Bug 671060

Summary:	/etc/modprobe.d/modprobe.conf not sourced by mkinitrd
Product:	Red Hat Enterprise Linux 6	Reporter:	Steve Morgan <captainmrgn>
Component:	kernel	Assignee:	Jon Masters <jcm>
Status:	CLOSED NOTABUG	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	high	Docs Contact:
Priority:	low
Version:	6.3	CC:	jcm
Target Milestone:	rc
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:50:40 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 Steve Morgan 2011-01-20 05:22:26 UTC

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.

Comment 2 Jon Masters 2011-01-24 06:24:38 UTC

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.

Comment 4 Steve Morgan 2011-01-24 22:41:22 UTC

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

Comment 5 Steve Morgan 2011-01-24 22:51:44 UTC

The file is actually: /etc/initramfstools.d/modules

Comment 6 RHEL Program Management 2011-02-01 05:31:59 UTC

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.

Comment 7 RHEL Program Management 2011-02-01 19:08:41 UTC

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.

Comment 8 Jon Masters 2011-02-04 07:42:19 UTC

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.

Comment 10 Steve Morgan 2011-02-05 00:47:19 UTC

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.

Comment 11 RHEL Program Management 2011-04-04 02:18:36 UTC

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.

Comment 12 Jon Masters 2011-05-26 21:50:40 UTC

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.