From owner-freebsd-hackers@freebsd.org Tue Jun 4 15:40:31 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA5A015B4F84 for ; Tue, 4 Jun 2019 15:40:30 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from hermod.tmst.com.au (hermod.tmst.com.au [203.14.245.41]) by mx1.freebsd.org (Postfix) with SMTP id 434756EFEC for ; Tue, 4 Jun 2019 15:40:24 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 47390 invoked by uid 907); 4 Jun 2019 15:40:14 -0000 Received: from p54B73A18.dip0.t-ipconnect.de (HELO [192.168.7.2]) (84.183.58.24) by hermod.tmst.com.au (qpsmtpd/0.96) with ESMTPSA (ECDHE-RSA-AES256-GCM-SHA384 encrypted); Wed, 05 Jun 2019 01:40:14 +1000 From: Jan Martin Mikkelsen Message-Id: <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags Date: Tue, 4 Jun 2019 17:40:06 +0200 In-Reply-To: Cc: "freebsd-hackers@freebsd.org" To: Warner Losh References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 434756EFEC X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.33 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_SPAM_SHORT(0.45)[0.450,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[a.mx.transactionware.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.68)[0.680,0]; NEURAL_HAM_MEDIUM(-0.29)[-0.294,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[country: AU(0.01)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 15:40:31 -0000 > On 4 Jun 2019, at 16:10, Warner Losh wrote: >=20 >=20 > On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen = > wrote: > Hi, >=20 > The UEFI boot1 loader does not support the GPT = bootme/bootonce/bootfailed flags for selecting which partition to boot. >=20 > Is there a reason for this? >=20 > Yes. There's three. >=20 > First, UEFI provides no way to get to these flags via their block = interfaces. Second, the block interfaces are independent, so there was = no easy way to know w/o jumping through a bunch of hoops. Third, the = UEFI Boot Manager Protocol was championed as being the one-true way to = select a boot partition. It's significantly more flexible and reliable = than rewriting the partition table from time to time. >=20 > However, there's significant drawbacks to the UEFI scheme. Vendors = suck at not mucking up the UEFI Boot Manager Protocol (I'm looking at = you SuperMicro). And the trend in embedded where UEFI has a foothold has = been to move away from writable variables at all... Finally, the UEFI = Boot Protocol assumes a host + media. There's no media-agnostic way to = produce an image with multiple partitions that you ping-pong between = (say a recovery USB stick that moves from system to system). >=20 > So against my better judgement, I've been working on making = gptboot.efi. It's not as terrible as I thought it would be, but it shows = another issue: loader.efi and boot1.efi process all the partitions they = find, but gptboot just does one disk's worth and stops when it = successfully boots something: this has required a restructuring of the = boot1 code that I started with to rearrange the loops used to find = things. An no, the gptboot.efi will not support ZFS, which has its own = way to do this outside of UEFI Boot Manager Protocol. >=20 > If you don't want to wait, there's now a mechanism for loading loader = environment variables from a file called \efi\freebsd\loader.env in the = ESP that can accomplish much the same thing. OK. I am looking at similar situations: Supermicro servers and various = flavours of embedded systems. For some of the newer embedded systems = UEFI is the necessary approach. I am not at all interested in writable = variables in firmware. I=E2=80=99m also not interested in booting from = ZFS. My question was because I have been reading the efi/boot1 source code = and deciding what to do to duplicate the bootme/bootonce functionality. = That there were lots of hoops to jump through was clear. However, I was = coming to the conclusion that boot1.efi needed to duplicate the = functionality of gptboot, and was getting ready to implement. How far have you gone with your gptboot.efi? What=E2=80=99s missing? Regards, Jan M.