The depmod tool, in all ebuilds from the module-init-tools package, has an off-by-one bug in the command-line option parsing. This means that when you tell it to scan a set of specific modules (instead of the default where everything is scanned), it always skips the first module. Reproducible: Always Steps to Reproduce: % depmod -n `uname -r` foo bar > /dev/null Actual Results: WARNING: Can't read module /bar: No such file or directory Expected Results: WARNING: Can't read module /foo: No such file or directory WARNING: Can't read module /bar: No such file or directory I've confirmed this bug is in the module-init-tools-3.0-r2 and module-init-tools-3.1-r1 ebuilds. The fix is trivial, and will be included shortly (once I test my patch).
Created attachment 57466 [details, diff] Patch that fixes depmod in module-init-tools 3.0 The optind variable is set by the getopt functions. It points to the next parameter that should be parsed. It therefore does not need to be adjusted to find the start of the list of files to scan. - Andrew
Created attachment 57467 [details, diff] Patch that fixes depmod in module-init-tools 3.1 As remarked in earlier patch, optind is set by getopt to the next parameter to process. As such it does not need to be offset to find the first file to scan.
i just checked module-init-tools-3.2-pre2 and it still could use this patch ... could you e-mail rusty@rustcorp.com.au about getting this resolved in upstream module-init-tools first ?
I've sent an email (and the patch) to Rusty as suggested, with a CC to you. I've also downgraded the bug, since I discovered this tool doesn't do what I wanted it to anyway. Instead I'm now using modprobe -n --set-version --show-deps to generate a list of modules for an initramfs, although depmod -e -F with a module list will be useful at the end to check the generated list is consistent. Cheers, - Andrew
I just received the following reply from Rusty: > OK, I've also fixed the relative path bug (it doesn't handle relative > paths, and prepends a "/"), and written a test case. > > 3.2-pre3 will include this. > > Thanks! > Rusty. That means the fix will be in 3.2. I don't know what the policy is for 'backporting' fixes is, especially for unreleased upstream packages, but am happy to leave this to the judgement of the wranglers. Hope this helps, - Andrew
if you feel like grabbing the fix from the newer version, i'll add it to 3.1, otherwise we can just close the bug and wait for the new release since it doesnt seem like too critical an issue ... thanks for e-mailing rusty btw !
erm forgot to close ...
