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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
