RPM: Explicitly set the required min/max kernel version for the DKMS

[awehrfritz]

Motivation and Context

Some RPM-based Linux distributions are either on a rolling-release schedule or adopt new kernel releases very quickly (e.g. Fedora Linux). While OpenZFS typically incorporate patches for the latest Linux kernel (or even development version), quite often there is a delay between kernel releases and ZFS releases that contain compatibility patches for the latest kernel. For instance, with kernel 5.11 being end-of-life and Fedora 34 rolling out kernel version 5.12, ZFS users manually need ensure their systems don't update to the latest kernel since the latest stable ZFS release (2.0.4) does not yet support kernel 5.12. This minor tweak to the rpm-spec file ensures that the kernel packages are not update to versions not yet supported by the latest ZFS release.

Description

The changes comprise a minor tweak to the rpm-spec file which ensures that the kernel packages are not update to versions not yet supported by the latest ZFS release. The information in the rpm-spec file is obtained from the META information during the configuration step.

How Has This Been Tested?

Tested locally on my Fedora 34 Linux system

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

Actually specifying the supported kernel versions as part of the DKMS dependencies is a great idea.

[dioni21]

Hey, this is blocking me to upgrade kernel from 5.12.10-300 to 5.12.11-300 on Fedora fc34

Is it expected? If I let dnf upgrade run, it will remove all zfs kernel packages.

I can upgrade excluding kernel-devel, but this will break other modules, like nvidia and VirtualBox.

================================================================================
 Package         Arch      Version                       Repository        Size
================================================================================
Installing:
 kernel-devel    x86_64    5.12.11-300.fc34              updates           14 M
Removing:
 kernel-devel    x86_64    5.11.21-300.fc34              @updates          56 M
Removing dependent packages:
 zfs             x86_64    2.1.99-313_g83ba91adf.fc34    @@commandline    3.2 M
 zfs-dkms        noarch    2.1.99-313_g83ba91adf.fc34    @@commandline     62 M
 zfs-dracut      noarch    2.1.99-313_g83ba91adf.fc34    @@commandline     40 k

Transaction Summary
================================================================================
Install  1 Package
Remove   4 Packages

And I've been using it on kernel 5.12 for some time now. Shouldn't META also be upgraded?

[awehrfritz]

@dioni21 it appears that you are still on version 2.1.99 which was released somewhere between RC3 and RC4, and does not contain the changes in this PR, so this does not apply to your case.

In fact, there is currently no stable ZFS release which supports Linux 5.12. I hope that @tonyhutter will release the next point release in the 2.0.x series soon in order to get all Fedora, Arch, Gentoo, OpenSUSE users to a supported kernel again (Linux 5.11 is EOL for a few weeks no already).

If you feel adventurous you can test the latest release candidate for 2.1.0 (2.1.0-rc7) which contains this patch as well as support for Linux 5.12. As you are already on a pre-release version, that might indeed be your best option here.

[dioni21]

@awehrfritz I try to always be in master, as current as possible. The last one I compiled is
commit c4c162c1e8ff9ce8833014711875d18df520096c (HEAD -> master, origin/master, origin/HEAD)
So, yes, it applies to my case.

The fix was to edit META. I could submit a PR, but it is very simple:

diff --git i/META w/META
index b97858eed..2ea3a7300 100644
--- i/META
+++ w/META
@@ -6,5 +6,5 @@ Release:       1
 Release-Tags:  relext
 License:       CDDL
 Author:        OpenZFS
-Linux-Maximum: 5.11
+Linux-Maximum: 5.12
 Linux-Minimum: 3.10

BTW: There was not, and never will be a release named 2.1.99. This is an internal release number to make sure every build from sources is "newer" than releases. IMHO, this fix should be committed before 2.1.0 release.

[awehrfritz]

@awehrfritz I try to always be in master, as current as possible. The last one I compiled is
commit c4c162c1e8ff9ce8833014711875d18df520096c (HEAD -> master, origin/master, origin/HEAD)
So, yes, it applies to my case.

Hmm, you indicated in your previous message that you are on release 2.1.99-313_g83ba91adf.fc34. If that is not the case, then please state your correct version number and commit if you run into similar issues in the future. I guess the confusion with this stems from the fact that version 2.1.99 has an actual tag (https://github.com/openzfs/zfs/releases/tag/zfs-2.1.99), but indeed no release. It seems to me that tag was an oversight and should be removed.

The fix was to edit META. I could submit a PR, but it is very simple:

This has been fixed already over a month ago with RC5:

zfs/META

Line 9 in 3de7aeb

Linux-Maximum: 5.12

The master branch though is indeed missing that update. If you can submit a PR to rectify this, then you can discuss any potential issue with the developers there. But as far as this PR is concerned, I don't see an issue here.

[dioni21]

Hmm, you indicated in your previous message that you are on release 2.1.99-313_g83ba91adf.fc34.

This means a RPM build from commit 83ba91a

commit 83ba91adf6c0b4b1a5b0f0a6f3e84d267e689915
Author: наб <[email protected]>
Date:   Mon Jun 14 17:48:53 2021 +0200

    systemd: import: expand $ZPOOL_IMPORT_OPTS correctly

I have upgraded again since, to check if a fix has already been placed.

version 2.1.99 has an actual tag (https://github.com/openzfs/zfs/releases/tag/zfs-2.1.99), but indeed no release. It seems to me that tag was an oversight and should be removed.

That tag is just to indicate when master has deviated from 2.1.0, as the commit 9ac82ca indicates:

Increase the version to 2.1.99 to indicate the master branch is
newer than the 2.1.x release.  This ensures packages built from
master branch are considered to be newer than the last release.

The fix was to edit META. I could submit a PR, but it is very simple:

This has been fixed already over a month ago with RC5:

Yes, in rc5, just not in master, that is the main branch.

I don't see an issue here.

Ok.

[behlendorf]

This was indeed an oversight, Ive updated the master branch to bump the maximum Linux version.