From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web12.2302.1592418621305854429 for ; Wed, 17 Jun 2020 11:30:21 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: ard.biesheuvel@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F1F221045; Wed, 17 Jun 2020 11:30:20 -0700 (PDT) Received: from [192.168.1.69] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6644A3F71F; Wed, 17 Jun 2020 11:30:12 -0700 (PDT) Subject: Re: [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure To: Leif Lindholm Cc: devel@edk2.groups.io, Pete Batard , Andrei Warkentin , Samer El-Haj-Mahmoud References: <20200616174834.1110310-1-ard.biesheuvel@arm.com> <20200617111235.GJ6739@vanye> <6a089a72-00cb-f8ce-16d7-50cefed9b47d@arm.com> <20200617121641.GM6739@vanye> <4bb1b99c-fa5a-ea9d-d786-32b16bb1604c@arm.com> <20200617124026.GO6739@vanye> <20200617143551.GP6739@vanye> From: "Ard Biesheuvel" Message-ID: <249475b8-f7e9-4c59-35be-8fc34ed023b0@arm.com> Date: Wed, 17 Jun 2020 20:30:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200617143551.GP6739@vanye> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 6/17/20 4:35 PM, Leif Lindholm wrote: > On Wed, Jun 17, 2020 at 14:59:45 +0200, Ard Biesheuvel wrote: >>>>> 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. > > OK. I'm not convinced we're not going to see a report of this > somewhere down the line, but I think you've managed to convince me > it's an unlikely enough situation, and a fallback, that we can bump it > to then (and it *is* a behavioural improvement in all other cases). > > Reviewed-by: Leif Lindholm > (with the commit message update) > Merged as 2d233af64b8f73d1b1e138b302e6344f7c2e0f4e Thanks all,