Solved freebsd-update(8) and boot environments

With freebsd-update(8) in FreeBSD 12.3 and 13.1 on ZFS:
  • a single upgrade will typically add two boot environments:
2022-04-15 14-11-29 13.1-BETA1.png2022-04-15 14-56-58 13.1-BETA1.png2022-04-15 15-40-39 13.1-RC3.png

freebsd-update.conf(5)​

Code:
% uname -KU ; tail -n 3 /etc/freebsd-update.conf
1400056 1400056

# Create a new boot environment when installing patches
# CreateBootEnv yes
%

freebsd-update.conf(5)
  • to not create a boot environment, CreateBootEnv no

Related​

For releng/12.3 and releng/13.1:

FreeBSD bug 263303 – FreeBSD 13.1 release notes
 
Last edited:
… exactly what steps I should follow to update to the latest patch level with a new boot environment (keeping in mind I am a complete noob)?

Preparations​


Just once, these two commands:
  1. ( echo export EDITOR=/usr/bin/ee ; echo export VISUAL=/usr/bin/ee ) >> /etc/profile
  2. ( echo setenv EDITOR /usr/bin/ee ; echo setenv VISUAL /usr/bin/ee ) >> /root/.cshrc
– then log out.

Whenever required, another command – if your preferred shell is sh:
  • PAGER=/bin/cat ; export PAGER
– if your preferred shell is csh or tcsh, a simpler command:
  • setenv PAGER /bin/cat



The first two commands help to avoid unwanted appearances of vi(1). ee(1), an alternative editor that is also integral to FreeBSD, is typically more user-friendly for newcomers. ee is easy editor.

The PAGER-related command helps to avoid the confusion that can occur when a key press is required, but there's nothing on screen to hint that a key press is required.

I always run setenv PAGER cat (lazily, without the full path) before a run of freebsd-update.
 
… noob-friendly instructions that do the same thing as my instructions in my original post? …

If you choose to suppress the automation that's now integral to freebsd-update, then the essence of what you had was good:
  1. create a new environment
  2. activate the environment
  3. boot it
  4. begin your update routine
  5. if prompted to restart the operating system, do so.
In addition:

… KDE …

Whatever the desktop environment, it's advisable to:
  • log out
– before beginning an update routine.

When the SDDM screen appears, key Control-Alt-F2 to put a terminal (ttyv1) on screen, then login as root to perform the update routine.

Noob-friendly instructions (condensed)​


An example, with FreeBSD 13.0-RELEASE-p11 as a starting point and csh as the preferred shell for root:
  1. bectl create 13.1-RC4
  2. bectl activate 13.1-RC4
  3. use KDE Plasma to restart the OS
  4. Control-Alt-F2
  5. login as root
  6. setenv PAGER cat
  7. freebsd-update -r 13.1-RC4 upgrade
  8. follow the on-screen instructions
  9. remember the PAGER-related command before each run of freebsd-update
  10. refrain from logging in to Plasma until after completion of all stages of the update routine (including stages that are documented, but do not appear on screen) – in other words, be prepared to repeat Control-Alt-F2.
 
Whatever the desktop environment, it's advisable to:
  • log out
– before beginning an update routine.

When the SDDM screen appears, key Control-Alt-F2 to put a terminal (ttyv1) on screen, then login as root to perform the update routine.
Thanks, grahamperrin. I'm thinking about following my original instructions and using beadm. Does this sound OK? I'm using KDE, but I don't believe I use SDDM. I start KDE by running startx as a regular user. Should I still make sure to perform the update routine in the command-line interface? Additionally, do you know how to find the current patch level without running freebsd-update fetch? I'm guessing the current patch level is still p11 for 13.0, but I want to know how to find the current patch level when updating in the future.
 
Additionally, do you know how to find the current patch level without running freebsd-update fetch? I'm guessing the current patch level is still p11 for 13.0, but I want to know how to find the current patch level when updating in the future.
Code:
curlew:/home/mike% freebsd-version -ku
13.0-RELEASE-p11
13.0-RELEASE-p11
 
… to find the current patch level without running freebsd-update fetch? … for 13.0 …

Officially​

Maybe something like:
  1. visit the FreeBSD home page <https://www.freebsd.org/>
  2. under SECURITY ADVISORIES, use the context menu for More to open the list of advisories in a separate tab
  3. under ERRATA NOTICES, click More
  4. open the most recent errata notices in separate tabs
  5. open the most recent security advisories in separate tabs
  6. seek the highest p number that applies to 13.0-RELEASE-.

Unofficially​

13.0-RELEASE-p11 at the foot of the table.
 
… I start KDE by running startx as a regular user. Should I still make sure to perform the update routine in the command-line interface? …

Part of the routine involves a check for upgrades to packages.

In tests: I sometimes see failure to log out (from the desktop environment) where log out is attempted after upgrading. Better to not risk putting yourself in situations such as this.

Better to run the commands at ttyv1, without logging in to Plasma.
 
Notable for FreeBSD 13.1-RELEASE, but not mentioned in the announcement or release notes:



Where boot environments are supported and appropriate, the install command of freebsd-update[8] will automatically create a snapshot of the current environment before proceeding with installation. freebsd-update.conf[5] describes the CreateBootEnv option, which can be set to no, and other situations in which automation will not occur. 1420778e9ee6, 8a3c868ab4e6
 
the install command of freebsd-update[8] will automatically create a snapshot of the current environment before proceeding with installation.
How does this work exactly? Doesn't one have to create a BE, then activate it and then actually reboot into so one can rollback on a failed update? I doubt that freebsd-update(8) would want to force a reboot but as per my understanding that would be necessary - what am I missing?
 
… what am I missing?

Something is missing from the FreeBSD Handbook under <https://docs.freebsd.org/en/books/handbook/cutting-edge/#freebsdupdate-upgrade> (Performing Major and Minor Version Upgrades, currently 24.2.3).

At the moment I can't find the relevant bug (sorry):

<https://forums.freebsd.org/threads/...nt-surveys-announcement-and-background.84849/>

– unless I'm missing something, it's not (or not yet) in the dependency tree for meta bug 263315.


See <https://forums.freebsd.org/posts/567267>



Also, to complicate things, online manual pages are somewhat broken at the moment. Maybe work in progress on FreeBSD bug 262778 – FreeBSD 13.1-RELEASE, FreeBSD 13.1-RELEASE and Ports, FreeBSD Ports 13.1
 
Manual pages such as freebsd-update.conf(5) and freebsd-update(8) now work as expected.

How does this work exactly? …

As far as I can tell, when you next use freebsd-update to install an update (of the base operating system) to FreeBSD 13.1-RELEASE:
  1. the preset name for the initial boot environment is probably default (see the opening post, third screenshot)
  2. you run freebsd-update, it creates (does not activate) a snapshot of default, then installs things to default
  3. you restart the OS
  4. you re-run freebsd-update, it creates (does not activate) another snapshot of default, then installs things to default
  5. you run e.g. pkg upgrade
  6. you restart the OS, still using default
– then if ever default is irreparably spoilt, you'll activate then boot a snapshot (in other words, default will no longer be the default) and future updates will be to the active boot environment.

HTH
 
This is more than a little disturbing... I don't like finding "surprise" boot environments!

My travelling FreeBSD VM (on a notebook) just nearly ran out of disk space, and I find this:
Code:
[f13.138] # bectl list
BE                             Active Mountpoint Space Created
13.1-RELEASE_2022-08-10_092443 -      -          4.23G 2022-08-10 09:24
131                            NR     /          15.8G 2022-05-26 16:14
default                        -      -          3.39G 2021-09-09 02:46
So I checked what I'm actually running from the BE "131":
Code:
[f13.143] #  freebsd-version -k -u
13.1-RELEASE-p1
13.1-RELEASE-p1
The BE called "default" which would be from FreeBSD 13.0. The boot environment I originally set up for FreeBSD 13.1 was called "131". I ran freebsd-update(8) a few days ago after the flurry of Errata Notices. I'm assuming that's installed 13.1-RELEASE-p1

From what's being suggested above, "13.1-RELEASE_2022-08-10_092443" is a backup copy of the original "131".

I intend to destroy "13.1-RELEASE_2022-08-10_092443" and "default". Does anyone think that's a bad idea?
 
This is more than a little disturbing... I don't like finding "surprise" boot environments!

My travelling FreeBSD VM (on a notebook) just nearly ran out of disk space, and I find this:
Code:
[f13.138] # bectl list
BE                             Active Mountpoint Space Created
13.1-RELEASE_2022-08-10_092443 -      -          4.23G 2022-08-10 09:24
131                            NR     /          15.8G 2022-05-26 16:14
default                        -      -          3.39G 2021-09-09 02:46
So I checked what I'm actually running from the BE "131":
Code:
[f13.143] #  freebsd-version -k -u
13.1-RELEASE-p1
13.1-RELEASE-p1
The BE called "default" which would be from FreeBSD 13.0. The boot environment I originally set up for FreeBSD 13.1 was called "131". I ran freebsd-update(8) a few days ago after the flurry of Errata Notices. I'm assuming that's installed 13.1-RELEASE-p1

From what's being suggested above, "13.1-RELEASE_2022-08-10_092443" is a backup copy of the original "131".

I intend to destroy "13.1-RELEASE_2022-08-10_092443" and "default". Does anyone think that's a bad idea?

I'd always keep at least one known working BE as a backup in case something goes wrong at sometime.
 
Back
Top