UEFI boot1 vs. GPT bootme/bootonce flags

[Jan Martin Mikkelsen]

> On 4 Jun 2019, at 16:10, Warner Losh <imp at bsdimp.com> wrote:
> 
> 
> On Tue, Jun 4, 2019 at 1:06 AM Jan Martin Mikkelsen <janm at transactionware.com <mailto:janm at 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.

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’m 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’s missing?

Regards,

Jan M.