swapping disk with UEFI hardware - a dead end?
lists at colorremedies.com
Thu Jun 28 22:03:39 UTC 2012
On Jun 28, 2012, at 2:51 PM, Matthew Garrett wrote:
> On Thu, Jun 28, 2012 at 02:22:48PM -0600, Chris Murphy wrote:
>> I'm not bitching about the spec, I'm bitching about the firmware in
>> the context of the OP's described experience. The intent of 3.3 is to
>> avoid failure. It predates 18.104.22.168. The user is experiencing boot
>> failure. I don't see 3.3 being at all in Fedora's domain to solve.
>> It's a firmware problem. Not an OS problem. Not a spec problem.
> The OS is expected to drop a utility in a well-known location in order
> to ensure that the firmware can do something sensible with 3.3.
I don't see how 3.3 or 3.4 burdens the OS vendor with this utility. 3.3 burdens the firmware and firmware vendor with determining the boot options order, and attempting to boot from each option - with the goal of booting either an operating system or a utility.
And how do you read 22.214.171.124's "default boot processing behavior may optionally occur" because that seems to render everything subsequent as optional for everyone, and still lacks explicit mention that the OS vendor is expected to provide a utility.
Further this seems to present a conflict with the abstraction intent of UEFI between OS and firmware, if the OS is required/expected to produce a utility so the firmware knows WTF to go do with itself.
> not doing that. What do you actually want the firmware to do here?
Conform to the burden placed on it by 3.3. Scan, produce new vendor defined boot options, then attempt to boot from each option.
More information about the devel