(a)kmods, dkms, and rpm-ostree

[andrewgdunn]

Realizing that this is a distribution specific ask, the answer may easily be no in the sense that dkms works across multiple distros and this enhancement would be specific to the Fedora rpm-ostree install base. This might be a small community, but I'd wanted to make a sort of tombstone here for others to peep at (in case there are more of us).

Use of OpenZFS with rpm-ostree would be an extremely nice feature. There is difficulty with the dkms approach to packaging with rpm-ostree.

Would it be possible to consider use of akmods to allow OpenZFS to chart against faster moving Kernels and immutable installs? This would allow for the package to be rebuilt as people try out new/different kernel compositions.

It seems like the groundwork is in place for kmod builds with zfs-kmod and srpm-kmod build targets but I'm unsure of how to take it further to utilize with ostree.

There are some discussions in other areas online, referencing them here:

• Implement compatibility with DKMS (Nvidia, etc.) coreos/rpm-ostree#1091
• https://bugzilla.redhat.com/show_bug.cgi?id=1667014
• https://blogs.gnome.org/alexl/2019/03/06/nvidia-drivers-in-fedora-silverblue/
• https://github.com/varasys/corezfs
• Some discussion on the rpmfusion mailing lists

[gdevenyi]

#10333

[jmpolom]

@gdevenyi I noticed in that thread several mentions generally about some things not being supported because of a lack of effort to maintain them. I think in the case of an akmod package for fedora, my organization could justify contributing effort to maintain such a package. However right now it looks like the build system lacks support for generating an akmod package, so there would be some development necessary.

I want to add a link to a comment in closed issue #9891 where someone showed a patch that appears to enable building an akmod package. It seems like most of the bits and pieces are here to do this, but it just hasn't been done (for one reason or another).

[xrishox]

would really appreciate the ability to use zfs inside of silverblue.

[jmpolom]

It is possible to use zfs on OS's that use ostree/rpm-ostree but it requires building the zfs kmod package for the particular kernel the system is on.

However in my testing (using Fedora IoT's ostree and manifests) I've found that these packages don't seem to function correct if they're layered onto the ostree -- they must be included when the ostree is built. I don't fully understand why that is because as a logged in user you can clearly navigate to the kernel modules and observe their presence on the filesystem.

A pre-requisite for any akmod support is to understand why layering on a kmod package doesn't seem to work. The akmod process builds kmod packages and installs them. The reason this issue is asking for akmod support is because it enables automatically rebuilding kmod packages when kernels change. This is contrast to dkms which just builds the raw module files and sticks them somewhere.

I'd really appreciate some thoughts as to why layering on the kmod rpm using rpm-ostree results in modprobe not being able to find the module. I'm not an expert on how ostree actually works and suspect it may have to do with the details of how the final layered filesystem is composed.

[mcheshkov]

I managed to get working ZFS kmod on Fedora CoreOS. Here is gist I use to build kmod package for specific kernel version
https://gist.github.com/mcheshkov/69dfc70fd1ec5bdb875105979c20b75b

Beware, this is not well-tested packages by any means, but I use them for my personal NAS.

Main issue I encountered was System.map placement - on CoreOS it is located elsewhere, default %post script generate it in /boot. IIRC, script couldn't write there during install on rpm-ostree system, but otherwise package installed normally. After reboot system use old modules map, which is why zfs.ko itself is there, but modprobe failed to find new module.
https://gist.github.com/mcheshkov/69dfc70fd1ec5bdb875105979c20b75b#file-patches___0001-zfs-kmodtool-system-map-path-patch

[jmpolom]

@mcheshkov that's some really great info there. Your build script is very clean. Completely forgot to check if System.map was getting updated when I loaded the module.

I took a look at the current kmodtool source and I see there's some conditional logic where your patch made changes. Looks like this change was added in April of 2021. Have you attempted without your patch since?

[mcheshkov]

#11836 didn't make it to release, and I haven't tried yet to build master.

[jmpolom]

I see now that it wasn't included in 2.0.6 which is what I tested building. Looks like the tag 2.1.1 contains the change so perhaps I will try building at that point or from master. Great info either way.

This does not specifically address akmod support though which would require adding support to openzfs for building another package type for Red Hat/Fedora type systems. That was the original genesis of this issue. However this is absolutely some great work that would be needed to get that working on ostree-based systems.

[i2]

Is there any update on this? Any prospect of it being implemented?

[anthr76]

Just a friendly ping on this issue. Anywhere I can pitch in?

[BlauerHunger]

Any progress on this? I'd really like to use zfs on new systems, but no akmod available is a showstopper for me since dkms does not work (and probably never will due to its design) with rpm-ostree. This 2 years old patch seems to go into the right direction, but I don't want to be required to patch and rebuild zfs on production systems.

Especially since Fedora IoT, which is rpm-ostree based, is an official Fedora Edition by now, this is a growing problem for admins who'd like to use zfs but can't.

[francoism90]

I'm running Silverblue, any update on this?

Would be great if ZFS could be supported somehow. :)