Latest fedora kernel-devel wants to remove zfs and libvirt?

Software & Operating Systems Linux
,
1

well this seems disturbing…

Installing:
 kernel-devel                                 x86_64            5.16.8-200.fc35               updates              15 M
Removing:
 kernel-devel                                 x86_64            5.15.18-200.fc35              @updates             61 M
Removing dependent packages:
 libvirt                                      x86_64            7.6.0-5.fc35                  @updates              0
 libvirt-daemon-driver-storage                x86_64            7.6.0-5.fc35                  @updates              0
 libvirt-daemon-driver-storage-zfs            x86_64            7.6.0-5.fc35                  @updates             24 k
 zfs                                          x86_64            2.1.2-1.fc35                  @zfs                1.7 M
 zfs-dkms                                     noarch            2.1.2-1.fc35                  @zfs                 62 M
2

It may be that the DKMS is not compatible with the new kernel.

2 Likes
3

Looking at the dependencies, it’s the ZFS group to blame. They recently updated zfs-dkms to require Linux 5.15.999 or older. That’s after my system had already been running 5.16 for several weeks. So any update operation was triggering removal.

Libvirt depends on libvirt-storage-zfs which depends on the zpool command, so that’s why it’s trying to uninstall as well.

The fix was to manually download and install kernel--5.15.18-200 rpms and then exclude kernel-* in dnf.conf going forward.

3 Likes
4

I guess that’s why Pop!_OS hasn’t updated their kernel to 5.16?

5

That sounds messy. I wonder why they did that. Is ZFS mainly targeting LTS kernel releases? It may be wise to stick to an LTS if so.

2 Likes
6

And this shit right here is why ZFS on linux is a second class citizen (that I will never use in production), whereas on FreeBSD (or any of the Illumos/OpenSolaris derivatives) it is not.

1 Like
7

So many people argued with me about this and I was like, “Hey, I love GNU/Linux as much as you do, but use the right tool for the job.” There is a reason why I run BSD, Solaris, and GNU/Linux in my home. BSD/Solaris is great for networking and Storage, bar none and those tools are first class citizens in that echo system.

Now if ZFS targets LTS Linux kernels, then it would be wise to stick to LTS if you value your data. IF ZoL pulls this type of stunt on LTS systems, well, BSD and Solaris are not that hard to learn.

2 Likes
8

Look at the utility yum-plugin-versionlock.

The utility creates a txt file with the rpm version string and places it in /etc/yum/pluginconf.d/versionlock.list. This list can be managed by Saltstack or Ansible or other build tools.

Upon every update it tells you how many packages are held due to the versionlock and is more clear than just holding the version in the main conf file.

This is one mechanism for how we control kernel updates at work.

3 Likes
9

Didn’t ZFS have some major breakage starting with the 5.16 kernel, and hasn’t been fully patched?
That’s been my understanding. Too bad, too, since there’s finally been an update to the ALX WOL patches that tbqh shouldn’t even be necessary as the ALX WOL bug was always implementation specific, non-critical, and in many cases not even related to or triggered by WOL.

10

Looking at the issues on the openzfs GitHub that appears to be the case. It was quite a battle to get my Fedora machine back to 5.15.

I will definitely check out the suggestion from @Dynamic_Gravity … Sounds cleaner than just a wildcard exclusion of kernel-*