Re: PKGBase and Embedded Systems

From: Bob Bishop <rb_at_gid.co.uk>
Date: Tue, 12 Aug 2025 12:51:37 UTC
Hi,

> On 12 Aug 2025, at 12:40, Karl Denninger <karl@denninger.net> wrote:
> 
> Well, ok, "sort-of" embedded systems.  Think firewalls.
> Right now I build a USB stick-based setup for these on NanoBSD and, for some other hardware in somewhat-similar applications (e.g. home control, etc.) for the PI series using Crochet.
> /var is volatile on both where /usr/local/etc has a "save" mechanism (along with /etc) in both environments; that is, its volatile while running, but can be instructed to sync with the saved copy thus on a reboot/reset/powerloss the last-saved is retained.
> A couple of times I've concluded the "best" way to deal with things that dump state they'd like to keep in /var somewhere (usually in /var/db), where the "thing" doesn't have a command-line switch to change that, is to move that directory to /usr/local/etc/db and then symlink it during the setup, thus it becomes "volatile but subject to save" as with anything else in /usr/local/etc.

We used to do that kind of thing. Now that storage, RAM and 64bit boxes are cheap we just use a full install on ZFS and make everything except the volatile bits read-only…

> Pkgbase opens the possibility of fixing security vulnerabilities and similar with other than using the "ping pong" type of dual-partition setup that both nanobsd and Crochet can support.  But pkgbase, like pkg itself, relies on persistent storage.
> Anyone else doing embedded stuff have thoughts on this?  (I presume pkgbase going to be something you CAN use, but not that you MUST use....)

… so we can directly use freebsd-update today and pkgbase tomorrow.

With ZFS one can switch the read-onlyness on and off selectively and without rebooting. We also set copies=2 for a bit more safety (although it’s debatable whether that actually helps).

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

--
Bob Bishop
rb@gid.co.uk