Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 125990 - depmod under 2.6.x does not look first in "updates/" directory
depmod under 2.6.x does not look first in "updates/" directory
Product: Fedora
Classification: Fedora
Component: module-init-tools (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
Blocks: FC3Target
  Show dependency treegraph
Reported: 2004-06-14 17:51 EDT by Fernando Lopez-Lezcano
Modified: 2014-03-16 22:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-11 12:57:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
one possible patch to fix the problem (1.95 KB, patch)
2004-06-14 21:57 EDT, Fernando Lopez-Lezcano
no flags Details | Diff
a better patch (I think) (1.71 KB, patch)
2004-06-15 14:07 EDT, Fernando Lopez-Lezcano
no flags Details | Diff

  None (edit)
Description Fernando Lopez-Lezcano 2004-06-14 17:51:23 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
or predictable). 

Version-Release number of selected component (if applicable):
3.0-beta10 (inside modutils 2.4.26-16)

How reproducible:

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
Comment 1 Fernando Lopez-Lezcano 2004-06-14 21:57:29 EDT
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).
Comment 2 Fernando Lopez-Lezcano 2004-06-15 14:07:29 EDT
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.
Comment 3 Thomas Vander Stichele 2004-06-16 12:43:02 EDT

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)
Comment 4 Fernando Lopez-Lezcano 2004-06-16 14:11:09 EDT
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). 
Comment 5 Bill Nottingham 2004-10-11 12:57:40 EDT
Should be fixed in current module-init-tools.

Note You need to log in before you can comment on or make changes to this bug.