Date: Thu, 17 Mar 2022 22:19:36 -0600 From: Warner Losh <imp@bsdimp.com> To: Karl Denninger <karl@denninger.net> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: Hybrid partition tables -- can gpart make them? Message-ID: <CANCZdfqheEm4ypt2Va=2JRVSbHF1D%2BRFyYjGnPp8eay8WGaW3Q@mail.gmail.com> In-Reply-To: <68449cab-c5d7-47ff-99e1-d0e6963374d0@denninger.net> References: <68449cab-c5d7-47ff-99e1-d0e6963374d0@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000dfbf8f05da767483
Content-Type: text/plain; charset="UTF-8"
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
--000000000000dfbf8f05da767483
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 17, 2022 at 7:20 AM Karl =
Denninger <<a href=3D"mailto:karl@denninger.net">karl@denninger.net</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=20
=20
=20
<div>
<p>First, the "why" -- I wish to have *two* OS partitions, a =
data
partition and a config partition under NanoBSD on a Pi3 or 4.=C2=A0
Both boot using EFI and the "3", at least, appears to refus=
e to do
so off a GPT-labeled disk.=C2=A0 This means I need *five* slices and
MBR can only do 4.</p>
<p>I attempted to have one slice be "Freebsd" with the two OS
partitions inside it, which would work *except* it doesn't becaus=
e
I can't set "bootme" on those; the EFI loader always fi=
nds the
first usable UFS partition and boots it.=C2=A0 I need to be able to
toggle that to boot the *second* partition.<br>
</p>
<p>I've replaced boot1.efi (quite some time ago) with loader_lua.ef=
i
in the EFI partition.=C2=A0 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</p></div></blockquote><div><br>=
</div><div>It follows the EFI Boot Manager protocol, but the RPi doesn'=
t give a good way to persist that data.</div><div><br></div><div>If you cou=
ld get GPT working, you could use gptboot.efi, which allows you to set whic=
h GPT partition to boot. We use that at Netflix for this exact scenario.</d=
iv><div><br></div><div>More, see below...
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div><p>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=C2=A0 "next boot."=C2=A0 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.</p></div></blockquote=
><div>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 U=
EFI override for this filename)<br></div><div><br></div><div>This lets you =
set currdev to be the device that you wish to boot off of in there. This wi=
ll load all the /boot files off that partition (at least all the lua script=
s, config, etc). I've tested this, but wound up using the GPT method fo=
r selecting partitions because that's operationally better for the purp=
ose that I'd needed this for.</div><div><br></div><div>This won't h=
elp with the gpart creation question, nor with the mkimage issue. The RPi r=
equires 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 GP=
T tables. That's part of the GPT spec. mkimage could be hacked to creat=
e 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 we=
ird, 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)....<br></div><di=
v><br></div><div>Warner<br></div></div></div>
--000000000000dfbf8f05da767483--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqheEm4ypt2Va=2JRVSbHF1D%2BRFyYjGnPp8eay8WGaW3Q>