On Jun 28, 2012, at 3:25 PM, Matthew Garrett wrote:
> 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.
It's not a vendor subdirectory. It belongs to the spec. It's also
clearly not required, since you can have an entirely functional system
without it.
12.3.1.3 "optional vendor subdirectory called BOOT". Although it's vendor
in-specific.
> 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?
Yes. Of course any useful EFI implementation should then have an
interface to choose your bootloader, but that's a somewhat separate
issue.
Ok well we disagree then because I consider this extremely user hostile behavior. There is
only one choice. UI not required because the user isn't needed to choose ONE OPTION.
And choosing that one option no matter what it is, statistically it's going to be a
boot loader for the only operating system on the drive, which is the 99% use case. The use
case in the example that started the thread.
How about we save the firmware puke in the face for when there's meaningful ambiguity
involved?
Apple's firmware will only attempt to load either blessed files
or the
fallback path. The behaviour is basically identical to the one you're
complaining about.
The behavior I care about, is results. Swap hard drives, even dual boot, between two Apple
computers, and they still boot. Lenovo example in this thread, does not boot in the same
case. These are not identical behaviors.
And so far all the Apple hardware I've tried does actually fall back to
/EFI/BOOT/BOOTx64.efi unlike a lot of UEFI hardware.
> 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.
What? No, Apple hardware wouldn't have booted. The only scenario in
which it would have is if you had a blessed bootloader, which is clearly
massively outside the EFI specification since it relies on HFS+.
Seems like a deficiency of the UEFI specification that a dinky ass company thought of this
problem 20 years ago and solved it with file system metadata. There is no reason why the
UEFI spec can't do as good or better than this, and make it standard to write out an
NVRAM equivalent file, or other metadata, on the EFI System partition, to resolve the
ambiguity.
Chris Murphy