Hide Forgot
Description of problem: /etc/modprobe.d/modprobe.conf does not source the scsi module load order. alias scsi_hostadapter 3w-xxxx alias scsi_hostadapter1 3w-9xxx alias scsi_hostadapter2 3w-sas alias scsi_hostadapter3 mpt2-sas Version-Release number of selected component (if applicable): RHEL 6 How reproducible: Create a new initramfs file after changing the scsi_hostadapter order in modprobe.conf. Reboot the system with the new initrd. The device order does not change. Modules are loaded in the default order. I have heard many times to mount by UID. This is not feasible for the environments I work in. I have hundreds of computers with multiple RAID controllers. An example would be loading the following modules in order: 3w-9xxx 3w-sas mpt2-sas Sorry if this post is incorrectly placed. I saw no other option as I have stumped all of my resources.
Today, we use udev in the initramfs to load drivers, so determining the specific ordering in the fashion you are looking to achieve isn't possible. Instead, you can implement udev rules to enforce ordering, but this should not be necessary. Can you tell me why you require this? Jon.
I work in cluster environments and need consistency with RAID controllers showing up as /c0, /c1 and so on and can't depend on the PCIe slot as not all hardware is identical. I also need the OS to be sda. Debian seems to of seen this as a needed feature because they have added /etc/modules.d/modules that is probed for this purpose. update-intramfs reads this file and builds the initramfs correctly. Steve
The file is actually: /etc/initramfstools.d/modules
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
This request was erroneously denied for the current release of Red Hat Enterprise Linux. The error has been fixed and this request has been re-proposed for the current release.
We have the ability to source specific modules into the initramfs (like the Debian example that you cite), but not to specify a specific ordering using modprobe. Neither RHEL, nor Debian for that matter, are using these files to determine the *order* in which modules will be loaded. The only real solution is to use udev rules to determine ordering, or file a bug requesting that we implement a means to specifically specify the order of udev loads. This is not something that can be solved in modprobe as it is dependent upon device detection. The Debian case provides simply a list of modules. These might happen to get loaded in the order given in the case of Debian, but if using udev, modules are loaded as devices are detected by udev, which is enumeration dependent. I share the concern that it would be useful to control this load ordering and device naming/binding more directly. If you file a bug to that effect, it will help. Jon.
I personally have used the Debian example I provided to correct the same issue. The file itself states the purpose of the file is for loading modules in a specific order. If you want me to file the bug again and word it differently I can. Let me know if there is anything I can do to expedite this.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
At this time, there are proposals in the Linux community for this to be resolved using variations on persistant device labels. But there are no plans to have RHEL load drivers in a specifically specified order. There are options available. For example, you can create a custom udev rules file that specifically loads the modules in the order that you require. Additionally, if you have a support contract with Red Hat, and have an urgent business justification for implementing a workaround, please open a case through the Issue Tracker (by contacting support). Jon.