Bug 135

Please attach .config files from working 1.12.4 and from broken 1.13.2.

What output do you get when you run "modprobe some_module"?

Created attachment 81 [details]
.config files for v1.12.4 and v1.13.2

modprobe is broken in both versions. Any attempt to run modprobe results in an error message: "cannot parse modules.dep". No modules.dep file is generated during the build process.

> It works perfectly under Busybox 1.12.x (up to 1.12.4)

_what_ works perfectly then, if modprobe fails? insmod?
What is the insmod's output in 1.12.4 and 1.13.2?

Yes, insmod works perfectly under 1.12.x. I have done some further investigations. Under 1.13.2, insmod works if you supply the full path of the module that you wish to load, or if the module is in the directory that you are running from. So it seems to be a path issue.

Modprobe under 1.12.4 always complains about not being able to parse modules.dep. Under 1.13.2, it claims that it can't find the module  (e.g., "modprobe: Module rshaper.o not found") even when the module is in the current directory, and even if you supply the full path to the module.

(In reply to comment #4)
> Yes, insmod works perfectly under 1.12.x. I have done some further
> investigations. Under 1.13.2, insmod works if you supply the full path of the

This is expected behaviour. insmod nowadays takes the full path to the module.
If you want to load an "rshaper" module without specifying the full path then
use "modprobe rshaper".

> module that you wish to load, or if the module is in the directory that you are
> running from. So it seems to be a path issue.
> 
> Modprobe under 1.12.4 always complains about not being able to parse
> modules.dep.

Run depmod again to make sure that modules.dep is generated properly for
your modprobe binary. Take care to use the depmod from busybox depending
on your busybox config.

>              Under 1.13.2, it claims that it can't find the module  (e.g.,
> "modprobe: Module rshaper.o not found") 

This would mean that you are on a 2.4 kernel, right?

>                                         even when the module is in the current
> directory, and even if you supply the full path to the module.

Please show us the exact command you are running plus it's output. Copy and
paste from your terminal will do.

Yes, we are on Linux 2.4. Here is the output out "uname -a":

"Linux RouterTech.AR7WRD 2.4.17_mvl21-malta-mips_fp_le #1 Mon Mar 2 21:46:46 GMT 2009 mips unknown"

This is the command line to modprobe (busybox 1.13.2):
"/var # modprobe /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/driv
ers/net/rshaper.o"

This is the result:
"modprobe: Module /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/net/rshaper.o not found."

It is a spurious error, because the module is there:
"/var # ls -all /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/net/rsh
aper.o
-rw-r--r--    1 1001     1001         7844 Aug 29  2008 /lib/modules/2.4.17_mvl21-malta-mips_fp_le/kernel/drivers/net/rshaper.o"

insmod requires full path now because this is the compatible behavior.

This is how "standard" insmod does this:

# strace insmod wazoo
execve("/sbin/insmod", ["insmod", "wazoo"], [/* 54 vars */]) = 0
...
munmap(0x7f71f375d000, 155067)          = 0
brk(0)                                  = 0x1407000
brk(0x1428000)                          = 0x1428000
open("wazoo", O_RDONLY)                 = -1 ENOENT (No such file or directory)
write(2, "insmod: can\'t read \'wazoo\': No s"..., 54insmod: can't read 'wazoo': No such file or directory
) = 54
exit_group(1)                           = ?

See? it just tries to open given file by name.

With the following options in .config:

#
# Linux Module Utilities
#
# CONFIG_MODPROBE_SMALL is not set
# CONFIG_FEATURE_MODPROBE_SMALL_OPTIONS_ON_CMDLINE is not set
# CONFIG_FEATURE_MODPROBE_SMALL_CHECK_ALREADY_LOADED is not set
CONFIG_INSMOD=y
CONFIG_RMMOD=y
CONFIG_LSMOD=y
CONFIG_FEATURE_LSMOD_PRETTY_2_6_OUTPUT=y
CONFIG_MODPROBE=y
CONFIG_FEATURE_MODPROBE_BLACKLIST=y
CONFIG_DEPMOD=y
#
# Options common to multiple modutils
#
CONFIG_FEATURE_2_4_MODULES=y
CONFIG_FEATURE_INSMOD_VERSION_CHECKING=y
CONFIG_FEATURE_INSMOD_KSYMOOPS_SYMBOLS=y
CONFIG_FEATURE_INSMOD_LOADINKMEM=y
CONFIG_FEATURE_INSMOD_LOAD_MAP=y
CONFIG_FEATURE_INSMOD_LOAD_MAP_FULL=y
CONFIG_FEATURE_CHECK_TAINTED_MODULE=y
CONFIG_FEATURE_MODUTILS_ALIAS=y
CONFIG_FEATURE_MODUTILS_SYMBOLS=y
CONFIG_DEFAULT_MODULES_DIR="/lib/modules"
CONFIG_DEFAULT_DEPMOD_FILE="modules.dep"

I can run these commands and each one works:

Full name:
# ./busybox modprobe /lib/modules/2.6.29-0.28.rc1.fc11.x86_64/kernel/fs/minix/minix.ko

Full name without .ko extension:
# ./busybox modprobe /lib/modules/2.6.29-0.28.rc1.fc11.x86_64/kernel/fs/udf/udf

Just a module name:
# ./busybox modprobe romfs

This is on the system with modprobes.dep file present. strace has these syscalls:

chdir("/lib/modules")                   = 0
chdir("2.6.29-0.28.rc1.fc11.x86_64")    = 0
open("/proc/modules", O_RDONLY|O_LARGEFILE) = 3
open("/etc/modprobe.conf", O_RDONLY|O_LARGEFILE) = 3
open("/etc/modprobe.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 3
open("/etc/modprobe.d/blacklist-visor", O_RDONLY|O_LARGEFILE) = 5
open("/etc/modprobe.d/floppy-pnp", O_RDONLY|O_LARGEFILE) = 5
open("/etc/modprobe.d/i915modeset", O_RDONLY|O_LARGEFILE) = 5
open("/etc/modprobe.d/blacklist", O_RDONLY|O_LARGEFILE) = 5
open("/etc/modprobe.d/modprobe.conf.dist", O_RDONLY|O_LARGEFILE) = 5
open("modules.alias", O_RDONLY|O_LARGEFILE) = 3
open("modules.dep", O_RDONLY|O_LARGEFILE) = 3
open("/lib/modules/2.6.29-0.28.rc1.fc11.x86_64/kernel/fs/udf/udf.ko", O_RDONLY|O_LARGEFILE) = 5

Having to supply full pathnames to modules would be a very big move to make for the ADSL firmwares. Unfortunately, there seems to be no obvious way to run depmod to produce modules.dep on the target platform. I can't seem to find any instructions in the busybox docs about this. 

Insmod works well enough under busybox 1.12.x without having to supply full paths. So I guess we'll just stick with 1.12.4, since there is no particularly pressing need to move to 1.13.x. Most of the other AR7 firmwares (both official and third party) are still running busybox 0.61-pre, so we are already far ahead of the rest of them!

I suppose this is not a bug, after all. Sorry for wasting your time!

Thanks.

Created attachment 99 [details]
Patch to emit "can't open 'modules.dep'" message (less confusing)

I looked into the code. Modprobe requires modprobe.dep. You should generate one with depmod, or use insmod.

I am making modprobe to be more explicit about it in the error messages.

Closing it as "INVALID". If depmod generated bad modprobe.dep, or modropbe does not work even with modprobe.dep, feel free to reopen.

> Having to supply full pathnames to modules would be a very big move to make for
the ADSL firmwares.

I did know that this change will cause some pain, but in the long run it's far better to maintain compatibility with "standard" tools - we want more desktop users to use busybox. Sorry...

(In reply to comment #9)
> Having to supply full pathnames to modules would be a very big move to make for
> the ADSL firmwares. Unfortunately, there seems to be no obvious way to run
> depmod to produce modules.dep on the target platform. I can't seem to find any
> instructions in the busybox docs about this.

cat >/etc/init.d/depmod<<EOF
#!/bin/sh
case "/$1" in
/start) ;;
*) exit 0;;
esac
test -f /lib/modules/$(uname -r)/modules.dep || depmod -ae
exit $?
EOF
chmod +x /etc/init.d/depmod && make sure that this is run on bootup.

Thanks. But the filesystem is a readonly squashfs, and so depmod can't write to it.

Then you have to generate modules.dep during the generation of the rootfs.
Let me refer you to buildroot on how to do that cleanly.