Bug 703189

Summary: Module in "extras" directory overwritten during errata kernel upgrade
Product: Red Hat Enterprise Linux 5 Reporter: Chad Dupuis (Cavium) <cdupuis>
Component: module-init-toolsAssignee: Jon Masters <jcm>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: unspecified    
Version: 5.5CC: amyagi, coughlan, ichute, ravi.anand, revers
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-26 21:24:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Chad Dupuis (Cavium) 2011-05-09 15:29:41 UTC 
Currently, the default module search order is defined in /etc/depmod.d/depmod.conf.dist as:
 
updates, extra, built-in, weak-updates.
 
This can cause issues if we have an updated module in the "extras" directory and we do an errata kernel upgrade.  What happens here is that a link is created from our updated module in the "extras" directory of the old kernel to the "weak-updates" directory of the new kernel.

This becomes an issue if we have a SAN boot target and we use a dd-disk to install a driver with new hardware support.  As soon as we install an errata kernel and reboot we won't be able to find our boot partition as the inbox driver won't recognize the new hardware.

We can work around this by adding a module specific search order in  /etc/depmod.d but were hoping to find a way around this issue without having to create module specific settings.  Our initial request is to change the default order to:

updates, extra, weak-updates, built-in

but obviously we're open to other solutions as well.

Version-Release number of selected component (if applicable):

module-init-tools-3.3-0.pre3.1.60.el5
Comment 1 Jon Masters 2011-05-26 21:24:50 UTC 
I understand the reason for your request, but the purpose of the default being as it is is that inbox drivers will always take priority unless specifically configured otherwise. This generally favors a progression in which an update exists for a brief time and then goes away, in favor of the in-box driver.

The correct recommended course of action is to carry a driver specific /etc/depmod.d configuration file for the module in question, using the "override" option to change the priority temporarily, while the update is installed. An example of this can be found in the ddiskit 2.x utility. For further information, please see http://people.redhat.com/el6/dup/docs/

Jon.
Comment 3 Akemi Yagi 2011-05-26 22:53:55 UTC 
Jon,

That link does not exist. I can get to the docs by inserting a 'jcm' in the path ...

Akemi