13.2p5 -> 14.0R - freebsd-update uprade - fails while creating boot environment

S

s2r

Hi all!
This week I tried to upgrade to 14.0-RELEASE from 13.2p5 but I failed. I ran into an zfs error while running freebsd-update upgrade and merging all the config changes.
I have many datasets that are used as disks for vms.

The upgrade fails with the following error:
Code: 
.............
# RISC-V HTIF console                                                                                                                                                            [451/1499]
-rcons  "/usr/libexec/getty std.9600"   vt100   onifconsole secure
+rcons  "/usr/libexec/getty std.115200" vt100   onifconsole secure
Does this look reasonable (y/n)? y
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".
[freebsd:~ $]> sudo freebsd-update install
Password:
src component not installed, skipped
Creating snapshot of existing boot environment... cannot create 'zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090222/cbsd-cloud-openbsd-70.raw': 'canmount' does not apply to datasets of this typeerror when calling zfs_clone() to create boot env
error when calling zfs_clone() to create boot env
error when calling zfs_clone() to create boot env
Failed to create bootenv 13.2-RELEASE-p5_2023-11-28_090222
failed.
Then I tried to delete that old dataset:
Code: 
 sudo zfs destroy -r zroot/ROOT/default/cbsd-cloud-openbsd-70.raw
[freebsd:~ $]> sudo freebsd-update install
src component not installed, skipped
Creating snapshot of existing boot environment... cannot create 'zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090341/bcbsd-ubuntusrv1-dsk1.vhd': 'canmount' does not apply to datasets of this typeerror when calling zfs_clone() to create boot env
error when calling zfs_clone() to create boot env
error when calling zfs_clone() to create boot env
Failed to create bootenv 13.2-RELEASE-p5_2023-11-28_090341
failed.

Here's a list of some datasets:
Code: 
zfs list -r -o name,canmount,mountpoint
NAME                                                        CANMOUNT  MOUNTPOINT
zroot                                                       on        /zroot
zroot/ROOT                                                  on        none
zroot/ROOT/13.2-RELEASE-p1_2023-08-06_180926                noauto    /
zroot/ROOT/13.2-RELEASE-p2_2023-09-10_235747                noauto    /
zroot/ROOT/13.2-RELEASE-p3_2023-10-05_123918                noauto    /
zroot/ROOT/13.2-RELEASE-p4_2023-11-08_124951                noauto    /
zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090222                noauto    /
zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090341                noauto    /
zroot/ROOT/13.2-RELEASE-p5_2023-11-28_090341/adc1           noauto    /usr/jails/jails-data/adc1-data
zroot/ROOT/13.2-RELEASE-p5_2023-11-28_094647                noauto    /
zroot/ROOT/13.2-RELEASE-p5_2023-11-28_094647/adc1           noauto    /usr/jails/jails-data/adc1-data
zroot/ROOT/13.2-RELEASE_2023-04-19_142632                   noauto    /
zroot/ROOT/13.2-RELEASE_2023-06-22_164022                   noauto    /
zroot/ROOT/default                                          noauto    /
zroot/ROOT/default/adc1                                     on        /usr/jails/jails-data/adc1-data
zroot/ROOT/default/bcbsd-ubuntusrv1-dsk1.vhd                -         -
zroot/ROOT/default/cbsd-cloud-cloud-Ubuntu-x86-20.04.2.raw  -         -

Any ideas why beadm might be falling to create the new be?
 
SirDice said:
Why are these created under zroot/ROOT/default?
Click to expand...

This behavior existed long before the `beadm` and the appearance of ZFS in the FreeBSD installer ( ZFS support implemented in CBSD around ~2013-2014 y) and so far there have been no problems. The logic is simple - CBSD takes the pool to which the working directory belongs ( /usr/jails directory by default).
For example, if the user creates a personal dataset for the CBSD working directory, all working data resources will belong to this dataset:
Code: 
# zfs create zroot/jails
# zfs set mountpoint=/usr/jails zroot/jails
# env workdir=/usr/jails /usr/local/cbsd/sudoexec/initenv
..
# cbsd jcreate jname=adc1

In this example we will see something like:
Code: 
..
zroot/jails/adc1    70.4M  34.6G  70.4M  /usr/jails/jails-data/adc1-data

// .. or for bhyve cloud/image:
zroot/jails/cbsd-cloud-FreeBSD-ufs-13.2.0-RELEASE-amd64.raw  3.85G  33.6G  1.03G  -


Maybe now it's time to force users to always unconditionally create a personal dataset if they don't want to encounter this behavior.

However, in the official handbook (or anywhere) I did not find any prohibitions regarding the use of 'zroot/ROOT/' for custom/users datasets (or volumes). So far I have not studied how `beadm` works, perhaps it has a configuration that will prohibit creating snapshots for unknown datasets (for example, some kind of 'include' or 'exclude' list ).
 
Seems like a bug. Suggest filing a bug report and/or discussing this on some mailing list (may be freebsd-fs).
 
Ole said:
I have not studied how `beadm` works,
Click to expand...

Check the manual page for beadm(8) in ports, <https://man.freebsd.org/cgi/man.cgi?query=beadm&sektion=8&manpath=freebsd-release-ports>. cc vermaden

Is the issue reproducible with bectl(8), integral to FreeBSD?

forums.freebsd.org

ZFS - bectl(8)

The online view of the manual page is currently broken, for RELEASE: Not broken, the view for CURRENT: kevans and others are aware.
forums.freebsd.org forums.freebsd.org

Particular attention to mount points.

Please read this comment alongside <https://forums.freebsd.org/posts/631446> if/when it appears.
 
Last edited:
So systems that have VMs created with CBSD can't upgrade to 14.0 right now, isn't it?

Or maybe disabling the creation of boot environments in freebsd-update?

forums.freebsd.org

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: freebsd-update.conf(5) % uname -KU ; tail -n 3 /etc/freebsd-update.conf 1400056 1400056 # Create a new boot environment when installing patches # CreateBootEnv yes %...
forums.freebsd.org forums.freebsd.org
 
You must log in or register to reply here.
Back
Top