On Jun 28, 2012, at 2:01 PM, Peter Jones wrote:
>>
>> The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result
>> in the booting of an operating system or maintenance utility. The previously
>> bootable disk is not malformed, the computer simply lacks the proper efi
>> boot variable in NVRAM, a completely understandable condition, if not common.
>> And yet this firmware shits its pants.
>
> /EFI/BOOT/BOOT${arch}.EFI *is* the maintenance utility the spec refers to.
The spec says operating system or maintenance utility.
And you're still referring to a vendor subdirectory that's optional in the spec, and a 3.4.1.2 is also optional, but if the option is taken the vendor firmware it to behave in the described manner. You have zero assurance any firmware will conform, except by shear laziness on the part of firmware vendors who may prefer a singular hard code path default fallback, rather than having to scan the EFI system partition and come up with a dynamically generated boot list.
>> What is your interpretation of the first four sentences of paragraph 2 of
>> 3.3? To me that means the firmware is required to create a new boot order,
>> not save to NVRAM, and attempt to boot from each option. Obviously the only
>> required directory in EFI//EFI is the operating system vendor's subdirectory
>> containing their EFI boot image, and the intent of this section is for that
>> to be used.
>
> No. In fact, the spec specifically states: "These new default boot options
> are not saved to non volatile storage." That is, it is not allowed to create
> new BootOrder or Boot#### variables. That's the OS's job.
I'm not saying otherwise. I'm saying the spec specifically requires the firmware scan for new default boot options, does not store them in NVRAM, but does try to use them in sequence (vendor defined) to boot the system. BOOTx64.EFI is a fallback position. The behavior in 3.3 is longstanding and was left open ended without a final fail safe, which is the obvious point of bootx64.efi.
There are millions of firmware out there not conforming to 2.3.1 and hence not to 3.4.1.2 anyway.
>
>> It's wholly irrational for a user to move a disk from one computer to
>> another and to get either puke in the face (the OP's experience) or even a
>> vendor provided maintenance utility, rather than booting the singular obvious
>> option on the non-removable disk, in this case the only frigging option that
>> could possibly boot the hardware. That it's the same model makes the
>> experience beyond absurd.
>
> It can be obvious to you and still incompatible with the reasonably working
> model the spec provides.
I'm not bitching about the spec, I'm bitching about the firmware in the context of the OP's described experience. The intent of 3.3 is to avoid failure. It predates 3.4.1.2. The user is experiencing boot failure. I don't see 3.3 being at all in Fedora's domain to solve. It's a firmware problem. Not an OS problem. Not a spec problem.
Chris
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
