Bug 431 - modprobe puts the preferred directory at lowest priority
modprobe puts the preferred directory at lowest priority
Status: CLOSED DUPLICATE of bug 96
Product: Red Hat Linux
Classification: Retired
Component: modutils (Show other bugs)
5.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-12-15 11:52 EST by vek
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-01-07 13:10:27 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 vek 1998-12-15 11:52:50 EST
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.
Comment 1 David Lawrence 1998-12-16 12:10:59 EST
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 09:20:59 EST
Problem not resolved.  See my e-mail messages for further information.
Comment 3 Jeff Johnson 1999-01-07 13:10:59 EST
*** 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.