FreeBSD Upgrade: newbie messed up the zfs boot configuration (slightly)

E

enno1

Hey there,

today I decided to upgrade my FreeBSD System, so I started to read the docs and once stumbled upon the freebsd-upgrade command (just used pkg update before) I started to give it a try (without RTFM).

Everything seems to be installed fine - it's just that I have to select the correct ZFS root snapshot by pressing "8" during the boot menu. "default" seems to point to the wrong "snapshot" [1] (sorry if I'm using the wrong term here), so the question is how can I make
zfs zroot/ROOT/15.0-RELEASE_2025-12-08_185706 the zroot/ROOT/default ZROOT?

I could also delete the 15.0-RELEASE snapshot and restart the upgrade, but on the other hand the kernel seems to be upgraded and that would break all executables, so i would have to downgrade the kernel, too.

Kind regards

[1] If I boot that environment, all executables fail complaining about missing/wrong libc version .so.
 
# man bectl
.
.
bectl [-r beroot] activate [-t | -T] beName

activate [-t | -T] beName
Activate the given beName as the default boot filesystem. If the
-t flag is given, this takes effect only for the next boot. Flag
-T removes temporary boot once configuration. Without temporary
configuration, the next boot will use zfs dataset specified in
boot pool bootfs property.


is what I assume would solve you issue
never happend to me so never had chance to practice .
 
Thanks for your reply.

I also thought about just setting the filesystem/snapshot zroot/ROOT/15.0-RELEASE_2025-12-08_185706 as the default for booting, but I'm not sure if this is unnecessary "fragmenting" the ZFS filesystem list.

It's probably the right thing to do, because you have these kind of snapshots/filesystems after an update anyway, but I can not verify how it should look when all is done correctly.

That's why I decided - because of your input - to verify how a clean upgrade looks like on ZFS (by using a second system) and maybe then I decide that for me it will be the best to rollback the whole update.

Because up to now it always felt like a pleasure to use ZFS, I'm looking forward that this will work out just fine. Maybe I will ask another question, once I see how a cleanly upgraded FreeBSD ZFS looks like.
 
Well, went trough the upgrade process from 14.1-RELEASE to 15.0-RELEASE (first upgraded to 14.3-RELEASE).

Now, a very similar error message is presented, when I run the command pkg update:

"ld-elf.so.1: Shared object "libutil.so.9" not found"

So, this time - a not so important - .so file is affected, still leaves login etc. functional.

Progress? :-/

Now that I'm somewhat familiar with the basic upgrade command chain, I wonder what my mistake was.

I'll try a third time, to make sure that I did not make any mistakes.
 
pkg bootstrap -f. And make sure both the 15.0 kernel and userland are active.
 
Hello, first post here but my search for an already asked question instead of new post brought me to this thread. I hope is OK. I think is similar enough.
I have some tests I want to do. For that I created a new VM on my laptop. Downloaded 14.3-RELEASE dvd1.iso , started it and went to install using ZFS and mostly defaults. Once sshd in I went to freebsd-update fetch then freebsd-update install which showed it was creating a new Boot Environment.
A reboot followed and by default it booted to the "default" BE which is still NR. All this is fine. I can activate, make the new snapshot the default and reboot. Name is "14.3-RELEASE_2025-12-16_155400".
My question is whether the expected flow with creating a new BE is to select it upon reboot to complete any updates and be in the newly updated BE. OR is the BE created (which is not marked new NR) created as a fallback in case of failure ?

What I would think my "process" would be is: a) create a new BE, activate and reboot onto it, then make the updates. That way I know my previously-good BE was left untouched.
If of use:
Code: 
# bectl list
BE                             Active Mountpoint Space Created
14.3-RELEASE_2025-12-16_155400 -      -          74.7M 2025-12-16 15:54
default                        NR     /          903M  2025-12-16 15:11
 
cookiemonsteruk said:
I can activate, make the new snapshot the default and reboot. Name is "14.3-RELEASE_2025-12-16_155400".
Click to expand...
This would revert the last freebsd-update install you did. In other words, you rolled back the update.

cookiemonsteruk said:
is the BE created (which is not marked new NR) created as a fallback in case of failure ?
Click to expand...
This.

Every freebsd-update install creates a snapshot BE first, then installs the updates in the currently active BE (which would normally be 'default'). So you should keep NR on "default" and just reboot. Those snapshot versions (like your 14.3-RELEASE_2025-12-16_155400) are in case you encounter a problem after installing the updates and you have something to fallback on. You're essentially going back in time before the updates were installed.

There's a different way to deal with updates some people like to use, they create a snapshot/clone of their current BE, install the updates in that clone and do a single test boot (or start a jail) of the new BE (with the updates). That's an entirely different approach and not how freebsd-update(8) works with BEs. But it's probably where some of the confusion comes from.
 
Perfect. That is exactly the flow I was missing from the current manual and my usage so far with the new BEs being created i.e. if the system is being patched up on the running BE or the one created for it. I know now - thank you SirDice

The alternative way you describe is with the snap/clone the chroot I imagine into to place the updates there. But no, I was thinking a way that makes sense to me somehow, how I've done it:
1) create new BE, name it like "freeBSD-14" mark active reboot into it.
2) now on "freeBSD-14" do the upgrades i.e.
freebsd-update fetch & install . Reboot and complete anything. Test what I want to test in this "new upgraded" environment. The previous BE is still there and I can identify it because it is called still "freeBSD-13" perhaps.

Maybe my head works differently because I can't see hits for this question i.e. is the system being patched up on the running BE or the one created for it.
Much obliged.
 
SirDice said:
There's a different way to deal with updates some people like to use, they create a snapshot/clone of their current BE, install the updates in that clone and do a single test boot (or start a jail) of the new BE (with the updates). That's an entirely different approach and not how freebsd-update(8) works with BEs.
Click to expand...

With freebsd-update's scheme, you could I suppose, do:

bectl activate <backupBE>
bectl activate -t <updatedBE>

reboot and then:

bectl activate <updatedBE>

I'm assuming that the main point of the -t option is to handle the possibility of booting into an untested BE that locks up without providing a usable boot menu/prompt. If this happens with an activated BE there's no way to boot into the backup BE.

For this to work I think the boot would have to start in the active BE so that it can reliably clear the -t setting, before switching to the temporary BE. Is that how it works? Does -t provide full protection against the problem I mentioned?
 
You must log in or register to reply here.
Back
Top