Ran zpool upgrade, need to update boot code?

[franco]

> For good measure, I'd never run zpool upgrade on OPNsense because it brings virtually nothing useful, only potentially makes your system not bootable any more.

I second that. Ironically enough the FreeBSD 14.0 release notes[1] state:

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.


Cheers,
Franco

[1] https://www.freebsd.org/releases/14.0R/relnotes/

[cookiemonster]

You only need to update either BIOS or UEFI, because your specific system only uses one. But just for good measure, I would always update both types.

Of course. As I said, in an emergency having both in the fs just adds to the elements to consider.

I for one like that the images provided by OPN have both EFI and legacy BIOS so a single download/image can be used on either type of system. That said, I agree a documentation could be enhanced to better inform, because it is very true that once installed, it's hard to know in an emergency and needs to update both.
I suppose the alternative to provide each image X 2, one for BIOS and one for EFI could deal with it in another way.

Not sure what you meant to say but we actually do have both images and installation being dual-boot? Serial, vga, dvd plus the hybrid ZFS or UFS install modes...


Cheers,
Franco

Yes exactly. Each is dual.

[doktornotor]

but updating the boot loader can avoid making the system unbootable if the pool is upgraded in the future.

Lol... seems kinda the other way round. Pretty much everyone (FreeNAS/TrueNAS, NAS4Free/XigmaNAS explicitly advises against upgrading the root pool feature flags -- since it only causes breakage.

[meyergru]

Everyone has their reasons to do one thing or another. By reviving this thread, I only wanted to make it clear that it is really dangerous to "just" update the zpool features, which was not what I got from the thread so far - however dumb the move may have been on my part in the first place.

While it was clear to me that I give up backwards-compatibility by upgrading the pool (i.e. I cannot use that pool with an older ZFS/kernel version), I was not aware that the boot files are never getting updated by the OpnSense upgrade process. This is totally different with most Linuxes that use ZFS, like with my Proxmox host and the negative outcome would be prevented if that was the case for OpnSense as well, and thus I made a feature request.

I also was not aware that this is already being discussed upstream and Franco is waiting for a fix there.
However, OpnSense's approach is a little different from standard FreeBSD, by using both an EFI and a GTPBOOT partition as is indicated by the different partition index 2 for updating gptzfsboot.

[Patrick M. Hausen]

I was not aware that the boot files are never getting updated by the OpnSense upgrade process. This is totally different with most Linuxes that use ZFS, [...]

Neither does FreeBSD update the boot loader - legacy boot or EFI - when the OS is updated. And the devs are aware that this is a problem waiting to turn into a disaster happening to the unsuspicious admin. There is just no one-size-fits-all solution, yet. Not even a clear consensus about the right approach, if I am not mistaken.

Before the proliferation of EFI the `zpool upgrade` command would print a message with the more or less correct gpart invocation to update the boot loader. This message was removed because today it is in itself dangerous - if followed by the letter without thinking people will overwrite their EFI partition with gptzfsboot.

I'll report back from EuroBSDCon in September

With most Linux distributions it's "everything is GRUB", so much less opportunities for error. Caveat: if you follow the OpenZFS howtos to install e.g. Debian with ZFS boot and root, never upgrade your boot pool! The version of GRUB in Debian cannot boot with all feature flags enabled. GRUB is notoriously lagging behind ZFS development.

One might be tempted to use ZFSBootMenu instead, but then you are on your own again.
https://github.com/zbm-dev/zfsbootmenu