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