problem with /etc/init.d/modules

[beek555]

Hi, the symptom of the problem I'm having is that the modules listed in modules.autoload are not being loaded on bootup.

I can reproduce this by calling "/etc/init.d/modules pause" and then observe that "/etc/init.d/modules start" does not load any of the modules I have in modules.autoload.

[rac]

Does running modprobe on the modules by hand work properly?
_________________
For every higher wall, there is a taller ladder

[beek555]

Yes, it does. (I should have noted that)
So this is why I conclude that modprobe is never being called by the script.

[rac]

Does running "env-update" and/or "/sbin/update-modules" help? What is the version of /etc/init.d/modules? I'm looking at 1.16.
_________________
For every higher wall, there is a taller ladder

[beek555]

Thanks for your suggestions
My "modules" script is version 1.16 as well.
Calling "update-modules", "env-update", and "depmod -a" all have no effect.

**
To more explicitly document for later readers:
Running update-modules had occurred to me, but I noted that it is actually called by "/etc/init.d/modules".
It generates "modules.conf" based on files from "/etc/modules.d/" (Independent of "modules.autoload")
Incidently, any aliased modules in modules.conf (such as alsa) load just fine upon bootup.

As for env-update, it is called every time emerge is used, so I'm probably safe there. Similar to the other script, it generates /etc/profile.env from /etc/env.d.
**

One thing I notice about this script is that when I stop or start it, the ebegin statements are not printed, whereas they are printed with other scripts such as metalog. This makes debugging difficult. (I've tried using eerror)
I also notice that the 'needs' dependencies are processed correctly for the script. IOW if I call "/etc/init.d/modules stop", all its' dependencies are stopped.

As near as I can tell, the start() {} segment in the script is just not being called?
I'm sure that the problem is not with the script, since everybody uses it, but it seems to me that identifying the point of failure inside it is the best way to find the actual problem. So I'm learning runscript.

(I think I'm getting close on this one, but my router just locked up - thank you Time Warner - so I'll have to wait until I get home to find out)

[beek555]

From messing with the script, I've determined that it returns silently because /proc/modules does not exist. This is apparently is the check to see if the kernel has module support compiled in, which I do.

I'm now researching what could be causing this file to be missing from /proc.

[beek555]

Well, it's going to be one of those things -
I decided to recompile the kernel, since gentoo-source-r10 was out anyway. Lo and behold, /proc/modules appears upon reboot.

For some reason, my r9 kernel had some screwyness involving /proc.
It would never accept kernel parameter changes through /proc before now either (erratic permissions), and that works now too.

Ah well, an unsolved mystery, but at least it works now.

Thanks for the advice