Update Station, pkg, bectl, and boot environments

grahamperrin

Briefly

My command line routine, on FreeBSD, includes lines similar to these:

bectl create 20250503-1300
bectl mount 20250503-1300 /tmp/up
/usr/bin/time -h pkg -r /tmp/up upgrade -Fqy -r FreeBSD-base
env BACKUP_LIBRARY_PATH=/tmp/up/usr/local/lib/compat/pkg pkg -r /tmp/up upgrade -qUy -r FreeBSD-base
cp /root/.history /tmp/up/root/.history
history -S
cp /root/.history /tmp/up/root/.history
bectl umount 20250503-1300
bectl activate -t 20250503-1300

Please note, that's not a comprehensive list, not a recipe. (BACKUP_LIBRARIES=true in pkg.conf(5); the history-related lines suit my use of csh(1) for the root user; and so on.)

Essentially

never upgrade an active boot environment.

Instead: upgrade a new environment, make the environment temporarily active, boot it. If boot succeeds, then make the active environment non-temporary.

@ericbsd food for thought.

From tests with various versions of FreeBSD, and with GhostBSD, I'm fairly certain that upgrading an active environment is, simply, risky. Doing so in vt, after logging out from a desktop environment, does not negate the risk.

vimanuelt

grahamperrin
Yes, that is a good idea. It might be worthwhile to tune the datasets as well. Separating /usr/local into its own ZFS dataset on GhostBSD is a practical improvement. It keeps third-party packages persistent across boot environments, reduces upgrade time and storage use, and avoids reinstalling everything with each BE. It also allows independent snapshots and rollbacks of just your software stack, without touching the base system. This layout is especially helpful on low-resource systems and aligns with FreeBSD’s design philosophy. :-)

grahamperrin

vimanuelt … Separating /usr/local into its own ZFS dataset on GhostBSD …

I wouldn't do that.

If a boot environment is problematic:

clone a previous environment, one that is free from the problem
perform a limited upgrade of the clone (avoiding the problem)
activate the clone, then restart the OS.

vimanuelt

grahamperrin
That is sound advice, ZFS truly excels at rollback and controlled testing through boot environments.

My concern arises when encryption enters the picture. With GELI or ZFS native encryption, especially on low-resource systems, recovery workflows can break down. It is no longer just about cloning or activating datasets, it is about managing keys, device unlock sequences, and potential failure points during boot.

Would you agree that encryption introduces a layer of operational complexity that most guides simply gloss over?

Perhaps it would be better to drop support for GELI and ZFS native encryption in GhostBSD. The system is designed for newcomers, and encryption adds significant complexity to installation, boot management, and recovery. These are areas where even experienced users can run into trouble. Advanced setups involving encryption are better suited to FreeBSD, where the user is expected to understand and configure the full stack manually.

grahamperrin

vimanuelt … Would you agree that encryption introduces a layer of operational complexity that most guides simply gloss over? …

Not really.

Whilst there's potential for complexity, usage can be simple. An example, with the installer for FreeBSD:

install to a single device
accept the invitation to encrypt.

Further simplification should include:

user-friendly documentation for changing the passphrase in the case above
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282806#c4 autoconfiguration of fstab(5) for savecore(8) to work as expected.

Robin

After three weeks with no updates, I wondered if something was wrong. So I followed the procedure in GhostBSD's documentation, "forcing" an update with -f . That seemed to work but it re-installed every little thing. (new BE, I assume), and then Update Station offered updates to the newly-installed stuff. It made sense that it's done that way.

grahamperrin

Robin I followed the procedure in GhostBSD's documentation, "forcing" an update with -f . That seemed to work but it re-installed every little thing. …

As far as I know, the force in this case was required for the detected downgrade.

Please see:

https://forums.ghostbsd.org/d/208-ghostbsd-2501-r142p1-now-available/6 above
the screenshot below – downgrading (visible in Update Station) as part of the upgrade (visible in htop in the Terminal window).