Red Hat Bugzilla – Bug 1962
Difficult to use non-obvious /lib/modules/<foo> module directories
Last modified: 2008-05-01 11:37:49 EDT
The Rawhide modutils-2.1.121 appears to be compiled to
as the search path for modules, unlike the RedHat 5.2
modutils, which seem to have been compiled to check
/lib/modules/preferred as well (and first, from the
looks of things).
The net effect of this change seems to be to make it
practically impossible to use the old scheme where
/lib/modules/preferred was symlinked to the right
place. I believe this is undesirable; I don't want
to be frobbing EXTRAVERSION in kernel Makefiles for
every variant I test-compile (among other things,
this will make patches from kernel version to kernel
version fail to apply cleanly!).
I suggest that RedHat revert/enhance/whatever modutils
to check /lib/modules/preferred again.
You can modprobe modules only against the running kernel, and now we
have a very sure way of identifying the running kernel, so the
preferred hack is no longer needed.
If the preferred hack is no longer supposed to be there at all,
you might want to delete the stanza in /etc/rc.d/rc.sysinit that
falls back to it.
Personally, I think that relying on uname -r/EXTRAVERSION is a
bit fragile in an environment where people may build their own
kernels, but clearly RedHat disagrees.
it has been removed in the latest initscripts (removed about 3/29
Relying on EXTRAVERSIOn is a whole lot more stable than the previous
preffered hack. This is what EXTRAVERSION is for and it is not
terribly difficult to change that value when compiling a customized