freebsd-update auto BE confusion

Hi all - I've run into a few servers and VMs where I've either done something wrong with the automatic BE functions of freebsd-update or maybe I'd started doing things manually and the transition to auto BEs just didn't go well, or my initial understanding of BEs was wrong. I have no idea. :)

Anyhow, wherever I see this, I have a situation like this repeated:

Code:
[spork@hc1-nnj3 ~]$  bectl list -c creation
BE                                Active Mountpoint Space Created
default                           -      -          457M  2021-01-04 02:00
12.2-RELEASE                      -      -          3.99G 2021-06-19 17:45
13.1-RELEASE                      NR     /          14.5G 2022-11-14 04:04
13.1-RELEASE-p3_2023-01-20_204855 -      -          99.5M 2023-01-20 20:48
13.1-RELEASE-p5_2023-03-04_035111 -      -          49.2M 2023-03-04 03:51
13.1-RELEASE-p7_2023-05-02_225038 -      -          65.6M 2023-05-02 22:50
13.2-RELEASE_2024-08-20_162120    -      -          2.60M 2024-08-20 16:21
13.2-RELEASE_2024-08-20_163328    -      -          245M  2024-08-20 16:33

Versions differ, but the pattern is the same. My active BE (marked with "NR") references some old release, then a series of all the updates (yes, I know, I'm behind), but they aren't marked "active".

The actual running version is correct:

Code:
[spork@hc1-nnj3 ~]$ freebsd-version -kru
13.2-RELEASE-p11
13.2-RELEASE
13.2-RELEASE-p12

Any idea where I've gone wrong?

What's the safest way to go about correcting this and cleaning up a bunch of the older BEs?
 
The BE named 13.1-RELEASE was created by you and is never touch by freebsd-update, usually it is named default.
Then each time you upgrade, freebsd-update create a BE that is a snapshot of the current version. So it is named after the FreeBSD version right before the upgrade.
So in your case, you should not remove the one that is marked as NR (so not 13.1-RELEASE).
then you could remove all the other, except for 13.2-RELEASE_*.
So in the end, it should be
13.1-RELEASE NR / 14.5G 2022-11-14 04:04
13.2-RELEASE_2024-08-20_162120 - - 2.60M 2024-08-20 16:21
13.2-RELEASE_2024-08-20_163328 - - 245M 2024-08-20 16:33

Then you could rename 13.1-RELEASE to something else.
 
I should name it using the freebsd-update auto-snapshot scheme though, right? Or it will just keep happening?

I think I have a throwaway test VM like this somewhere, going to give it a whirl - rename things and then do a point upgrade and see what happens.
 
freebsd-update creates a new BE based on what you are currently running (the NR) flag. This represents the system BEFORE any updates are applied. You can modify the behavior so new BEs are not automatically created. /etc/freebsd-update.conf, variable CreateBootEnv (default is yes, explicitly set to No)

freebsd-update always updates the currently running BE (R and usually N flags)

Based on your information:
13.1-RELEASE is the BE you are currently running (R) and will be on the next boot. Don't delete this.
13.2-RELEASE_2024-08-20_163328 is the snapshot representing your system BEFORE the last freebsd-update command.

What is the output of
freebsd-version -kru
I'll bet that it references 13.2 stuff.

I simply let freebsd-update do it's thing with creating new BEs and then I manually bectl rename things to reflect reality.
Ex:
If freebsd-version -kru in your current 13.1-RELEASE BE says something like "13.2-RELEASE-p37" I would do:
bectl rename 13.1-RELEASE 13.2-RELEASE-p37
 
I should name it using the freebsd-update auto-snapshot scheme though, right? Or it will just keep happening?
You "shouldn't" (as in: what is "the one and only way") name it like the "auto-snapshot scheme".

In general, for any update process: minor-major & package upgrade (or other big change that is covered by BEs), you have the following options:
  1. Do not use BEs at all.
  2. Let the automatic creation of BEs solely under control of the enabled CreateBootEnv parameter.
  3. Disable CreateBootEnv and fully control the creation of BEs manually.
  4. A combination of #2 and #3.
Note that the parameter CreateBootEnv in freebsd-update.conf(5) is only controlling the update process by means of freebsd-update(8). If you update from source or where it concerns a packages/ports update, CreateBootEnv has no effect.

With option #1 you do not have any BE managerial duties to perform; you then, of course, miss out on all the advantages that BEs offer. I personally favor the last option. When BEs are created manually, you may consider an appropriate naming scheme, such as mer indicated. You may find Boot Environment & snapshot: important ZFS features useful.

As a final remark, the creation of a BE is (nearly) instantatinous; it is also practically free of charge, at its creation. Only over time, when changes accumulate, the extra storage costs increase; extra or "too many" BEs do not effect normal ZFS operation, with the exception when your total pool space goes beyond ca. 95% of its capacity.
 
Back
Top