Bug 317811 - depending on modprobe.conf configuration, required modules are not included in the initrd.
depending on modprobe.conf configuration, required modules are not included i...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mkinitrd (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Peter Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-04 01:18 EDT by Norm Murray
Modified: 2010-10-22 15:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-09 09:57:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wade Mealing 2007-10-04 01:18:05 EDT
Description of problem:

(Hard to explain, easy to reproduce)

The method of determining a modules path (in mkinitrd) in the 5.1 beta seems to
have changed.  It introduces a regression.  The problem is that the locatemodule
function does not seem to correctly include the parent module if there are
additional configuration options in the modprobe.conf.

This breaks the qla2400 driver specifically, but i'm sure that it will affect
other drivers.

The codepath in question is.

locatemodule() {
    fmPath=$(modprobe --set-version $kernel --show-depends $1 2>/dev/null | awk
'/^insmod / { print $2; }' | tail -1)
    if [ -n "$fmPath" -a -f "$fmPath" ]; then
        return 0
    fi

    for modExt in o.gz o ko ; do
        for modDir in /lib/modules/$kernel/updates /lib/modules/$kernel ; do
            if [ -d $modDir ]; then
                fmPath=$(findone $modDir -name $1.$modExt)
                if [ -n "$fmPath" -a -f "$fmPath" ]; then
                    return 0
                fi
            fi
        done
    done
    return 1
}

---
The offending code section seems to be:

    if [ -n "$fmPath" -a -f "$fmPath" ]; then
        return 0
    fi

This always seems to break the module if there are any additional options in the
modprobe.conf such as..

install qla2400 /sbin/modprobe qla2xxx_conf ;/sbin/modprobe --ignore-install qla2400
remove qla2400 /sbin/modprobe -r --first-time --ignore-remove qla2400 && {
/sbin/modprobe -r --ignore-remove qla2xxx_conf; }

(Just tested, this happens for other modules with additional options in
modprobe.conf)

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

mkinitrd-5.1.19.6-19


How reproducible:

Every time

Steps to Reproduce:
1. Install standard rhel 5.1 snap 7
2. pass addition options for module control via modprobe.conf
3. make initrd
  
Actual results:

Initrd does not include modules that have additional control options in
modprobe.conf

Expected results:

Module to be included on initrd.

Additional info:
Comment 3 Issue Tracker 2007-10-08 15:42:39 EDT
----- Additional Comments From chavezt@us.ibm.com (prefers email at
tinytim@us.ibm.com)  2007-10-08 15:13 EDT -------
I've begun looking at this issue on our side and wanted to document a
few
observations...

I began investigating by hooking the mkinitrd script in its findmodule()
function to print out the module name, its dependencies, and the path to
the
driver.  This is where I noticed that the qla2xxx driver was not getting
its
correct path.  Its path was being set to the path of its "scsi_mod"
dependency.
 Here is some output (the "before" is printed before locatemodule() and
the
"after" is printed after locatemodule()):

before: mod=mptscsih, deps=scsi_mod mptbase ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/scsi/scsi_transport_sas.ko
after: mod=mptscsih, deps=scsi_mod mptbase ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/message/fusion/mptscsih.ko
before: mod=mptsas, deps=scsi_mod mptbase ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/message/fusion/mptscsih.ko
after: mod=mptsas, deps=scsi_mod mptbase ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/message/fusion/mptsas.ko
before: mod=qla2xxx, deps=intermodule scsi_mod ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/message/fusion/mptsas.ko
---->after: mod=qla2xxx, deps=intermodule scsi_mod ,
path=/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/scsi/scsi_mod.ko

So "mkinitrd" thinks, for some reason, this is the location it should
use (it's
dumb, it just assumes the last location in the list is the right one)...
its
getting this information from "modprobe", so I ran the modprobe command
it uses
at the command line to see what it was returning.  

In /etc/modprobe.conf we have:
alias scsi_hostadapter2 qla2xxx
install qla2xxx /sbin/modprobe qla2xxx_conf; /sbin/modprobe
--ignore-install qla2xxx
remove qla2xxx /sbin/modprobe -r --first-time --ignore-remove qla2xxx &&
{
/sbin/modprobe -r --ignore-remove qla2xxx_conf; }

%  modprobe --set-version 2.6.21.4-ibmrt1.3 --show-depends qla2xxx
2>/dev/null
insmod /lib/modules/2.6.21.4-ibmrt1.3/kernel/kernel/intermodule.ko 
insmod /lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/scsi/scsi_mod.ko
max_report_luns=256 max_luns=512
install /sbin/modprobe qla2xxx_conf; /sbin/modprobe --ignore-install
qla2xxx

Ah... now let's comment out the "install" directive in
/etc/modprobe.conf:
alias scsi_hostadapter2 qla2xxx
#install qla2xxx /sbin/modprobe qla2xxx_conf; /sbin/modprobe
--ignore-install
qla2xxx
remove qla2xxx /sbin/modprobe -r --first-time --ignore-remove qla2xxx &&
{
/sbin/modprobe -r --ignore-remove qla2xxx_conf; }

% modprobe --set-version 2.6.21.4-ibmrt1.3 --show-depends qla2xxx
2>/dev/null
insmod /lib/modules/2.6.21.4-ibmrt1.3/kernel/kernel/intermodule.ko 
insmod /lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/scsi/scsi_mod.ko
max_report_luns=256 max_luns=512
insmod
/lib/modules/2.6.21.4-ibmrt1.3/kernel/drivers/scsi/qla2xxx/qla2xxx.ko
ql2xfailover=0 ql2xretrycount=3 ql2xprocessnotready=0
qlport_down_retry=35

The path to our module is revealed!

Now the question is this:  According to Mike, this same code worked fine
in
RHEL4.2... So was it incorrect in RHEL4.2, allowing Qlogic to accidently
exploited a weakness in modprobe that rendered the "correct" output and
was this
fixed for RHEL5.1 showing an error in QLogic's modprobe.conf setup?  Or,
was
modprobe correct in RHEL4.2 in this regard and broken between RHEL4.2 and
RHEL5.1?  I do not understand enough about how the "install" directive
_should_
work, yet.

More later, hopefully. 


This event sent from IssueTracker by jkachuck 
 issue 133058
Comment 4 Issue Tracker 2007-10-08 16:31:54 EDT
----- Additional Comments From chavezt@us.ibm.com (prefers email at
tinytim@us.ibm.com)  2007-10-08 16:18 EDT -------
In the ChangeLog it states under version 3.1:

modprobe: install/remove commands must override modules.alias file.

I noticed that RHEL4.2 is using a pre-release of version 3.1.  This kind
of
sounds like what is happening with regards to our bug.  The "install"
command is
essentially overriding the scsi_hosadapter2 alias... Can an expert
vindicate for
me that modprobe is infact doing the correct thing? 


This event sent from IssueTracker by jkachuck 
 issue 133058
Comment 7 Denise Dumas 2008-05-09 09:57:01 EDT
IT was closed in November, closing this to match 
Comment 8 Konstantin Khorenko 2008-12-02 12:28:45 EST
One of your customers faced the same issue but with qla2xxx module on RHEL5.2 and as far as i understand anybody who has QLogic controller and set up RHEL5 will get incorrect initrd after a kernel update?

Is it really acceptable and thus - won't fix?

Note You need to log in before you can comment on or make changes to this bug.