Solved Upgrade 13.2->14.0 and zpool upgrade: command sequence

dnb

dnb

I'm planning an update 13.2 to 14.0. After this I'm going to do zpool upgrade for the system pool (root on ZFS). The system pool is a mirror of two freebsd-zfs partitions on disks with an EFI partition.

Here are the commands I'm going to run:

Code: 
freebsd-update -r 14.0-RELEASE upgrade
freebsd-update install

At this point I expect the file /boot/loader.efi to have been updated.
So next I update the bootloader for each disk in the mirror:

Code: 
mount -t msdosfs /dev/diskid/DISK-1111111111111p1 /mnt

Here I copy updated bootloader from /boot that was already updated in the previous step:

Code: 
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount/mnt

Then I finish the update:

Code: 
shutdown -r now
freebsd-update install
pkg-static upgrade -f

Or should I update the bootloader here at this point, after the second freebsd-update install?

Finally, zpool upgrade:

Code: 
zpool upgrade zroot

However, what confused me about the 14.0 Release Notes: https://www.freebsd.org/releases/14.0R/relnotes/
There have been a number of improvements in the boot loaders, and upgrading the boot loader on the boot partition is recommended in most cases, in particular if the system boots via EFI. If the root is on a ZFS file system, updating the boot loader is mandatory if the pool is to be upgraded, and the boot loader update must be done first. Note that ZFS pool upgrades are not recommended for root file systems in most cases, but updating the boot loader can avoid making the system unbootable if the pool is upgraded in the future. The bootstrap update procedure depends on the boot method (EFI or BIOS), and also on the disk partitioning scheme.
Click to expand...

Q1: What does "upgrades are not recommended" mean? Either it should be written that (1) such upgrades will lead to breakdowns, or that (2) it is absolutely safe. And the expression "not recommended" means undefined behavior after upgrade. So can I safely do a zpool upgrade for the system pool or not?

I only have one zpool, on which both the system and data are located, so the problems resulting from the zpool upgrade are very relevant to me.

Besides, I see too much drama here in release notes. Even if the pool is not loaded, it will not be damaged? Then we'll just boot from the livecd and put the correct updated bootloader where we need it, right?

Q2: Is my command sequence correct?
 
It has been a recurrent question since the venue of 14.0-RELEASE. You may search the answer on this forum.

Be aware about the existence of /efi/freebsd/loader.efi. Double check this before to upgrade your zpool. And create a checkpoint, it can be useful in case you can't boot.
 
You shoud better waiting for at least next update (-p1 or -p2) before upgrading root pool.
OpenZFS codes in stable/14 is updated to fix severe issue AFTER 14.0-RELEASE is released, if I recall correctly.
But the fix is not yet considered "theoretically OK" by some developers.
It seems to be tested with brute-forcing but it is NOT ASSURED that the test is enough. You should keep paying attention at least for freebsd-stable ML and freebsd-current ML (reading archives linked are OK, but you must subscribe to post questions) and check no more screams are found.
 
You are missing the last freebsd-update install which remove old libs.

For upgrading your zpool: by doing so you cannot go back safely with boot environment (I think ?) which is not a good idea when upgrading.
So, when you are definitely sure that you never go back to 13.2, remove the related boot environment and then you can upgrade your zpool (by removing your old BE you acknowledge that you cannot go back).
 
  • Thanks
Reactions: dnb
Not sure if it works as intended or not (as I myself have not tried at all), but possibly creating checkpoint zpool-checkpoint(8) can help.

Be sure you do NOT create/modify needed files/directories until you are enough sure it's working OK. Create/modify anything for purely testing.
Once you are sure, you can discard the checkpoint.

If not, you can (hopefully) get back to at the point when the checkpoint is created. But doing so should discard ALL CHANGES TO THE WHOLE POOL after the checkpoint is created
.
 
dnb said:
I'm planning an update 13.2 to 14.0. After this I'm going to do zpool upgrade for the system pool (root on ZFS). The system pool is a mirror of two freebsd-zfs partitions on disks with an EFI partition.
Click to expand...
You can install the new loader on the 13.2 system. Just to be sure. It is capable of booting both versions (14.0 and 13.2). Also wait a little with zpool upgrade. See that everything is working. There is no way back, except transferring the whole pool to another pool with lower version.
 
  • Thanks
Reactions: dnb
T-Aoki said:
You shoud better waiting for at least next update (-p1 or -p2) before upgrading root pool.
Click to expand...
Definitely a smart decision)

By the way, recently I was interested in a Linux distribution for GPU-server. And I came to the conclusion that Debian 11 finally became quite good six months after the release of Debian 12.

Carrying out this principle for FreeBSD 13 vs 14, the situation here will differ by a time lag, which will no longer be equal to several years. Most likely, here I will just have to wait until 14.1, drinking tea and reading this forum.
 
Just a FYI:
I basically have newest stable branch for daily use (currently, stable/14) and main branch for sniffing potentially dangerous changes to be MFC'ed later on different physical disk on exactly the same computer.

I'm using dataset holding home directories on main branch as one of the backups for the ones of stable branch using send/recv. So both pools MUST be at the same features enabled/disabled.

For this use case, the only completely safe timing to zpool upgrade -a is when new stable branch is JUST BRANCHED and ZFS codes 100% matches in both branches.

This time, stable/14, at least one known-to-be-dangerous feature existed on main (block cloning), so I decided not to upgrade pool this time, which means I must wait for next stable/15.

If the time stable/15 is created comes and there could be situation something like this time, my upgrading pool would be slip to stable/16.

This wouldn't fit for everyone, but this is MY strategy.
 
  • Thanks
Reactions: dnb
T-Aoki said:
… stable/14, at least one known-to-be-dangerous feature existed on main (block cloning), …
Click to expand...

For readers who may be new to this: ZFS pool features are described at <https://openzfs.github.io/openzfs-docs/man/master/7/zpool-features.7.html>.

For stable/14 there was <https://cgit.freebsd.org/src/commit/?h=stable/14&id=068913e4ba3dd9b3067056e832cefc5ed264b5cc> search results in cgit can be horribly confusing misleading.

stable/14 Git blame for the relevant line of the file: <https://github.com/freebsd/freebsd-...penzfs/module/os/freebsd/zfs/zfs_vfsops.c#L92>.
 
You must log in or register to reply here.
Back
Top