Bug 431 - modprobe puts the preferred directory at lowest priority
Summary: modprobe puts the preferred directory at lowest priority
Status: CLOSED DUPLICATE of bug 96
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: modutils
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1998-12-15 16:52 UTC by vek
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-01-07 18:10:27 UTC

Attachments (Terms of Use)

Description vek 1998-12-15 16:52:50 UTC
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.

Comment 1 David Lawrence 1998-12-16 17:10:59 UTC
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.

Comment 2 vek 1999-01-05 14:20:59 UTC
Problem not resolved.  See my e-mail messages for further information.

Comment 3 Jeff Johnson 1999-01-07 18:10:59 UTC
*** This bug has been marked as a duplicate of 96 ***

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