Re: Hybrid partition tables -- can gpart make them?

On Thu, Mar 17, 2022 at 7:20 AM Karl Denninger <karl@denninger.net> wrote:

> First, the "why" -- I wish to have *two* OS partitions, a data partition
> and a config partition under NanoBSD on a Pi3 or 4.  Both boot using EFI
> and the "3", at least, appears to refuse to do so off a GPT-labeled disk.
> This means I need *five* slices and MBR can only do 4.
>
> I attempted to have one slice be "Freebsd" with the two OS partitions
> inside it, which would work *except* it doesn't because I can't set
> "bootme" on those; the EFI loader always finds the first usable UFS
> partition and boots it.  I need to be able to toggle that to boot the
> *second* partition.
>
> I've replaced boot1.efi (quite some time ago) with loader_lua.efi in the
> EFI partition.  This works, but there does not appear to be a way to tell
> it that I want it to default to something other than the first bootable
> partition it finds
>

It follows the EFI Boot Manager protocol, but the RPi doesn't give a good
way to persist that data.

If you could get GPT working, you could use gptboot.efi, which allows you
to set which GPT partition to boot. We use that at Netflix for this exact
scenario.

More, see below...

The intent is to enable the capability to upgrade the OS without having to
> wipe/reload the card the unit boots from, then set the other partition as
> the  "next boot."  This works quite nicely with nanoBSD generally for
> MBR-bootable devices (and I use it with the pcEngines boards), but doesn't
> on the Pi due to requiring the EFI partition which means I run out of
> slots, never mind that the loader will still find andn boot the first one.
>
So, we read in \efi\freebsd\loader.efi off the ESP by default. We use it to
set boot environment variable (not UEFI ones, though there's a UEFI
override for this filename)

This lets you set currdev to be the device that you wish to boot off of in
there. This will load all the /boot files off that partition (at least all
the lua scripts, config, etc). I've tested this, but wound up using the GPT
method for selecting partitions because that's operationally better for the
purpose that I'd needed this for.

This won't help with the gpart creation question, nor with the mkimage
issue. The RPi requires the MBR partitioning to find things. GPT goes hand
in hand with MBR, since we put a 'protective mbr' on the disk in addition
to the GPT tables. That's part of the GPT spec. mkimage could be hacked to
create this hybrid, where you'd have one FAT slice in the MBR world, and
you could have the full layout you want with GPT. However, that's kinda
weird, and I don't know how our code would cope with that (I've never tried
it, though I have discussed it theoretically with benno when he was trying
to have a unified gpt/iso boot loader in BIOS land)....

Warner