Re: 12.4-STABLE to 13.3-STABLE upgrade

From: Edward Sanford Sutton, III <mirror176_at_hotmail.com>
Date: Mon, 29 Jul 2024 18:45:30 UTC
On 7/29/24 05:36, Gareth de Vaux wrote:
> On Mon 2024-07-29 (13:45), Ronald Klop wrote:
>> You do not provide much information on your system or upgrade method so I can't predict other issues you might run into, but as far as ZFS is concerned I think your upgrade should be fine.
> 
> Thanks. It's a ZFS on root system, raidz2, GENERIC kernel, Xeon E3-1220. I upgrade with the standard
> source rebuild procedure.
> 
>> The bootcode is not touched by upgrading FreeBSD. Upgrading the bootcode is a separate manual step.
>> And as long as you do not run "zpool upgrade" the ZFS bootcode and pools will stay compatible.
> 
> Sure, I update the bootcode after installworld to keep things in sync. The question is is there not
> eg. a chance of downgrading features by going to an earlier dated 13.0-RELEASE version and not being
> able to boot. Yes before running zpool upgrade.

   The boot code needs to be new enough to understand features of the 
ZFS pools it needs to boot. I'm not aware of any incompatibilities with 
eh boot loader booting older versions.
   If you need the pool to be compatible with an older version of 
FreeBSD, then you want to specify the relevant compatibility version or 
don't upgrade the pool after creating it with said older version of FreeBSD.
   You may be able to get past the initial limitations of compatibility 
of a FreeBSD version to ZFS pools by installing sysutils/openzfs when it 
is newer than what is in that FreeBSD version and compatible with the 
older system. 12 isn't an officially supported FreeBSD version anymore, 
but openzfs was available through ports for it.

>> If you want the pools to not be upgraded "accidentally" you can do something like "zpool set compatibility=freebsd-12.4 <pool-name>".
>> Different compatibility versions can be found here:
>> # ls -l /usr/share/zfs/compatibility.d/
> 
> Thanks, I have no /usr/share/zfs directory though?

   You also haven't upgraded to 13 yet. 13 switched from the solaris 
forked ZFS code to openzfs which I think is when such compatibilities 
are added. Upgrading to 13+ does not upgrade your zpool, running `zpool 
upgrade` with a pool name or -a does and that is when a newer bootloader 
that is compatible with the features is needed and when you won't be 
able to use that pool on an older FreeBSD. If you install the port on 12 
you will also have that compatibility list but under the /usr/local 
equivalent path but you do not need to specify a compatibility to not 
run a zpool upgrade.
   Keep in mind that having ZFS as a kernel module from the ports tree 
means you will want to keep it rebuilt+reinstalled when the kernel gets 
upgraded or disable it before that next boot until you do so. Disabling 
won't work if it is a root-on-zfs type of pool and if the next boot 
doesn't have a compatible ZFS kernel module in base (such as upgrading 
from one version of 12 to another version of 12, or upgrading to 13+ but 
of a version with ZFS older than what was installed from ports and too 
old to have support for all enabled/activate zpool features).

> To rephrase: is it safer to go from
> 
> 12.4-STABLE -> 13.3-STABLE, or
> 
> 12.4-STABLE -> 13.0-RELEASE -> 13.3-STABLE
> 

   I'd just do the leap in one run unless seeing /usr/src/UPDATING give 
any intermediate required step. The newer 13 releases and stable has 
fixes that you will want. When following stable, I haven't grabbed 
release versions in between; I usually haven't waited so long to go from 
one major version to the next. 14 also brings some nice performance so 
you may consider if you are able and want to go to it.
   Off the top of my head an example was somewhere around FreeBSD 10(?) 
where upgrading further required installing up to a certain version of 
10 first due to compiler changes so that you had a compatible compiler 
for building later versions. I didn't find out if that could be worked 
around by having a newer compatible compiler installed from 
ports/packages. Maybe there are similar gotchas I have forgotten about 
for later versions but the UPDATING file should be checked.