Re: Upgrade form 13.2-RELEASE-p5 to 14.0-RELEASE took almost 24hours

On 11/24/23 10:43, Matthew Seaman wrote:
> On 24/11/2023 15:31, mike tancsa wrote:
>    BTW, does FreeBSD upgrade from 13 to 14 do a zpool upgrade automatically
>> or do you have to do that step manually ?
>>
>>      ---Mike
> 
> No, the system upgrade process very carefully does not do a zpool 
> upgrade, because that would make it impossible to back-out a botched 
> upgrade.
> 
> Before doing `zpool upgradez be aware that you will need to update your 
> boot blocks or efiboot partition (whichever mechanism your machine uses) 
> _before_ updating the zpool, or you will render your machine unbootable.
> 
> Also, for maximum recoverability, be very careful to create and make 
> backups of zpool including all your boot environments.
> 
> So the suggested sequence of events should be something broadly like:
> 
> * Upgrade system from 13 to 14 by whatever means you prefer, but you are 
> strongly advised to create a new boot environment for FreeBSD 14 and 
> also keep the FreeBSD 13 B.E. available for the time being.

Backups are strongly advised. Boot environments (=snapshots) and 
snapshots are a cheap imitation by comparison but get users past most 
problems without having to go through a 'restore from backup' and 'may' 
be quicker by comparison. Backups get you past all the same problems and 
the rest except for backup corruption/failure (backup testing+multiple 
backups fights this). Snapshots are nearly instant to create, simple to 
delete, and only take a bit more disk space than the newly written 
blocks after such snapshots are made so having them is good if not too 
tight on free space.

> * Do whatever testing and qualification you require until you are 
> confident the FreeBSD 14 upgrade hasn't resulted in bugs or regressions 
> for your use-case.  At minimum, just use FreeBSD 14 for a few days and 
> look out for any problems.
> 
> * Once you're sure you're never going to need to revert back to FreeBSD 
> 13, update the bootblocks / efiboot to the version from FreeBSD 14.

The new boot loader gains knowledge of how to access the new ZFS pool 
feature sets but does not lose knowledge of how to access the old ones. 
You can continue to use a new loader just fine if you do go back. This 
step is safe to do sooner; if there are any bugs in the new boot loader, 
you will not find them until this step. If a new boot loader had a bug, 
you would have to install an older, or newer (fixed) boot loader 
anyways, and probably by booting from separate media as I suspect you 
found the issue by not being able to boot.

> * Now you can apply the `zpool upgrade` This will make any FreeBSD 13 
> Boot Environments you may have unusable, so those can be deleted.

Boot environments do not contain the booted copy of the boot loader as 
zfs does not contain the booted copy. Booting takes place from non zfs 
sections either being mbr bootblocks or efi's fat filesystem bootblocks. 
Neither of those areas is ever a ZFS pool. The kernel (well, just its 
zfs module) may not be happy but you could always give it an install of 
sysutils/openzfs. It is easiest to install such programs while the 
discussed system boots, so before the pool upgrade. Not doing so would 
require installing the package/port when booted from separate media.

Further bootloader updates need to come from a boot loader that 
understands the newer pool features; installing a bootloader from 
FreeBSD media that contains that same version, or newer, of ZFS is 
'usually' adequate but there can be times where pool features exist that 
are not part of a boot loader yet.

> For updating the bootblocks on a MBR system, see gptzfsboot(8) and the 
> 'bootcode' subcommand of gpart(8).
> 
> For updating efiboot, see efibootmgr(8) and the 'Upgrading from Previous 
> Releases of FreeBSD' in the release notes: 
> https://www.freebsd.org/releases/14.0R/relnotes/
> 
> Now, it may or may not be possible to revert an upgrade to the zpool -- 
> some property settings can be removed if they haven't been used yet, 
> some can't.  So trying to revert a `zpool upgrade` is not something you 
> should count on being able to do.  Take a look at the zpoolprops(7) man 
> page for the details.

If you need that revert feature, you need to use zpool-checkpoint(8) 
instead of snapshots. Presuming no major destruction, you can then roll 
a pool back to a previous state including undoing new properties being 
activated+used. This was how pools with block cloning corruption were 
fixed without restoring from backup. It is a different workflow than 
snapshots and comes with some limitations. Checkpoints and shapshots are 
not a replacement for proper backups.

>      Cheers,
> 
>      Matthe