On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
> The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious choice? Maybe a future spec could be more clear that the subdirectory and an EFI image in it are required, who should provide it, and that it should be used first in the case of invalid or missing BootOrder variables in NVRAM.
This is still in between ambiguous and optional in 2.3.1.
> Booting the first EFI executable you find on a drive is not a sensible
> thing to do.
Puking in the face of the user with an incoherent boot failure message is more sensible than trying the singular boot loader on the available non-removable drive?
I admit this strategy can also cause problems, and the UEFI spec isn't particularly helpful[1] in resolving the problem of removed operating systems, with residual boot loaders that point to them. But that is no worse, and still likely to generate a more coherent boot loader produced "can't find blah" message, than the OP's experienced rat race of an error message.
> Even Apple don't do that. Install Linux (only) on a Mac,
> zap the PRAM, see what happens - it'll boot if there's a blessed
> bootloader on an HFS+ partition, not otherwise.
They have a vendor defined order, which 3.3 allows, even though Apple EFI is not UEFI. When PRAM is zapped, the NVRAM is empty and nothing is blessed, therefore the sequence I described earlier applies. That it may fail on a singular valid boot loader in EFI//EFI/redhat/grub.efi I'll take your word on, I haven't tried it and if so it's pathetic but also really unsurprising.
And notwithstanding their non-standard EFI and ensuing problems and incompatibility it has cause, the hardware does provide a vastly superior UX in the same situation as the OP. Apple hardware absolutely would have booted. Unquestionably. And this is not a boot loader feature, or an OS feature, it is a firmware behavior.
[1] Failure of the spec to use "must release" instead of "can release". UEFI v2.3.1, section 2.1.3: If the OS loader experiences a problem and cannot load its operating system correctly, it can release all allocated resources and return control back to the firmware via the Boot Service Exit() call.
Chris Murphy
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
