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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#61413): https://edk2.groups.io/g/devel/message/61413
Mute This Topic: https://groups.io/mt/74921613/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
