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

not an FS developer, mostly an occasional FBsd installer these days on
bigger hw but I do run Pi and want. to run FBsd on Pi. I got a P4,
wound up on (unhappy!) Ubuntu for ZFS on a radxa SATA hat. I really
wanted FreeBSD but it wasn't ready for prime time when I commissioned
the system.

FWIW I would really appreciate the installer logic making this kind of
protective MBR+GPT outcome work, especially on the hardware like the
PI which has its own peculiarities in boot. Having to work out the
special cases for each box is a pain, but if I can incur the pain in
"you" rather than in me, its pain once, works everywhere. I think
thats the kind of incurred pain we want!

-G

On Fri, Mar 18, 2022 at 2:19 PM Warner Losh <imp@bsdimp.com> 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