Why updating my Fedora kernels is a complicated multi-step affair

September 30, 2018

I tweeted:

Ah, the delicate yak shaving dance of updating my Fedora system's kernel. Life will be easier when WireGuard is in the upstream kernel. (It would be even easier if ZFS in the upstream, but that's sadly probably never going to happen unless Oracle gets very strange.)

You might wonder why updating the kernel is such a complicated thing for me. Part of the answer is that updating the kernel is, in one sense, not complicated at all. If all I want to do on my home machine is update the kernel by itself, all I need to do is run 'dnf update "kernel*"' and then wait a while as the RPMs are installed and then DKMS rebuilds the kernel modules for WireGuard and ZFS on Linux for me. In this sense, having both upstream in the main kernel wouldn't really change anything (although it would mean no DKMS rebuilds).

But usually this is not all that I want to do, because I'm almost always taking the opportunity of a kernel update to also update WireGuard and ZFS on Linux. I get WireGuard from its Fedora COPR repo, where it updates pretty frequently; there's almost always at least one update by the time there's a new Fedora kernel. ZFS on Linux makes new releases only infrequently, but I don't run release versions; instead I use the latest development versions straight from the ZoL Github repo, where it sees ongoing development.

(It appears that WireGuard currently updates roughly once a week. There have been four updates this September, dated the 4th, the 10th, the 18th, and the 25th.)

Once I'm updating additional DKMS-based packages, DKMS adds its own wrinkle here, because you need to force things to update in the right order. If you install a new kernel in Fedora, part of the kernel updates insure that DKMS will rebuild all current DKMS modules for the new kernel. But if you install or update a DKMS based package, the Fedora setup only has DKMS (re)build kernel modules for the current kernel, not for any kernels that you may have installed and be waiting to reboot. So if you're going to update some DKMS packages and also your kernel, you must update the DKMS packages first and the kernel second.

So my whole update process looks like this:

  1. Sync up my local ZFS on Linux build repo and build new RPMs.
  2. Use 'dnf update zfs/*.rpm' to install the new version, which (slowly) builds the new DKMS kernel modules for my current kernel.
  3. Do 'dnf update "wireguard*"' to update the WireGuard packages, which will build its new kernel module for my current kernel.
  4. Finally do 'dnf update "kernel*"', which installs the new kernel and has DKMS rebuild the just-installed new ZFS and WireGuard kernel modules for the new kernel.

When WireGuard goes into the kernel, what will be different is that it will stop changing so much, or at least the version I use would stop changing so much because it would be whatever version was in the Fedora kernel. The same would be true if ZFS was somehow put into the Linux kernel; I would stop running the latest development version and just stick with whatever the Fedora kernel had.

So, really, I've done this to myself. I could run a released version of ZFS on Linux, which would basically stop that from updating all the time, and I could probably just freeze my WireGuard version for a month or two if I wanted to.

(Updating the kernel on my work machine takes an extra step because I have not yet put in the effort to DKMS-ize the special kernel modules for VMWare Workstation, so I have to run a couple more commands to rebuild them every time. These days I can at least do this before I reboot into the new kernel; I used to have to reboot into the new kernel, rebuild the modules, and then reboot again to get everything fully activated with the right magic.)

Written on 30 September 2018.
« Addressable values in Go (and unaddressable ones too)
My Firefox addons as of Firefox '64' (the current development version) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 30 00:21:55 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.