From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install Date: Fri, 19 Jun 2015 12:02:47 +0100 Message-ID: <21891.63191.825324.447946@mariner.uk.xensource.com> References: <1434644687.28264.53.camel@citrix.com> <1434644710-28881-11-git-send-email-ian.campbell@citrix.com> <21891.1671.795247.587046@mariner.uk.xensource.com> <1434709346.28264.88.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1434709346.28264.88.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Ian Campbell writes ("Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install"): > On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote: > > This seems a pretty serious bug. Is there a way to avoid it ? > > Unfortunately not as far as I can tell, it seems to be a major > shortcoming of the way UEFI boot order is managed both from the UEFI UI > and via the Linux command line tools. FWIW I was inspired by the way > XenRT has to do this too (so it is a problem for x86 too). > > grub-installer happens pretty late in the install, so the gap until the > late command which repairs things is short, but not ideal I agree. The real risk is, I think, that a marginal timeout results in the machine being powered off at the wrong moment. We could reduce the risk of this by having the installer report back to the controller saying "I'm about to enter the critical region" and "I have now exited the critical region and am about to reboot", thus applying a separate timeout to the critical region. Ian.