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

["Leif Lindholm" <leif@nuviainc.com>]

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?

/
    Leif