EL8 DKMS packages still at 2.0.6

[markusdd]

It seems that the official DKMS src.rpms are still at 2.0.6, while official releases here have already moved to 2.0.7 or even 2.1.4 respectively, which seem to contain a lot of important fixes.

Is my repo setup outdated/broken or is there indeed such a release lag?

Is there a web page where one can brwose the repositories? I am getting access denied when trying to open the repo in the browser.

[rincebrain]

The AWS buckets backing it do not have browsing enabled, no. I'd find it convenient if they did, but such it is.

Often when people encounter this, it's because they don't realize that they need to update their repo file as they update point releases of RHEL-alikes, or they won't get the newer versions (I don't control them, but IIUC they used to try to autodetect what you were on but that was surprisingly brittle). The other thing that surprises people is that (AIUI) the "zfs" repo contains some stable release version (often one major release behind) and the "zfs-testing" repo contains the latest stable release at the last time the ELx.y version was current (so for example, 8.1 is never going to get 2.1.4 prebuilt - you can build it, it'll work, but it's not in the repo).

[tonyhutter]

I ran though the steps in the docs (https://openzfs.github.io/openzfs-docs/Getting%20Started/RHEL-based%20distro/index.html), and successfully installed zfs-2.0.7 DKMS on Almalinux 8 (open source RHEL8):

$ rpm -qa | grep zfs-dkms
zfs-dkms-2.0.7-1.el8.noarch

$ cat /etc/centos-release 
AlmaLinux release 8.5 (Arctic Sphynx)

The src dkms RPM is there as well: http://download.zfsonlinux.org/epel/8.5/SRPMS/zfs-dkms-2.0.7-1.el8.src.rpm

[markusdd]

ok after putting in 8.5 I indeed see 2.0.7, but still no 2.1 series.

Also, why is this even needed for the DKMS packages? I totally understand for the prebuilt kmods, but with DKMS a generic EL8 repo should do? Or am I missing something?

[tonyhutter]

If you enable the zfs-testing repo, you'll get the newer 2.1.x RPMs on Centos.

Yea, we could (and should) just have one repo for DKMS. I think it's just force of habit that we make a new one just like we do with the kmods. Maybe when the next Centos 7/8 minor release happens, and we generate a new zfs-release RPM, we can make the DKMS RPMs point to a single repo.

[tonyhutter]

We switched CentOS 8 over to the 2.1.x branch when zfs-2.1.4 came out. That means that CentOS 8 is getting 2.1.x for the regular zfs repo. You no longer need to use the zfs-testing repo to get 2.1.x on CentOS 8.

We also checked in a universal zfs-release RPM that will work for all versions of CentOS. That saves you from having to download a new zfs-release RPM for each minor version of Centos (8.4, 8.5, 8.6, etc). See https://github.com/zfsonlinux/zfsonlinux.github.com/pull/67 and https://github.com/openzfs/openzfs-docs/pull/325

I recommend we close this issue.

[markusdd]

I can confirm now that the generic release RPM work as intended. Thanks a heap for that!

There is one issue still remaining though, I guess it is a 'hole' in the current scripting:

After installing the release rpm and running dnf install zfs (assuming the standard DKMS mode), DKMS is not being triggered to build the kernel module for the current kernel, meaning ZFS is not available.

You then have to manually dnf remove kernel followed by dnf install kernel to trigger the build (because DKMS triggers on installation of a new kernel). Upon installation, the zfs package must ensure that a dkms install is triggered so taht the currently running kernel gets the modules built and installed.

[rincebrain]

I believe commonly DKMS triggers on next boot of a kernel if the module isn't present, in addition to on a kernel changing.

I personally am not sure we would want to force DKMS to trigger (and therefore, block the package install process until finished building ) on installing zfs-dkms on a running system - I know the Debian packages do this, but I could see people being rather discontent to discover they need to wait O(minutes) for a package to install, and setting up something like a oneshot cron job or equivalent to trigger it before next reboot without blocking and clean up after itself gets increasingly convoluted.

[markusdd]

I tried exactly that and there was no automatic build on reboot.

And generally I'm not sure if the argument holds for the install-time, because at some point you have to spend it.

Just judging from what I just witnessed, my user experience was much worse with the current situation because after I run 'install zfs' I expect it to be available and not being greeted by 'your kernel module is missing' messages, which then recommend to 'modprobe' it, which of course also fails. And after it is installed, you will have that 'hang' on each and every kernel update, that is eactly how it works and how DKMS is intended.

So my take on the subject: The current experience is definetly not right, because it just does not work at all, not even with a reboot. So anyone using that will get sent on a google-session on how to trigger a manual DKMS rebuild. Also I think designing in an absolute unneccesary reboot in the install process is not something that should be done. Every DKMS package under the sun that I know takes care it gets installed for the current kernel and immidiatel works without rebooting or manually modprobing. I think zfs should follow that convention.

For anyone who doesn't like that: Well use kmod and be done with it.

[rincebrain]

I definitely agree that you should not have to reboot, and I would also say that it not triggering on reboot is a problem, unless I'm really misunderstanding how DKMS is intended to work.

I just don't like putting a blocking build step in the install process where there wasn't one before - I'd be absolutely down for queuing it to build immediately on install, but I don't know offhand of a way to do that within RPM packaging helpers versus just using arbitrary shell scripting and having to manage a backgrounded task yourself.

(IIRC, the other problem, historically, was that you can't require, if, say, you're installing kernel-devel-$NEWVERSION and zfs-dkms at the same time, and already have a kernel-devel installed, that zfs-dkms only be installed and therefore built after kernel-devel-$NEWVERSION is installed, so it would fail on the initial build, and we'd be in the same situation again.)

(Of course, my opinion only matters in that I'm unlikely to try opening a PR to do something I don't think is a good idea...)

On Sat, Jul 16, 2022 at 5:20 PM Markus Krause @.***> wrote:

I tried exactly that and there was no automatic build on reboot.

And generally I'm not sure if the argument holds for the install-time, because at some point you have to spend it.

Just judging from what I just witnessed, my user experience was much worse with the current situation because after I run 'install zfs' I expect it to be available and not being greeted by 'your kernel module is missing' messages, which then recommend to 'modprobe' it, which of course also fails. And after it is installed, you will have that 'hang' on each and every kernel update, that is eactly how it works and how DKMS is intended.

So my take on the subject: The current experience is definetly not right, because it just does not work at all, not even with a reboot. So anyone using that will get sent on a google-session on how to trigger a manual DKMS rebuild. Also I think designing in an absolute unneccesary reboot in the install process is not something that should be done. Every DKMS package under the sun that I know takes care it gets installed for the current kernel and immidiatel works without rebooting or manually modprobing. I think zfs should follow that convention.

— Reply to this email directly, view it on GitHub https://github.com/openzfs/zfs/issues/13417#issuecomment-1186295649, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUI7M4TSVGNZV3XU5XMKLVUMRRLANCNFSM5VBYEPKA . You are receiving this because you commented.Message ID: @.***>

[markusdd]

I think ultimately it boils down to the fact that basically anyone who does an 'install zfs' would expect zfs to work after that, which it does not right now. So either we need more steps in the docs, or we need to make sure zfs is available after the installation via dnf.

[rincebrain]

Absolutely - I'm not trying to say I think the status quo is okay, just debating what the best way forward is.

I'm not sure, but I think this also used to not be the case - though most of my CentOS and the like testing for some time has been "build package from git, install immediately", so I can't swear how long ago that was, but I don't think the instructions historically required more work.

...so, I just tried it in my freshly updated Alma 8.6 VM, and on installing freshly built zfs-dkms 2.1.5 DKMS and utils packages from source, it did indeed go build the kernel modules in a blocking fashion. Maybe that's not triggering on upgrade?

On Sat, Jul 16, 2022 at 7:03 PM Markus Krause @.***> wrote:

I think ultimately it boils down to the fact that basically anyone who does an 'install zfs' would expect zfs to work after that, which it does not right now. So either we need more steps in the docs, or we need to make sure zfs is available after the installation via dnf.

— Reply to this email directly, view it on GitHub https://github.com/openzfs/zfs/issues/13417#issuecomment-1186319937, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUI7LQVGYNT6CAZ2R4FKLVUM5T3ANCNFSM5VBYEPKA . You are receiving this because you commented.Message ID: @.***>

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.