Bug 317811
| Summary: | depending on modprobe.conf configuration, required modules are not included in the initrd. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Norm Murray <nmurray> |
| Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.0 | CC: | khorenko, tao |
| 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: | 2008-05-09 13:57:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
----- Additional Comments From chavezt.com (prefers email at
tinytim.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
----- Additional Comments From chavezt.com (prefers email at tinytim.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 IT was closed in November, closing this to match 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? |
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: