|Summary:||modprobe puts the preferred directory at lowest priority|
|Product:||[Retired] Red Hat Linux||Reporter:||vek|
|Component:||modutils||Assignee:||David Lawrence <dkl>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-01-07 18:10:27 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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 -> /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 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.