On 06/28/2012 02:04 PM, Chris Murphy wrote:
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.
We're talking about 3.4.1.2 here.
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]
So what you're saying is that it really doesn't work that well unless you're
booting MacOS first. Not surprising.
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.
You've completely ignored all of section 3.4, which specifies what those
default boot parameters are for various kinds of devices. In version 2.2,
there's no default for non-removable media whatsoever. The spec does sort
of accidentally define that the vendor must have some default, but it really
is allowed to be "set the machine on fire". That's what we're talking about.
In 2.3, section 3.4 has subclause 3.4.1.2 regarding default boot policy for
non-removeable media. In effect, the policy is that you should put a binary
such as I described earlier in the thread in /BOOT/EFI/BOOT${ARCH}.EFI on
non-removeable media as well.
This is a firmware requirement, not a boot loader or operating system
requirement.
It's a tool the OS can use. So far, we have not done so.
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.
I see no reason it isn't conforming to the current version of the spec. In
fact, I don't see any reason it isn't conforming to /any/ version of the spec.
The default behavior prior to 2.3 was to iterate all removable devices and
do what's specified there, and then if that fails, iterate all "fixed media"
devices and do something completely unspecified.
If we don't put a file there, the firmware is /in no way/ required to do
anything in particular. It's *never* required to default to running UEFI
applications not specified by Boot#### variables that are included in
BootOrder and also do not match the path /BOOT/EFI/BOOT${ARCH}.EFI .
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
