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