Date: Tue, 17 Jun 2025 15:49:57 -0600 From: Warner Losh <imp@bsdimp.com> To: Karl Denninger <karl@denninger.net> Cc: freebsd-hackers@freebsd.org Subject: Re: An idea for the EFI (LUA) loader.... Message-ID: <CANCZdfoHrkoods86hsQScjH5fgrgrSCwMzDVtvV3=wEXU_dV3g@mail.gmail.com> In-Reply-To: <009e52a1-4d6f-42b6-905f-53fbf1c69065@denninger.net> References: <eef03d5d-c906-40ea-b319-0497eda6812b@denninger.net> <9c7f2953-2fb3-4c36-977c-41aa7fd55c5c@delphij.net> <009e52a1-4d6f-42b6-905f-53fbf1c69065@denninger.net>
index | next in thread | previous in thread | raw e-mail
On Tue, Jun 17, 2025 at 4:19 AM Karl Denninger <karl@denninger.net> wrote: > > > 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. So we don't care about MBR in EFI-land. Sure, it kinda works, but this has been a problem for years and nobody has fixed it. We have code that will figure it out based on a number of heuristics for GPT disks no problem. Millions of people use it. We don't have similar code for MBR, so you have to do your rootdev=disk3s3a: hacks. One thing we need to do is fix that, I think. This would help us find the root partition better, which would obviate the need for this silly hack (though when there's two partitions we're ping-ponging between, we're back to needing a better solution). There's also some patches somewhere (Phab or github) that adds label:foo: as a disk that's valid for a partition labelled foo. Not sure if it handles MBR + BSDLABEL or not though. It could expand for that too, I guess. So that would be one way to do it. making rootdev=s1a: is hard. But a variation on the label idea we could have something like rootdev=efi:s1a: and that would expand to 'the volume you loaded the boot loader from, slice 1, bsdlabel partition a.' It's possible to write that code, at least, though I don't have that in my pocket. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=149803 has a really old patch that could be updated. That bit of parsing code changed a bit, so some tweaking likely is needed. I just never got around to looking at it since I didn't have a fire burning under my !@#%# to motivate me. The other issue you haven't mentioned is that the BIOS picks some random disks sometimes to boot off of and the BIOS disk enumeration code isn't 100% standardized so sometimes the right answer is disk4s1a for reasons that are mysterious.... Warnerhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoHrkoods86hsQScjH5fgrgrSCwMzDVtvV3=wEXU_dV3g>