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

On 3/18/2022 00:19, Warner Losh wrote:
>
>
> 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

I found a solution that works.

The EFI lua loader, if placed on the EFI partition directly, will load 
/and use /a config file on the MSDOS partition at 
EFI/FreeBSD/loader.env, and in there you can stick the directive 
"rootdev=......" (such as "disk0s2a" or "disk0s2b")

Now the disk layout can be:

MBR
    EFI
    Freebsd
       freebsd-ufs (system 1)
       freebsd-ufs (system 2)
       config (for nanobsd, overlay for the MD areas
       data (miscellaneous things)

You can then update the second system partition while it is running, 
validate that the load was good (e.g. cryptographic sum verify if you 
want, fsck of the new system boot partition is clean, that the 
/etc/fstab entry for root is adjusted in the "new" area as appropriate, 
etc) and then change rootdev only on success.  This is basically the 
same process that NanoBSD uses for MBR disks in setting the active 
primary partition which works as intended on MBR devices and it works on 
the Pi3 and 4 which boot from EFI.

What I thought I was going to have to do was have a fifth partition in 
front of the two system ones that had *only* the /boot/lua and 
/boot/defaults/loader.conf files, because otherwise if you are updating 
the first partition and it fails you're boned since that's where the 
directive is to change the rootdev.  But since the loader will obey the 
directive on the EFI partition that has proved to be unnecessary.

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/