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

[Unspec]

Er, what happens if you run zfs upgrade zroot and THEN update the bootloader? Are you screwed?

[franco]

It's a safety precaution doing it in this order. If you update the boot code the old zroot still boots. The other way around you need to do both otherwise it stops booting. For whatever reason zfs-upgrade could potentially fail to run cleanly.


Cheers,
Franco

[ezra55]

If the worst has happened and your system does not boot any more, you can either reinstall OpnSense from scratch or create a FAT32/VFAT USB stick with a correct loader.efi and copy that to the EFI partition into the correct locations (this is tedious, however). IDK how to fix it with BIOS boot.

Boot a FreeBSD 14.1 CD/DVD image, escape to shell, use the same gpart command you gave above to install the boot loader.

Similar for EFI:

Code Select Expand

mount -t msdosfs /dev/da0p1 /mnt
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
cp /boot/loader.efi /mnt/efi/freebsd/loader.efi
umount /mnt

Yup. After having someone at the remote site connect a display, keyboard and having no FreeBSD iso (and no CD-ROM either). I had to prepare a USB stick for download. Then, they had no internet to download that. Then, they had a Mac and no USB stick... been there, done that - not funny in any case.

I opened a feature request, although I know it was my own fault...

I would sincerely like to thank you both for saving my life with your info... Upgrade broke my system and it seemed the backups stopped a while back, still get cold shivers thinking about it.

Also this uncovered that my zfs mirror wasn't properly working and the mirrors p1 was faulty, after copying the files a DD from the working p1 to the faulty fixed that as well.

Thank you!