Bug 96

It looks like what happens is that it gets to

    if [ -e /lib/modules/preferred ]; then
        depmod -a preferred
    else
        depmod -a

in /etc/rc.d/rc.sysinit, runs depmod on prefered, and then kerneld
tries to find dependancies for /lib/modules/<version>/ from
/lib/modules/<version>/modules.dep .
/lib/modules/<version>/modules.dep in turn has dependancies for
/lib/modules/preferred/ instead, and so this doesn't work.

rtilder says the priority for this needs to be higher; none
of us have permissions to change it.

erm.  those should be /lib/modules/version/ instead of /lib/modules//
.  Angle brackets apparently aren't liked by bugzilla.

Here's what appears to be happening:

1) The linux kernel sends KERNELD_REQUEST_MODULE.
2) /sbin/kerneld picks up the message and execs
	/sbin/modprobe -k -s modulename
3) modprobe does
	read_config_file(NULL)
   which does
	if (!access("/lib/modules/preferred/modules.dep", R_OK) {
		depfile = "/lib/modules/preferred/modules.dep";
		add_set("/lib/modules/preferred")
	}
    and then does
	add_set("/lib/modules");
	add_set("/lib/modules/default")
     and finally
	add_set("/lib/modules/2.0.x");	# 2.0.x is kernel release

This results in /lib/modules/2.0.x being searched for modules
to be loaded before /lib/modules/preferred.

Try "modprobe -c | grep path" to see the currently configured
set of paths to be searched in first found order.

The work around is to add to /etc/conf.modules:

for i in sound ipv6 ipv4 cdrom block scsi net misc fs
do
	echo "path[$i]=/lib/modules/preferred" >> /etc/conf.modules
done

and verify that /lib/modules/preferred precedes /lib/modules/2.0.x
using "modprobe -c"

This problem could (should?) be fixed in modprobe.c ...

... and now has been fixed in
	dist-5.2.1/modultils-2.1.85-10
	dist-6.0/modultils-2.1.121-2

*** Bug 96 has been marked as a duplicate of this bug. ***


The modprobe utility puts the preferred directory at a
priority lower than enything else.  The effect is that if
you have a directory named /lib/modules/2.0.36 then
whatever is in this directory will take precedence over the
contents of /lib/modules/preferred ->
/lib/modules/2.0.36-0.7

This is only a problem if you build a new kernel and kernel
modules and the modules are installed in the 2.0.36
directory.  If you then boot from the new kernel everything
is OK, but if you boot from the original release kernel
2.0.36-0.7 then you get module load problems.

I assume that the preferred directory (symbolic link) was
intended to have the higest priority, and that when you boot
from a newly linked kernel the rc.sysinit will remove
preferred which causes the 2.0.36 to take the place of
higest priority.



------- Additional Comments From dkl  12/16/98 12:10 -------
The script in /etc/rc.d/rc.sysinit creates a new  preferred link
everytime the machine boots based on the version of the kernel it
detects therefore if you boot a new kernel it should set the preferred
link to the directory with the new modules. One thing you should do
before doing a modules_install during the kernel compilation is move
your old /lib/modules/2.0.x to /lib/modules/2.0.x.old or something
like that. That way your old modules do not get overwritten if you
want to revert back to an older kernel later.

------- Additional Comments From vek  01/05/99 09:20 -------
Problem not resolved.  See my e-mail messages for further information.