On Jun 28, 2012, at 12:29 PM, Peter Jones wrote:
>> In all of my testing, an empty NVRAM will always locate Apple's bootloader
>> and use it first. If not present, then it goes to EFI//EFI/BOOT/BOOTx64.EFI.
>> If not present, then it executes the first 440 bytes of the MBR (if a
>> partition other than MBR 1 is marked bootable). Lacking a UI entirely, I
>> think these are rather good fallbacks considering the target market. [1]
>
> So what you're saying is that it really doesn't work that well unless you're
> booting MacOS first. Not surprising.
I've said this how?
It is completely reasonable and rational for Apple hardware to first boot Mac
OS, if present, if NVRAM is empty or invalid. It's also consistent with section
3.3 of the UEFI spec. Vendors gets to decide the boot order. The point of that
section is to get a bootable computer, rather than a computer that craps its
diaper.
> In 2.3, section 3.4 has subclause 3.4.1.2 regarding default boot policy for
> non-removeable media. In effect, the policy is that you should put a binary
> such as I described earlier in the thread in /BOOT/EFI/BOOT${ARCH}.EFI on
> non-removeable media as well.
1.
3.4.1.2 is a bit messy. It says in paragraph 2 that default boot processing
behavior may optionally occur. Then proceeds to propose how it will occur, if
it optionally occurs, using a file to be located in an optional directory per
12.3.1.3.
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.
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.
> 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.
And in 20 years such a thing would never occur on Apple hardware in the same
context, which have had a keyboard command used on startup specifically
designed to obliterate the contents of NVRAM. And firmware that knows how to
reasonably intelligently recover from such condition.
> 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.
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.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
