On 06/28/2012 03:54 PM, Chris Murphy wrote:
2.
It doesn't at all indicate who should do this. If anything 12.3.1.3 implies
it's vendor domain. Not operating system domain.
It's completely obvious that if we want something to happen, we have to do it.
Given there's no mandate that this subdirectory or file be created, let
alone used by the firmware, I don't see how this is your bug, as you put it.
It's a tool for us to use. Right now we don't.
I see no reason it isn't conforming to the current version of the spec. In
fact, I don't see any reason it isn't conforming to /any/ version of the spec.
The default behavior prior to 2.3 was to iterate all removable devices and
do what's specified there, and then if that fails, iterate all "fixed media"
devices and do something completely unspecified.
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.
If we don't put a file there, the firmware is /in no way/ required to do
anything in particular. It's *never* required to default to running UEFI
applications not specified by Boot#### variables that are included in
BootOrder and also do not match the path /BOOT/EFI/BOOT${ARCH}.EFI .
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.
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.
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
