UEFI boot1 vs. GPT bootme/bootonce flags

[Warner Losh]

On Tue, Jun 4, 2019 at 9:40 AM Jan Martin Mikkelsen <
janm at transactionware.com> wrote:

>
> 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> 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
>

I have it mostly written at this point. Nailing down going back and forth
between handles and different partition numbers.

Warner