Hide Forgot
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
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.
Jon, That link does not exist. I can get to the docs by inserting a 'jcm' in the path ... Akemi