Re: An idea for the EFI (LUA) loader....

On 6/17/2025 02:47, Xin Li wrote:
> On 2025-06-16 18:05, Karl Denninger wrote:
>> The problem is that it wants something like "rootdev=disk0s1a" -- a 
>> full specification.
>
> If ZFS is an option, you can say something like:
>
> rootdev=zfs:mydevice-boot/ROOT/default:
> currdev=zfs:mydevice-boot/ROOT/default:
>
> in EFI's FreeBSD/loader.env; ZFS have much better way to find out the 
> right device and does not rely on probe order.
>
But it isn't.

This is an "sort-of-embedded" environment.  The goal is "one media that 
boots them all, provided we have the drivers for your network card and 
its an AMD compatible CPU."

Thus it has to boot in something like a pcEngines apu2 (which has no 
idea what EFI is, and won't boot a GPT USB stick either) and also be 
able to be stuck into something like a GMKTek "cube PC" which has no CSM 
mode (EFI boot only.)  I'll live with the constraint that any other 
media in or connected to it (e.g. on a USB interface, etc) either can't 
be bootable OR you have set the boot order in the BIOS so the stick 
that's plugged in is the first to be considered.

I build these using "nanobsd" so they're power-fail safe and the 
capability to pull the stick in the event of a hardware failure, shove 
it into something else and with a de-minimus set of edits (e.g. "what 
are the ethernet interfaces called") if different (e.g. igb .vs. ix) it 
will come up and run.

Think edge gateway/firewall appliance.

I tend to stick these images out where anyone can grab and use them with 
a decent set of software included (e.g. Strongswan, etc.); I used to 
build them for the pcEngines internal sd card slot which came up as 
"mmcsd0" but those guys are gone, they're not fast enough to saturate a 
full gigabit connection anyway and, as it turns out, basically 
everything today when it boots FreeBSD identifies a USB stick as a "da" 
device, so if its the only storage device on USB it will come up as 
"da0" which works nicely (and quite consistently) once the kernel is 
loaded.  The goal is "one image that will boot and run on most, from old 
and crusty to new and shiny."

The key element that drives the request is that nanobsd allows online 
updating -- that is, there are two system partitions and you can update 
the one that isn't running with a "dd" and then reboot to activate it.  
I resolved the issue of losing the data partition in the nanobsd build 
if you have EFI as an option but that leaves me with this which I've not 
been successful sorting out reliably with the tools available.

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