How to upgrade a separate bectl environment?

[loveydovey]

What's the easiest way to upgrade a separate bectl environment (which just a ZFS dataset)?

I'm assuming I have to launch a bhyve VM or a jail that uses that separate dataset to boot from. Chrooting is probably a little too barebones for this. Does anyone have a jail script for this? It should be like a super simple jail, right?

 

[loveydovey]

The main reason for this being upgrading from a running system and then booting into a perfectly upgraded setup. Otherwise, if you are upgrading normally you end up breaking everything (that you had compiled yourself) until you rebuild all your packages.

 

[SirDice]

Otherwise, if you are upgrading normally you end up breaking everything (that you had compiled yourself) until you rebuild all your packages.

Should only happen with a major version upgrade. The ABI is only allowed to change between major versions. This ABI is the reason you need to recompile your applications, they need to be linked to the "new" libc for example.

 

[loveydovey]

But that happens often enough. I think it's making me recompile Firefox because I upgraded from 14.3 to 14.4. So I lose the browser if I try to upgrade the normal way...until I recompile it, which is hard because I need the browser to recompile stuff because I need to look things up.

So still wondering how I can 'chroot' into a bectl environment dataset and upgrade things there.

 

[Alain De Vos]

My personal workflow. Never used any bectl boot environment.
Must say my workflow is always for anything latest stable , that is 15.
Never had any boot issues, even after compiling installing packages.
But then your milleage can vary.
Note chroot and boot environments are completely different stuff.
Normally on boot, a key , you are able to choose boot environments.
Normally key 8
----> then key 2 choose boot environment out of list.
Note : there is also "bootctl activate XXX"

 

[SirDice]

But that happens often enough. I think it's making me recompile Firefox because I upgraded from 14.3 to 14.4.

It won't. It's a minor version change, ABI is kept stable across the entire major branch. So it's not a problem to run an application that was built on/for 14.0 on 14.4.

 

[patmaddox]

bectl is nice precisely because you can create and mount a BE and upgrade it. I'm typing this from memory / man page, so you may need to adapt it a bit, but this is the gist.

bectl create my-new-be
bectl mount my-new-be /tmp/my-new-be
# upgrade /tmp/my-new-be however you want
bectl umount my-new-be
bectl activate -t my-new-be # next boot only

 

[Machiaveli]

As patmaddox said, freebsd-update(8) can do that easily with the help of -b and -d options.

Create a new BE (or used an already existing one):

bectl create freebsd_update_`date +%y%m%d`
bectl list | grep freebsd_update
freebsd_update_260509     -     -     8K     2026-05-09 09:48
bectl mount freebsd_update_260509
Successfully mounted freebsd_update_260509 at /tmp/be_mount.9xZM

Next, ensure that freebsd-update doesn’t use its default database in the currently booted BE by removing that directory:

rm -Rf /var/db/freebsd-update

Run the freebsd-update(8) utility and specify the BE mount point as the basedir ( -b) and the BE’s database as the workdir ( -d).
First, fetch the updates:

freebsd-update -b /tmp/be_mount.9xZM -d /tmp/be_mount.9xZM/var/db/freebsd-update fetch
<output snipped>
The following files will be removed as part of updating to
14.4-RELEASE-p3:
<SNIP> (use page down to read through and q to quit)

Next, repeat that command with install:

freebsd-update -b /tmp/be_mount.9xZM -d /tmp/be_mount.9xZM/var/db/freebsd-update install
<output snipped>
done.