Description of problem: If used with some kernels other than rhel the kernel requirement is not correct for the produced kmod RPM. eg: if used with kernel-ml-5.4.2-1.el7.elrepo.x86_64 any produced kmod RPM has a requirement of kernel >= 5.4.2-1.elrepo. Version-Release number of selected component (if applicable): 1-37.el7 How reproducible: Steps to Reproduce: 1. kmodtool --target x86_64 --kmodname 88x2bu --for-kernels 5.4.2-1.el7.elrepo.x86_64 2. Look for the relevant Requires: kernel 3. Actual results: Requires: kernel >= 5.4.2-1.elrepo Requires: kernel < 5.4.2-2.elrepo Expected results: Requires: kernel >= 5.4.2-1.el7.elrepo Requires: kernel < 5.4.2-2.el7.elrepo Additional info: My "works for me" fix is --- /usr/bin/kmodtool.orig 2019-10-13 08:50:11.000000000 -0700 +++ /usr/bin/kmodtool 2019-12-07 07:50:27.478930800 -0700 @@ -213,8 +213,7 @@ fi || : %if 0%{?rhel} -Requires: kernel >= ${kernel_uname_r_short} -Requires: kernel < ${kernel_uname_r_short_plus_one} +Requires: kernel = ${kernel_uname_r_wo_arch} BuildRequires: kernel-devel = ${kernel_uname_r_wo_arch} redhat-rpm-config kernel-abi-whitelists %post -n kmod-${kmodname}-${kernel_uname_r}
Your patch will break normal redhat kernel. Can you check which provides are available for kernel-ml ? rpm -q --provides kernel-ml ?
For kernel-ml.5.4.2-1.el7.elrepo.x86_64 the relevant provides are kernel = 5.4.2-1.el7.elrepo kernel-ml = 5.4.2-1.el7.elrepo kernel-ml(x86-64) = 5.4.2-1.el7.elrepo kernel-ml-uname-r = 5.4.2-1.el7.elrepo.x86_64 kernel-ml-x86_64 = 5.4.2-1.el7.elrepo kernel-uname-r = 5.4.2-1.el7.elrepo.x86_64 kernel-x86_64 = 5.4.2-1.el7.elrepo I guess I should have also mentioned that kmodtool worked for these kernels up to one of the last updates to kmodtool.
Hello, Maybe you should try to replace line 152 of /usr/bin/kmodtool shell script: local kernel_uname_r_short=$(echo ${1} | sed -e "s/\.${target}//" -e "s/\(.*\)-\([[:alnum:]]\+\)\(\.[[:alnum:]\.]\+\|\)\(\.el.*\|\.fc.*\)/\1-\2\4/") with this one (on one line): local kernel_uname_r_short=$(echo ${1} | sed -e "s/\.${target}//" -e "s/\(.*\)-\([[:alnum:]]\+\)\(\.[[:alnum:]\.]\+\|\)\(\.el[0-9]*\(\.elrepo\|\)\|\.fc[0-9]*\)/\1-\2\4/p") Keeping the rest of the file unchanged from the upstream one. My two cents. Feel free to make any comment about this subject. Cordially, -- NVieville
(In reply to dkmalick from comment #2) > For kernel-ml.5.4.2-1.el7.elrepo.x86_64 the relevant provides are elrepo have his own kmodtools IIRC, maybe contact elrepo would be the best . TBH , I hadn't to look to this , but I'd like integrate elrepo work on kmodtool to RPMFusion .
(In reply to Sergio Monteiro Basto from comment #4) > (In reply to dkmalick from comment #2) > > For kernel-ml.5.4.2-1.el7.elrepo.x86_64 the relevant provides are > > elrepo have his own kmodtools IIRC, maybe contact elrepo would be the best . > > TBH , I hadn't to look to this , but I'd like integrate elrepo work on > kmodtool to RPMFusion . I haven't had a look recently, but my bet is that it's not elrepo works (or for limited features), but instead it's based on a fork made by Red Hat ages ago (that was never integrated back to our upstream project). What would have been appropriate to integrate is the move to more sane RPM macros instead of custom bash scripts. At least that's the way forward. @NVieveille, yet again a crazy solution ! You need to assume redhat only in the redhat kernel case (not using %{rhel} which only indicate a redhat userspace). Everything else should be non-redhat kernel (so, it will assume: no kabi support for what this bug is about). Specially, you should not assume a blacklist of case by case situations. Sane solution would be: - consider kernel ml (or lt) as a valid kvariant in kmodtool (I would also add kernel-longterm which I'm using on my own copr) https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/builds/ https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.14/builds/ - Check for appropriate kABI feature in kernel (/boot/config-${KERNEL_UNAME_R} or using symbol while list package availability). - Check for livepatch/kpatch availabilty from /boot/config-${KERNEL_UNAME_R} (but this bug is not about that).
Hello kwizart > @NVieveille, yet again a crazy solution ! https://docs.fedoraproject.org/en-US/project/code-of-conduct/ In regards of this link, I was tempted not to answer. But... This is not a solution. Re-read carefully all the words "Maybe" "should" "try". It's at most a workaround proposition yet again. And, yet again, the spirit of my response was to try to help to workaround the issue encountered by the original poster (stackoverflow spirit - just answering the OP question without digression). Please, try to remember this next time. Now on the background. The crazy proposition was extracted from original kmodtool script. Maybe this shell script already contains crazy code?!? But I would not say that out of respect for the people who wrote it. Just modestly trying to modify it to respond to the OP and not leave him without any workaround. The script was just amended in its original sed part to take into account one new pattern in addition to the existing ones (elXX and fcXX). Nothing more. Reading carefully the two line of my previous post will show it. > You need to assume redhat only in the redhat kernel case (not using %{rhel} > which only indicate a redhat userspace). > Everything else should be non-redhat kernel (so, it will assume: no kabi > support for what this bug is about). > Specially, you should not assume a blacklist of case by case situations. > > Sane solution would be: > - consider kernel ml (or lt) as a valid kvariant in kmodtool > (I would also add kernel-longterm which I'm using on my own copr) > https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/builds/ > https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.14/builds/ > > - Check for appropriate kABI feature in kernel > (/boot/config-${KERNEL_UNAME_R} or using symbol while list package > availability). > > - Check for livepatch/kpatch availabilty from /boot/config-${KERNEL_UNAME_R} > (but this bug is not about that). As you probably understood it from my comment above, I'm not trying to rewrite or re-design kmodtool, just trying to help the OP with a working workaround that doesn't break actual working of this script. I would very pleased if you could try to elaborate with force examples about what you mean and how you would implement it in this precise case of the kmodtool script about kABI. Maybe in an another discussion when we have time. Feel free to make any comment about this subject. Hoping this response will not contain too much words. Cordially, -- NVieville
(In reply to dkmalick from comment #0) > Additional info: > My "works for me" fix is > > --- /usr/bin/kmodtool.orig 2019-10-13 08:50:11.000000000 -0700 > +++ /usr/bin/kmodtool 2019-12-07 07:50:27.478930800 -0700 > @@ -213,8 +213,7 @@ > fi || : > > %if 0%{?rhel} > -Requires: kernel >= ${kernel_uname_r_short} > -Requires: kernel < ${kernel_uname_r_short_plus_one} > +Requires: kernel = ${kernel_uname_r_wo_arch} > BuildRequires: kernel-devel = ${kernel_uname_r_wo_arch} > redhat-rpm-config kernel-abi-whitelists > > %post -n kmod-${kmodname}-${kernel_uname_r} I proposed this https://src.fedoraproject.org/fork/sergiomb/rpms/kmodtool/c/97b07e28b6650be32235e081db94b256c0d287c6?branch=rawhide maybe also fix this bug ...