freebsd-update auto BE confusion

spork

spork

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
Click to expand...

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
 
spork said:
I should name it using the freebsd-update auto-snapshot scheme though, right? Or it will just keep happening?
Click to expand...
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.
 
OK, so all the complexities and different ways of doing this aside... let me get back to a really simple question that will probably make this all make sense. If using the auto-BE stuff in freebsd-update correctly, your running system, in normal operation will always have the BE normally/by default called "default", correct? Unless you're doing a rescue operation of some sort, you'll never be running off of a named BE like "13.4-RELEASE-p1_2025-01-27_003955"...

I just did a run through on a VM and that seems to be correct based on going through a few updates to get to a current 13.4-RELEASE.

Code: 
root@bhyvetest:/home/spork # bectl list
BE                                Active Mountpoint Space Created
13.3-RELEASE-p7_2024-11-26_004159 -      -          1.60G 2024-11-26 00:41
13.3-RELEASE-p8_2025-01-27_003145 -      -          2.78M 2025-01-27 00:31
13.4-RELEASE-p1_2025-01-27_003955 -      -          2.91M 2025-01-27 00:39
default                           NR     /          8.47G 2022-06-27 04:28
root@bhyvetest:/home/spork #
 
And while I'm here, also am I the only one that really cannot read this blue text? Am I too old or colorblind? Can other people easily read that?

Also I see hitting "A" will cycle through BE's, but I note that hitting "b" just resets to the default BE. Should it? What is "bootfs" in this context? Booting from another pool?

Screenshot 2025-01-27 at 4.43.30 PM.png


Screenshot 2025-01-27 at 4.43.47 PM.png
 
spork said:
And while I'm here, also am I the only one that really cannot read this blue text? Am I too old or colorblind? Can other people easily read that?

Also I see hitting "A" will cycle through BE's, but I note that hitting "b" just resets to the default BE. Should it? What is "bootfs" in this context? Booting from another pool?
Click to expand...

Colors can be disabled, try loader.conf(5):
Code: 
loader_color
	       If set to "NO", the beastie boot	menu will be displayed
	       without ANSI coloring.

bootfs is what actually controls where the ZFS boot process searches for the filesystem to boot by default (=bootable dataset): Boot Environments and zpoolprops(7).

P.S. A nice basic overview of BEs is item #1 Managing Boot Environments by Dru Lavigne in Boot Environment & snapshot: important ZFS features.
 
spork said:
And while I'm here, also am I the only one that really cannot read this blue text? Am I too old or colorblind? Can other people easily read that?
Click to expand...
No you are not the only one. It's the same for me. Need to get my eye glasses off and move 20 cm close to the screen to
read it.
But let's be happy to have BE's and the option to choose them at boot time.
 
meaw229a said:
No you are not the only one. It's the same for me. Need to get my eye glasses off and move 20 cm close to the screen to
read it.
But let's be happy to have BE's and the option to choose them at boot time.
Click to expand...
I think I'll open a PR on this. While I could turn off color, it's not the default and I can't imagine someone in some urgent "can't boot!" situation wants to sit there and squint and/or dig up how to disable color.
 
src: baa7e9cd3083ccaed8f26e9ad786ff9657ab85fc.
It looks like the reading difficulty with colors used for items displayed by the loader had already been addressed:
  • "blue" on "black" --> "cyan" on "black"
This change is now present in
  1. stable/13
  2. releng/13.5
  3. stable/14
My guess is that it will not appear in 14.2-RELEASE but will appear in 14.3-RELEASE.

However, as this is a lua script, you can edit /boot/lua/menu.lua and apply these changes yourself.
 
You must log in or register to reply here.
Back
Top