From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 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: Always 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.
Hi, 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 http://thomas.apestaart.org/download/patches/modutils/module-init-tools-update/ and the modutils rpm with the fix is at http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/modutils-2.4.26-16.fdr.1.2/ together with a module for pwc/pwcx that you could try it out with: http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-module-pwcx-9.0-0.0.beta.2.fdr.3.2/ (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.