Date: Tue, 4 Jun 2019 08:10:49 -0600 From: Warner Losh <imp@bsdimp.com> To: Jan Martin Mikkelsen <janm@transactionware.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: UEFI boot1 vs. GPT bootme/bootonce flags Message-ID: <CANCZdfoVdDjR8D_ju1i7%2BAKA9Va0rWwqo-H3KX=Mu4%2BMQY%2B_4g@mail.gmail.com> In-Reply-To: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen < janm@transactionware.com> wrote: > Hi, > > The UEFI boot1 loader does not support the GPT bootme/bootonce/bootfailed > flags for selecting which partition to boot. > > Is there a reason for this? > Yes. There's three. 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. 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). 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. 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. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoVdDjR8D_ju1i7%2BAKA9Va0rWwqo-H3KX=Mu4%2BMQY%2B_4g>