Updating to latest zfsbootmenu

[skinlayers]

Hello!

What is the best way of upgrading to the latest zfsbootmenu after installing?

I was digging through the script it looks like systemsetupFunc_part4() contains most of the relevant parts, particularly in compile_zbm_git() and config_zbm(). Would it be enough to run those function, followed by update-initramfs -c -k all && generate-zbm --debug? Would update_boot_manager() also be required?

Thank you!

[Sithuk]

Hi skinlayers,

Running compile_zbm_git and then config_zbm should work. You shouldn't need to reconfigure or reinstall rEFInd. It should pickup the new files automatically.

Alternatively, you could try downloading one of the pre-compiled zbm binaries from the zfsbootmenu git and drop it into the /boot/efi/EFI/ubuntu directory. rEFInd should pickup the new zfsbootmenu EFI file automatically. That will take a bit of experimenting to see what, if anything you need to alter to make that work.

Regardless of which approach you take, I recommend testing in a virtual machine first. "Should work in theory" has a way of all too frequently not working in practice. You don't want to end up with an unbootable machine.

If you are using remote access (or possibly also multiple ESPs) then there will be more steps required.

Please report back on your testing. It would make a good answer in the FAQ section of the readme.

[joelishness]

Hi, so is there no defined upgrade path?
What is the recommendation? Just install and leave as-is for the life of the system?

[Sithuk]

There is no defined upgrade path, no. Install and don't upgrade to a new Ubuntu version is the recommendation. Running apt upgrade to upgrade packages should work fine.

That said, if you do an in place upgrade to upgrade your ubuntu version (do-release-upgrade), zfsbootmenu should remain untouched on the boot partition and the system should boot fine.

Pyznap isn't in the ubuntu repositories so it might not be present in the new version. If that is the case, then Pyznap can be re-installed manually by following the commands in the "pyznapinstall" function of the script.

I have been thinking of replacing pyznap with another snapshot program that is in the repositories to make version upgrades easier. However, I haven't found another snapshot programme that allows drives to remain asleep when taking snapshots of awake drives.

If you want to update the zfsbootmenu version then you can manually re-install by following the commands in the "zfsbootmenuinstall" function.

[Sithuk]

I just did a test on a fresh 22.04 server install using the script. It upgraded to 22.10. Pyznap and generate-zbm worked fine in the upgraded install. No re-compile and re-install needed. I didn't test an install with remote-access.

[Sithuk]

Having re-read your initial post, it looks like I've misunderstood your question. I think you were referring to an upgrade path for zfsbootmenu only? Not an upgrade path for the distribution as a whole? In that case, I have already set out what the options are in my response to skinlayers above. I'll expand a bit further below.

The zfsbootmenu boot files created and installed when the script is first run should continue to work fine through in-place upgrades of the distro. Zfsbootmenu identifies zfs pools at boot. It then boots from the default or offers options to select which to boot from. That functionality should be unaffected by in-place distro upgrades. What could affect it, is is you upgrade your zfs pool(s) to a newer zfs version that zfsbootmenu does not support. You could be left with an upbootable system. But there are options to run a newer zfsbootmenu from a usb stick to allow you to fix that scenario.

If you do not use remote-access then using one of the pre-compiled efi files from the zfsbootmenu github site is an option to upgrade zfsbootmenu. You don't need to compile anything and can just copy the efi file over to the /boot/efi/EFI/ubuntu folder. rEFInd should pickup the efi file at boot and allow you to select it. I haven't tested this. However, the zfsbootmenu creation software run by "generate-zbm" won't be updated. You'll need to re-compile and re-install if you want to create zfsbootmenu boot files with custom options. Which is why if you need the remote-access functionality then you need to re-compile and re-install zfsbootmenu in order to update it and retain that functionality.

I am thinking of adding to the todo list to add an update feature to the script to allow users to update zfsbootmenu and pyznap following installation. But that will need to wait for another day. I'd be interested in any feedback you have on testing any of the upgrade options above and whether you encounter any problems.

[joelishness]

Thanks very much!
Yes, my inquiry was about updating zbm.
Thank you for your explanation and details, I will give it a try when I have a chance for feedback

[Sithuk]

I've also looked into the following as solutions to the script upgrade issue. Upstreaming zfsbootmenu and pyznap to debian is the best solution, but the most work. Flathub is the next best solution but there is currently a bug in flatpak that has prevented me from creating the flatpaks. I've put more detail below.

Snap: Snaps do not work in a chroot environment, which is how the install script works. So creating a pyznap and/or zfsbootmenu snap and switching the script over to using snaps will not work.
https://bugs.launchpad.net/snappy/+bug/1609903

Flatpak: Flatpaks are designed to work in chroot but there is a bug that currently prevents installation of the required freedesktop environment.
flatpak/flatpak#3238
Flatpak also currently isn't well optimsed to run command line applications, although that issue appears to be worked on.
flatpak/flatpak#1188

Launchpad PPA: I could create deb files and host on a ppa on launchpad. The ppa would need to be added to the apt sources file. The script uses open source sources where the user can verify the content of what is used. Using a third party ppa would require trust of my ppa, which I would like to avoid.

Become a debian package maintainer: This option is the best for the user from an ease of use and trust stanpoint. But becoming a Debian package maintainer is not something I want to undertake at this time.

[satmandu]

Setting up a PPA would be fantastic! It's not that much work....

[Sithuk]

From my post above:
“ The script uses open source sources where the user can verify the content of what is used. Using a third party ppa would require trust of my ppa, which I would like to avoid.”

The issue is one of trust with a third party ppa. I don’t expect users to trust anything they can’t verify themselves. I don’t think launchpad is like AUR where the user can review the code being run to create the file?