Red Hat Bugzilla – Bug 125990
depmod under 2.6.x does not look first in "updates/" directory
Last modified: 2014-03-16 22:46:07 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)
Description of problem:
The modules-init-tool version of depmod (for 2.6.x) does not look in
the "/lib/modules/`uname -r`/updates directory first when searching
for modules. This was supported in 2.4.x as a way to be able to
override kernel modules that are included in the kernel package. AFAIK
there is no way to do that in 2.6.x with the new depmod (depmod just
uses readdir and the order of directory search is thus not repeatable
Version-Release number of selected component (if applicable):
3.0-beta10 (inside modutils 2.4.26-16)
Steps to Reproduce:
I need this feature to work in some way to be able to override the
built-in ALSA with a newer version (without damaging or overwriting
the installed kernel package). So:
1. install kernel
2. install additional kernel-modules-alsa package for the installed
kernel, modules are installed in /lib/modules/`uname -r`/updates/
3. load alsa modules
4. depending on the unsorted ls of the top dir either the old modules
or the newer modules are modprobe'd.
Actual Results: Depending on the on-disk layout of the directory
contents the new modules or the old ones get loaded. There is no way
to assure that the new modules will be always loaded.
Expected Results: The new kernel modules should have been loaded.
Additional info: None
Created attachment 101132 [details]
one possible patch to fix the problem
This patch changes grab_dir so that it always scans the "updates" directory
last (last scan means first output). It seems to work fine in limited tests,
modules installed in the "updates" directory take precedence to the ones in the
normal kernel tree.
I'm certain this could be done more efficiently :-) I'm using scandir which
does a sort that is not really necessary (and then just a linear scan searching
for the "updates" directory)....
I'm not checking the recursion depth so any "updates" directory at any level in
the tree should take precedence - not tested (I don't know if that was the
behavior in 2.4.x).
Created attachment 101154 [details]
a better patch (I think)
Another approach. Just uses readdir again (no unneeded sort happens, no
duplicate scans). I add a parameter to grab_dir to ignore the "updates"
directory on the scan that parses the whole module tree. This patch only
considers an "updates" directory in the top level of the modules tree (ie:
/lib/modules/`uname -r`/updates), any other "updates" directories are treated
as standard subdirectories. This could be easily changed.
I think I'll use this patch unless somebody finds any problems with it. I would
appreciate additional eyes to check for stupid typos or logic flaws. Seems to
be working fine.
I checked your second patch, but I don't think it's correct.
Basically you discard the first list (which is a memleak, but not that
important), and only keep the second list (from updates/)
I looked at the problem, and created a new patch that also fixes
modinfo, and seems to me to have the right logic. I verified that it
works with my pwcx kernel module packages and looking at the
modules.dep files generated.
The patch is up at
and the modutils rpm with the fix is at
together with a module for pwc/pwcx that you could try it out with:
(You don't need to have the webcam, just install and look at the
generated .deps files)
Thanks Thomas! Your patch is better because it removes the duplicates.
I don't know if that matters at all, it does not seem to make a
difference here (I have not looked at the code but I'm guessing
modprobe does a linear scan and uses the first matching module it
finds, that matches the behavior I have observed).
I do think my patch works (with the caveat that it does not remove
duplicate entries). The first list is not discarded. grab_dir
eventually calls grab_module and that creates a new struct and links
from it to whatever it receives as the parameter "next" (a null for
the first one). So, the second call (which is the one that scans the
updates directory) merely adds to the beginning of the list and thus
overrides whatever was scanned by the first call, which does
everything except for the updates directory.
If I grep modules.dep for the modules I'm overriding I see both the
updates (first) and the original (second) (plus everything works after
a reboot, otherwise things like eth0 would not load).
Should be fixed in current module-init-tools.