swapping disk with UEFI hardware - a dead end?

[Peter Jones]

On 06/28/2012 03:54 PM, Chris Murphy wrote:
> 2.
> It doesn't at all indicate who should do this. If anything 12.3.1.3 implies
> it's vendor domain. Not operating system domain.

It's completely obvious that if we want something to happen, we have to do it.

> Given there's no mandate that this subdirectory or file be created, let
> alone  used by the firmware, I don't see how this is your bug, as you put it.

It's a tool for us to use.  Right now we don't.

>
>
>> 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.
>
> The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result
> in the booting of an operating system or maintenance utility. The previously
> bootable disk is not malformed, the computer simply lacks the proper efi
> boot variable in NVRAM, a completely understandable condition, if not common.
> And yet this firmware shits its pants.

/EFI/BOOT/BOOT${arch}.EFI *is* the maintenance utility the spec refers to.

>> 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 .
>
> What is your interpretation of the first four sentences of paragraph 2 of
> 3.3? To me that means the firmware is required to create a new boot order,
> not save to NVRAM, and attempt to boot from each option. Obviously the only
> required directory in EFI//EFI is the operating system vendor's subdirectory
> containing their EFI boot image, and the intent of this section is for that
> to be used.

No.  In fact, the spec specifically states: "These new default boot options
are not saved to non volatile storage."  That is, it is not allowed to create
new BootOrder or Boot#### variables.  That's the OS's job.

> It's wholly irrational for a user to move a disk from one computer to
> another and to get either puke in the face (the OP's experience) or even a
> vendor provided maintenance utility, rather than booting the singular obvious
> option on the non-removable disk, in this case the only frigging option that
> could possibly boot the hardware. That it's the same model makes the
> experience beyond absurd.

It can be obvious to you and still incompatible with the reasonably working
model the spec provides.

-- 
         Peter