Solved freebsd-update(8) and boot environments

Cath O'Deray

Cath O'Deray

 
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:

{link removed}
{link removed}

FreeBSD bug {link removed}
 
Last edited:
Scribner said:
… 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)?
Click to expand...

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.
 
Last edited:
Scribner said:
… noob-friendly instructions that do the same thing as my instructions in my original post? …
Click to expand...

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:

Scribner said:
… KDE …
Click to expand...

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.
 
grahamperrin said:
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.
Click to expand...
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.
 
Scribner said:
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.
Click to expand...
Code: 
curlew:/home/mike% freebsd-version -ku
13.0-RELEASE-p11
13.0-RELEASE-p11
 
Scribner said:
… to find the current patch level without running freebsd-update fetch? … for 13.0 …
Click to expand...

Officially​

Maybe something like:
  1. visit the FreeBSD home page <{link removed}>
  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​

  • visit <{link removed}>
– 13.0-RELEASE-p11 at the foot of the table.
 
Last edited:
Scribner said:
… 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? …
Click to expand...

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. {link removed}, {link removed}
 
Last edited:
grahamperrin said:
the install command of freebsd-update[8] will automatically create a snapshot of the current environment before proceeding with installation.
Click to expand...
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?
 
jbodenmann said:
… what am I missing?
Click to expand...

Something is missing from the FreeBSD Handbook under <{link removed}> (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 {link removed} 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 {link removed} …
 
Last edited:
Manual pages such as freebsd-update.conf(5) and freebsd-update(8) now work as expected.

jbodenmann said:
How does this work exactly? …
Click to expand...

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
 
Last edited:
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?
 
gpw928 said:
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?
Click to expand...

I'd always keep at least one known working BE as a backup in case something goes wrong at sometime.
 
You must log in or register to reply here.
Back
Top