Re: nanobsd [was Re: Cross compiling user applications for armv7]

On 9/20/2025 19:19, Sulev-Madis Silber wrote:
> On September 20, 2025 2:34:06 PM GMT+03:00, Karl Denninger<karl@denninger.net> wrote:
> ...
>> There are ways to have that also be two-root-partition allowing "near-line" updates (update the other partition with the new OS code then reboot to activate it) provided you have a deterministic way to know which device the loader will boot from.  On EFI boot machines this can be problematic to obtain deterministically once the system is running.
>>
> there was some discussion somewhere about boot switching troubles
>
> unsure if even gpt helps here with it's dual part tables
>
> in my case i replace env files in efi part to control boot switch. it's a bad hack. i use cp, sync, mv, sync, etc magic to make it more power fail resistant
>
> i wish there's some sane way to do that. maybe loader could have changes. so you don't need to muck around with currdev & rootdev and what else. perhaps boot by ufs label?
>
> in my case i finally settled on ufs label of rootfs-<unixtimestamp>. my approach writes full raw fs images which stay unmodified
>
> and what about zfs? i might also need to have double pool system for resiliance
>
> i battled with this before efi too, 10y ago, in embedded. then it was fun if somewhere between uboot stages and fbsd loader / kernel, the boot order magically changes
>
> unsure if zfs be could be used here and is it enough. is it better in embedded? zfs also has benefits like copies=3 and compression. and ability to withstand power failures. unsure about which extent but on ufs i was once cursing on 0b file. but at least on zfs the bootfs is a metadata and that's much better than file on fs
>
> any opinions here?

The basic problem is that the EFI loader has its own ideas about the 
enumeration order of the devices on the machine, and you don't know what 
they'll be.  If you want a "universal" media that will boot on legacy 
(no EFI *possible*, which is the case for some such as pcEngines boxes) 
*and* will work on EFI you have a quandary.

I fixed the build issue in that such boxes typically can't boot GPT 
media either, but that is fixable because you can still have a partition 
layout that looks like this on MBR:

1. Partition "1"
2. Partition "2"
3. EFI (ignored for a non-EFI box)
4. "Data partition" which is then sub-partititoned into "cfg" and "data"

Looks like this on a USB stick when running:

=>      63  60125121  da0  MBR  (29G)
         63  11257500    1  freebsd  [active]  (5.4G)
   11257563  11257500    2  freebsd  (5.4G)
   22515063     81920    3  efi  (40M)
   22596983    840517    4  freebsd  (410M)
   23437500  36687684       - free -  (17G)

=>       0  11257500  da0s1  BSD  (5.4G)
          0        16         - free -  (8.0K)
         16  11257484      1  freebsd-ufs  (5.4G)

=>       0  11257500  da0s2  BSD  (5.4G)
          0        16         - free -  (8.0K)
         16  11257484      1  freebsd-ufs  (5.4G)

=>     0  840517  da0s4  BSD  (410M)
        0   62500      1  freebsd-ufs  (31M)
    62500  750000      4  freebsd-ufs  (366M)
   812500   28017         - free -  (14M)

For an MBR/CSM boot (non-EFI) you simply set the "active" partition 
after updating the other and that one is booted -- that works as it has 
always, in that it tells the system what to boot. The same is true if 
you use GPT with the "bootme" flag.  The problem with EFI is that you 
need to know what the EFI loader will call the disk so you can set 
"rootdev=...s1a" or "s2a" since the EFI loader ignores the partition 
"active" marker, particularly if you want "one build that works even on 
systems with no EFI or capacity to boot a GPT disk."

I have found no deterministic way to know what that will be (e.g. 
"disk0" is the obvious, but that makes a presumption -- there is no 
other media that could be enumerated.  What if there is?) once the box 
is booted and running.  There is nothing visible in sysctl, for example, 
that tells me deterministically where the loader got the running 
system's root from.

If you're willing to build EFI-only and ZFS, for example, then you could 
use the "bootfs" pool property for this and that should work as expected 
(beadm does this).  But on small-RAM systems ZFS is ill-advised and a 
lot of "embedded" applications are small-RAM.....

It would be nice if the EFI loader passed to the kernel where it loaded 
from (e.g. its idea of "rootdev" at the time it ran) which the kernel 
could then stash that in a sysctl-visible place.  That doesn't prevent 
someone from screwing it up by plugging in some other device to the box 
(thus potentially changing the EFI BIOS enumeration order) but so long 
as the physical configuration doesn't change that should be good enough.

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