The kmodtool script hardcodes "/sbin/depmod" in a couple places, but the file path should be "/usr/sbin/depmod" instead. For example: Requires(post): /sbin/depmod Requires(postun): /sbin/depmod Or: /sbin/depmod -aeF "/boot/System.map-${verrel}${variant}" "${verrel}${variant}" > /dev/null || : Or: /sbin/depmod -aF /boot/System.map-${verrel}${variant} ${verrel}${variant} &> /dev/null || : Please adjust this to /usr/sbin/depmod, since that is the file that kmod-15-1.fc20.x86_64 provides. https://fedoraproject.org/wiki/Features/UsrMove
This change is already in RHEL 7 * Sun Sep 22 2013 Weiping Pan <wpan> - 9.1.0-54 - Fix depmod path So this needs to be pushed back up to Fedora.
Here's the patch that RPM Fusion used on their kmodtool fork: http://cvs.rpmfusion.org/viewvc/rpms/kmodtool/devel/kmodtool-kmodtool?root=free&r1=1.5&r2=1.6&view=patch In addition to depmod, all references to "/lib/modules/" need to change to "/usr/lib/modules/".
I've applied for commit access in pkgdb. It would be nice to sync up the Fedora kmodtool version with the version that RHEL 7 will ship. https://admin.fedoraproject.org/pkgdb/package/redhat-rpm-config/
Created attachment 900604 [details] kmodtool script from redhat-rpm-config-9.1.0-63.el7.noarch I'm attaching the kmodtool script that shipped in the RHEL 7 RC. The easiest solution is to simply replace the current Rawhide kmodtool with this one.
Hold your horses please. There are planned changes to the way these kernel scripts and macros are maintained. Namely the plan is to split them out of redhat-rpm-config entirely, and any work in this area needs to be coordinated to avoid causing unnecessary complications. CC'ing a bunch of involved people for comments... I can certainly sync kmodtool up with RHEL-7 version if that doesn't disrupt any work from kernel-side people that has taken place in the meanwhile. But slopping in kmodtool from RHEL-7 is not really the way to do it when we have access to actual change history.
Hi, I agree with Panu. It is best to let the package maintainers handle these things as they are more familiar with the work going on. Also being that the kernel is special, it is nice to get Josh's feedback before disrupting his environment (though I am sure he is used to it by now :-) ). I am not familiar with the changes so I can not argue for or against them. Hopefully Wei can chime in with the reason for the change and let us know the impact it had on kernels in RHEL-7 (though it didn't seem to have any that I saw). Cheers, Don
(In reply to Don Zickus from comment #6) > Hi, > > I agree with Panu. It is best to let the package maintainers handle these > things as they are more familiar with the work going on. Also being that > the kernel is special, it is nice to get Josh's feedback before disrupting > his environment (though I am sure he is used to it by now :-) ). I don't think you're going to disrupt my environment with any changes to kmodtool. Fedora doesn't use it. There are 3rd party repositories that use kmodtool, but I think they have their own copies they use? > I am not familiar with the changes so I can not argue for or against them. > Hopefully Wei can chime in with the reason for the change and let us know > the impact it had on kernels in RHEL-7 (though it didn't seem to have any > that I saw). Looking over a diff of the attached script vs. what's provided by redhat-rpm-config in F20, there's somethings that are obviously wrong in the context of Fedora. - The knownvariants list drops PAE, but Fedora still (sadly) ships 32-bit x86 kernels. - The script adds Provides to the kmod-<whatever> package for "kernel-modules >= ${verrel_dep}${dotvariant}", but rawhide now actually ships a real subpackage named kernel-modules. Not sure that is going to play well. Arguably, the existing F20 script is broken in a very similar way, which is just a further illustration that nobody actually uses the Fedora copy. As for replacing all instances of /lib/ with /usr/lib, we haven't done that in kernel.spec yet and it's not a high priority. The symlinks exist in Fedora still, so things work fine. I'm not sure whether you should update the kmodtool script provided in redhat-rpm-config, or just remove it entirely, but using the RHEL7 version seems odd.
Thanks Panu, Don, and Josh for looking into this. The reason I filed this bug is that I received the following report at OpenAFS: http://lists.openafs.org/pipermail/openafs-info/2014-May/040662.html You're correct that the /usr symlinks still exist in Fedora and RHEL 7, but apparently the symlinks are not adequate for yum to do the right thing within a kickstart/Anaconda environment. OpenAFS bundles a very old kmodtool, and it would be nice to stop bundling that. Getting Fedora's kmodtool into shape will make it possible for us to stop bundling. (And of course there are a couple other projects that are not OpenAFS that would also be helped by this too.)
[jwboyer@vader linux]$ rpm -qf /sbin/depmod kmod-15-1.fc20.x86_64 [jwboyer@vader linux]$ rpm -qf /usr/sbin/depmod kmod-15-1.fc20.x86_64 [jwboyer@vader linux]$ RPM seems smart enough to figure it out here, so the theory in the thread that installation order doesn't matter seems incorrect. It's plausible dependency resolution might matter in other scenarios. At any rate, it would be better to do what was suggested here: http://lists.openafs.org/pipermail/openafs-info/2014-May/040691.html and change the Requires to use kmod, not a hard coded path.
Right, when we use yum to install the packages on running systems it works. We didn't notice this until someone tried to install the package within Anaconda/kickstart on RHEL 7. We've merged a workaround in OpenAFS's bundled kmodtool for this, and my hope is that kmodtool in Fedora gets updated so that we can just drop the bundled openafs-kmodtool altogether.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
What's the status on this? Can I just close this bug or is there still something to do on the redhat-rpm-config side of things?
Hi Florian, I'm no longer actively involved in OpenAFS development, and that was the only 3rd-party kmod that I was interested in, so I no longer need a reason for an updated kmodtool in Fedora. At a general level, it would be nice if kmodtool could be extracted out of redhat-rpm-config and into its own project/package. Right now there are different versions of the script floating around here in Fedora, and in RHEL 6, RHEL 7, RPM Fusion, and OpenAFS.org (and I've seen others as well). It would be great if all these groups could benefit from easier collaboration and shared maintenance instead of forking kmodtool so much. But I no longer have an active interest in driving that unification effort forward. Thanks for following up and you can feel free to close this bug.
Closing this for now. If anyone wants to take over kmodtool just give us a call.