On Jun 28, 2012, at 10:26 AM, Peter Jones wrote:
> On 06/28/2012 12:17 PM, Chris Murphy wrote:
>
>> It is perturbing that in 2012, with a nearly 30MB operating system as a
>> pre-boot environment, that by design it doesn't scan the EFI System
>> partition for other possible boot options - like a rescue mode - in the event
>> efi boot variables aren't set.
>
> Well, as a matter of fact, if you read upthread, as of 2.3.1 it launches
> /boot/efi/boot${ARCH}.efi in this case. We weren't prepared for it, and so
> we're a little behind, but we've got a plan and we're going to do something
> about it.
I'm confused. I'm not familiar with that location. In 12.3.1.3 the location EFI//EFI/BOOT/BOOT[machine type short name].EFI is optional. It is only required, with no other, for removable media. If not required, I don't see how you can be faulted for lack of preparation for something optional.
>> Apple hardware does just such a scan. If I blow away every bit of information
>> in NVRAM, the firmware still scans available disks, and chooses a reasonable
>> default as fallback. Even in the case when Apple's bootloader isn't present.
>
> I bet you their reasonable default doesn't seem as good if you're normally
> dual-booting and using grub to chain-load apple's loader. I bet it's 50/50
> based on some criteria we haven't tried to figure out.
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]
Now, it may very well be that absent all of those, yet with a efi//efi/redhat/grub.efi present, that Apple hardware would not locate this and use it, even if it were the only obvious choice. I haven't tested it. If that doesn't work, I'd probably criticize it.
>
>> So after all of this UEFI complexity and baggage, we still need rescue media
>> in the example case? That is unbelievably stupid. The Lenovo case is either a
>> bug or it's bad design or they enjoy creating user hostile hardware.
>
> As lennart, myself, and mjg59 all made perfectly clear - this is our bug; it's
> possible to do this according to spec (though it could be better), and we're
> just not doing it yet.
I think we're talking about different things.
Based on section 3.3 of the 2.3.1 spec which rather clearly says a default boot behavior is required, though undefined (vendor specific), but must be invoked anytime the BootOrder variable is not present or invalid. The point being the expectation that default boot will load an operating system or a maintenance utility.
This is a firmware requirement, not a boot loader or operating system requirement.
I don't know what UEFI version Lenovo purports to conform to, but the lack of an EFI//EFI/BOOT/BOOTx64.EFI image isn't an excuse for it failing to boot a previously bootable disk that is in no way malformed. This seems to be a case of bad firmware behavior that isn't conforming to section 3.3 of the spec.
Chris Murphy
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
