Bug 96 - /lib/modules/ confusion
Summary: /lib/modules/ confusion
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: modutils
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 431 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 1998-11-16 20:44 UTC by Steve Wills
Modified: 2014-03-19 11:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1998-12-23 20:15:24 UTC

Attachments (Terms of Use)

Description Steve Wills 1998-11-16 20:44:09 UTC
If you have 2 module directories, such as
/lib/modules/2.0.36 and /lib/modules/2.0.36-0.7, it depmod's
one one of them and uses the modules of the other for
modprobe, etc.

I've seen this on the x86. Not sure if it applies to others
or not.

Comment 1 Peter Jones 1998-12-23 17:09:59 UTC
It looks like what happens is that it gets to

    if [ -e /lib/modules/preferred ]; then
        depmod -a preferred
        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@redhat.com says the priority for this needs to be higher; none
of us have permissions to change it.

Comment 2 Peter Jones 1998-12-23 17:12:59 UTC
erm.  those should be /lib/modules/version/ instead of /lib/modules//
.  Angle brackets apparently aren't liked by bugzilla.

Comment 3 Jeff Johnson 1998-12-23 18:57:59 UTC
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
   which does
	if (!access("/lib/modules/preferred/modules.dep", R_OK) {
		depfile = "/lib/modules/preferred/modules.dep";
    and then does
     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
	echo "path[$i]=/lib/modules/preferred" >> /etc/conf.modules

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

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

Comment 4 Jeff Johnson 1998-12-23 20:15:59 UTC
... and now has been fixed in

Comment 5 Jeff Johnson 1999-01-07 18:10:59 UTC
*** 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 ->

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@redhat.com  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@pharmapartners.nl  01/05/99 09:20 -------
Problem not resolved.  See my e-mail messages for further information.

Note You need to log in before you can comment on or make changes to this bug.