Hello,
based on the following document:
https://docs.rockylinux.org/books/lxd_server/01-install/
it seems it’s mandatory to upgrade the system, and reboot if new kernel is installed, each time ZFS is installed from zfsonlinux.org.
My systems are installed with tools like “salt” and “vagrant” and I would like to avoid to reboot the system to install ZFS.
Is there a procedure that allow to install ZFS without the need to reboot?
Thanks
Andrea
Good day @acucciarre,
Everything that I’ve read strongly recommends a reboot after the kernel update. There may be a way to do this without a reboot, but I’m not aware of the method.
If this is to run an LXD server (per the document you referenced above) then you can go with another filesystem type. The latest LXD server docs now don’t mention ZFS and instead key on btrfs. In short, you don’t have to use ZFS for an LXD server.
I’ve been going to do some additional tests with btrfs and LXD, but I need another machine to test snapshots with to do that. I may try a rebuild with btrfs w/o the snapshot server.
Thanks,
Steve
Installing a new kernel does not automatically take it into use. There are some system libs,
like glibc, that have the same issue. Red Hat documetation describes test utility
needs-restarting -r (from package yum-utils) that tells whether to reboot after dnf up.
Some distros do have “kpatch” that modifies currently running kernel. (Changes kernel without reboot.)
That is a different question. ZFS has kernel module(s) (filesystem drivers).
A point of modular kernel is that modules can be loaded during runtime (modprobe).
That page did mention kernel settings, which can be changed during runtime (sysctl).
Finally, there is a service? Services can be stopped and restarted.
As such, one might be able to enable ZFS support on a running system; reboot is just the trivial method.
“Longest runtime since boot” is not a glorious achievement. You want to reboot whenever that takes new security patches into use. In practice, you do want quick and painless reboots. I know, some of our systems seem “too important” to boot.
What if they break in regular use? That can happen too. Then the valuable services are down for sure.
If you can cope with that, then a reboot now and then should be unnoticeable.
Installing ZFS without rebooting is just a matter of making sure that the version of the modules you install are compatible with the running kernel rather than latest. That said, jlehtone is correct, and you will thank your past self for ensuring ahead of time that your system will come back up into a working state after an unplanned reboot.
@jlehtone and @quartsize Reason I am asking is that it’s not the first time for my systems that ZFS module probe fails with error after ZFS installation, and I have to update, reboot and install it again.
So it seems to be mandatory to update and reboot to make a successful ZFS installation.
The following link is used in that document for installation:
https://zfsonlinux.org/epel/zfs-release-2-2.el8.noarch.rpm
and as far as I can see it links to the ZFS for the latest 8 minor release, so currently 8.7.
If I look in zfsonlinux github we have the ZFS for all minor releases.
There we have also zfs-release.el8_6.noarch.rpm
So it seems to me that document to install ZFS on Rocky linux works only for the latest 8 minor release (8.7 currently), it fails if you install ZFS on 8.6.
That makes sense to me. It’s typical that staying up-to-date with patches is the only ~supported~ configuration, so it seems reasonable that the Rocky project would only document how to install ZFS on latest.
I just booted a Vagrant machine with kernel 4.18.0-372.16.1.el8_6.0.1.x86_64, installed kmod-zfs-2.1.6-1.el8.x86_64 from http://download.zfsonlinux.org/epel/8.6/kmod/x86_64/, and loaded the module without rebooting. In fact, since the zfs-release-2-2.el8.noarch package uses $releasever, you can do the installation specifying dnf --releasever=8.6 to use the old repository.
But it gets complicated quickly. If you have EPEL repos installed, they won’t work with that releasever, so you add a flag to temporarily disable them. But a user might have other similar repos on their system that also need disabled. Or they’re running an older kernel within the same minor EL release that the latest version in ZFS’ repo for that minor EL release doesn’t support, and they need to first make that determination and then specify to install an earlier version from that repository.
Maybe if someone is willing to write all that up, the Rocky project would accept a documentation patch. But I’d understand if they don’t want to complicate the documentation to help folks do a thing (i.e. stay on older releases) that’s generally not advisable.