Re: [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure

["Ard Biesheuvel" <ard.biesheuvel@arm.com>]

On 6/17/20 2:40 PM, Leif Lindholm wrote:
> On Wed, Jun 17, 2020 at 14:28:04 +0200, Ard Biesheuvel wrote:
>> On 6/17/20 2:16 PM, Leif Lindholm wrote:
>>> On Wed, Jun 17, 2020 at 13:32:36 +0200, Ard Biesheuvel wrote:
>>>> On 6/17/20 1:12 PM, Leif Lindholm wrote:
>>>>> On Tue, Jun 16, 2020 at 19:48:34 +0200, Ard Biesheuvel wrote:
>>>>>> One of the side effects of the recent changes to PlatformBootManagerLib
>>>>>> changes to avoid connecting all devices on every boot is that we no
>>>>>> longer default to network boot on a virgin boot, but end up in the
>>>>>> UiApp menu. At this point, the autogenerated boot options that we used
>>>>>> to rely on will be instantiated too,
>>>>>
>>>>> The passive voice is confusing me a bit here - who does the updating,
>>>>> and when specifically?
>>>>>
>>>>
>>>> Originally, the ArmPkg PlatformBmLib would always refresh all boot options,
>>>> but now, only the UiApp does that upon entry, at which point your sitting in
>>>> the menu idly, and so automated network boot no longer works.
>>>
>>> Sure. But the message should contain some description of agency.
>>>
>>> Something like:
>>> "On entry, the UiApp instantiates the autogenerated boot options that
>>> we used to rely on - but it does not consume them. This breaks the
>>> unattended..."
>>
>> OK
>>
>>> I assume the UiApp only ever *adds* entries, which is why checking
>>> number of entries is sufficient?
>>>
>>
>> It only manages entries that it instantiated itself, but it may also remove
>> entries if the underlying hardware has disappeared.
> 
> Hmm, that's a bit trickier then. I mean, it's unlikely, but I'm sure
> there's situations that could happen.
> Would we run the risk of getting bug reports like "system fails to
> boot from Ethernet when inifiniband switch powered off"? Or if some
> virtual devices presented by a BMC appear/disappear?
> 

If the boot entries are not refreshed, you will retain the old ones. So 
the only way this could lead to a boot failure is when you rely on 
automatically generated boot entries to device that disappear and 
reappear in a different place, e.g., move a Ethernet PCIe card to a 
different slot. Note that USB devices plugged into a different port will 
still work fine, though, as they rely on the removable boot path in this 
case, which will be attempted anyway before doing the UnableToBoot().

Note that the failure mode here is being dropped into the menu, where 
before you were always dropped into the Shell. The case we are trying to 
address here is zero intervention network boot after putting the device 
into circulation, and that should work correctly with this change: if 
the network boot path did not exist before, it will be added, in which 
case the number of boot options will increase.