From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by mx.groups.io with SMTP id smtpd.web12.9072.1592404555756345082 for ; Wed, 17 Jun 2020 07:35:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=1Y955Iim; spf=pass (domain: nuviainc.com, ip: 209.85.221.65, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f65.google.com with SMTP id t13so164948wrs.2 for ; Wed, 17 Jun 2020 07:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=e17Rn1YWFzDsdlU1I8xk998NW+ZLox6yR4VeYMgcf48=; b=1Y955Iimx6UoL9FDAaJ4Zyc2h6G2zUMNHN0o5XKyQ9+eHyNYglM5KI0vypD6YHkWDf m/tPpSPraJpFCkK9rnwy8ExRZsOKZrA0jnzkqypvdrGxcvBco/m2lu3dZXtaWPsEoC66 TcPjp4BApkBRPw8ClRsR/Bx2Y0RxeezRtTrEQ/f0FUg0j3XE+SgYLSrAP66Zx1DQcnEF s1e2umDSGm7Dgrqdrgs5o/DNGHzkRo/dKitqNra+KBeaBk9Eb4xh6HMrrHfNczagR4Dg 9abacgCMonl035JGT/WoctDwvmmRvE3/qbQpcVcT+hZVKYtGwn4jIrTI8vcn32huqk0R pIEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=e17Rn1YWFzDsdlU1I8xk998NW+ZLox6yR4VeYMgcf48=; b=nhlUwZUU7e3G8lM5aSQm+kG8DwUyev6b/jLIDegn1k9VRQ5MNWWT8f7SO3EE9bL95o 6DWsmTvsUPdFZzIZfB0sMObBMq4sWlcLLVuFUcZ8yyihFBL8p1QQ2LI73loEhsulnOrJ qFwx6IcqPoMNl7xUTrgzkcQny+mraUkH7fNu+NxTH8dkLSYuhceHhbBLvLSng6C+x5W1 p4uUE6FAom0Yjs7nrmgXxkIdqfHI+ZOAKmyRFHgdxrzFZT+fEtV6RAkfWf5V0apNo949 ody0DzZ0LCOVzoKb4uSIGAhph8L7fn7jssCXC1g2Jk7bIkJkGZ9OD+vjqnjyvxPvxZzu ZilQ== X-Gm-Message-State: AOAM5309zE8rH8QZg6u4tvMkANFLqtS3kVFnX790v2PYmnDJXEoW6/Nq QUBrDKRc+OLh7Tzsk64ZvPYsAw== X-Google-Smtp-Source: ABdhPJy7IjWw+72wir3VEZWu9DDxMp5mHjbKrGS4J0BsIUgM3JuBo42Z7NBfZHrY7fbLZHAc8iLkRg== X-Received: by 2002:adf:ff82:: with SMTP id j2mr8463867wrr.375.1592404554393; Wed, 17 Jun 2020 07:35:54 -0700 (PDT) Return-Path: Received: from vanye ([2001:470:1f09:12f0:b26e:bfff:fea9:f1b8]) by smtp.gmail.com with ESMTPSA id q4sm618757wma.47.2020.06.17.07.35.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2020 07:35:53 -0700 (PDT) Date: Wed, 17 Jun 2020 15:35:51 +0100 From: "Leif Lindholm" To: Ard Biesheuvel Cc: devel@edk2.groups.io, Pete Batard , Andrei Warkentin , Samer El-Haj-Mahmoud Subject: Re: [PATCH] ArmPkg/PlatformBootManagerLib: regenerate boot options on boot failure Message-ID: <20200617143551.GP6739@vanye> 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> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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) / Leif