Bug 96 - /lib/modules/ confusion
/lib/modules/ confusion
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: modutils (Show other bugs)
5.2
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
: 431 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-11-16 15:44 EST by Steve Wills
Modified: 2014-03-19 07:09 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1998-12-23 15:15:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Wills 1998-11-16 15:44:09 EST
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 12:09:59 EST
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@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 12:12:59 EST
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 13:57:59 EST
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 ...
Comment 4 Jeff Johnson 1998-12-23 15:15:59 EST
... and now has been fixed in
	dist-5.2.1/modultils-2.1.85-10
	dist-6.0/modultils-2.1.121-2
Comment 5 Jeff Johnson 1999-01-07 13:10:59 EST
*** 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@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.