Date: Thu, 6 Jun 2019 20:30:06 -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: <CANCZdfo3LK11Jvu_qDLFbeJuQggQrmr=w1ZYhDqLB6AeshP-rg@mail.gmail.com> In-Reply-To: <CANCZdfrKcxcL-sBwzMTBNDtT3WR2-9HBApjDOgW-Dy7U4PgVqw@mail.gmail.com> References: <33262C24-8B1E-4C3D-9E3F-549BD8B9F26D@transactionware.com> <CANCZdfoVdDjR8D_ju1i7%2BAKA9Va0rWwqo-H3KX=Mu4%2BMQY%2B_4g@mail.gmail.com> <74732E11-5735-46CB-AA54-2B49F30CB10A@transactionware.com> <CANCZdfrKcxcL-sBwzMTBNDtT3WR2-9HBApjDOgW-Dy7U4PgVqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 4, 2019 at 3:03 PM Warner Losh <imp@bsdimp.com> wrote: > > > On Tue, Jun 4, 2019 at 9:40 AM Jan Martin Mikkelsen < > janm@transactionware.com> wrote: > >> >> On 4 Jun 2019, at 16:10, Warner Losh <imp@bsdimp.com> wrote: >> >> >> 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 n= o >> 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 bee= n >> to move away from writable variables at all... Finally, the UEFI Boot >> Protocol assumes a host + media. There's no media-agnostic way to produc= e >> 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 issu= e: >> loader.efi and boot1.efi process all the partitions they find, but gptbo= ot >> just does one disk's worth and stops when it successfully boots somethin= g: >> 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 Manag= er >> 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. >> >> >> OK. >> >> I am looking at similar situations: Supermicro servers and various >> flavours of embedded systems. For some of the newer embedded systems UEF= I >> is the necessary approach. I am not at all interested in writable variab= les >> 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 an= d >> deciding what to do to duplicate the bootme/bootonce functionality. That >> there were lots of hoops to jump through was clear. However, I was comin= g >> to the conclusion that boot1.efi needed to duplicate the functionality o= f >> gptboot, and was getting ready to implement. >> >> How far have you gone with your gptboot.efi? What=E2=80=99s missing >> > > I have it mostly written at this point. Nailing down going back and forth > between handles and different partition numbers. > Update to the latest and apply https://reviews.freebsd.org/D20547 and this will create a gptboot.efi you can test. It works for me for the first few cases I've tested. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo3LK11Jvu_qDLFbeJuQggQrmr=w1ZYhDqLB6AeshP-rg>