UEFI boot1 vs. GPT bootme/bootonce flags

[Warner Losh]

On Tue, Jun 4, 2019 at 3:03 PM Warner Losh <imp at bsdimp.com> wrote:

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

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