Closed DasSkelett closed 2 years ago
I've backported this to my COPR package for Jool and tested it on another server (also F35 Linux 5.17) and it works there as well.
# dkms status
jool/4.1.8, 5.16.20-200.fc35.x86_64, x86_64: installed
# dnf update
...
# dkms build jool/4.1.8 -k 5.17.6-200.fc35.x86_64
...
# dkms install jool/4.1.8 -k 5.17.6-200.fc35.x86_64
...
# dkms status
jool/4.1.8, 5.16.20-200.fc35.x86_64, x86_64: installed
jool/4.1.8, 5.17.6-200.fc35.x86_64, x86_64: installed
(Had to specify the kernel because it's currently booted with the 5.16 kernel to have a working Jool)
Sorry this took so long. Everything looks OK; none of the supported kernels was negatively affected. Thank you for your work!
Problem
See #379, I encountered a bunch of kernel module build failures on Fedora 35 with 5.17 kernels.
They are all in places where there was a placeholder 9999 specified for the
RHEL_MAJOR
in the kernel version check.Changes
Since at least kernel 5.16 the underlying kernel patches (e.g. the renaming of
nf_reset
tonf_reset_ct
etc.) are also present in the Fedora 35 & 36 kernels. However the 5.16 series did not haveRHEL_RELEASE_CODE
and other RHEL_ veriables defined for whatever reason and theLINUX_VERSION_AT_LEAST
/LINUX_VERSION_LOWER_THAN
conditional helpers handled them as "stock" kernels. This made DKMS compilation still work.The 5.17 kernels however do have
RHEL_RELEASE_CODE
defined again, thus the build fails becauseRHEL_MAJOR
is 9, far from 9999.Now the version checks are updated to AT_LEAST / LOWER_THAN (a, b, c, 9, 99).
This has only been tested with Fedora 35 5.16 and 5.17 kernels. I assume that the RHEL and CENTOS distros have the same set of backports/patches when marked as 9.99+.
x.99 seems to be the version code of the development tree before a stable RHEL x+1 drops, so I assume that 9.0-98 did not have these patches yet. But I find the Red Hat kernel versioning system really confusing, if someone knows more and I'm wrong please let me know.
Fixes #379