Red Hat Bugzilla – Bug 442811
mkinitrd not adding cciss module to initrd
Last modified: 2013-01-09 23:40:10 EST
Description of problem:
I saw this on an ia64 system, will try it again on an x86_64 that has cciss (HP
Smart Array controller) tomorrow.
When installing to a /dev/cciss/ device the cciss module does not get added to
If I manually create an /etc/modprobe.conf that contains:
alias scsi_hostadapter cciss
and re-run mkinitrd it does get created properly.
Version-Release number of selected component (if applicable):
(I am now building a new ia64 tree with mkinitrd-6.0.47-1.fc9 to see if that
addresses the issue)
Steps to Reproduce:
Created attachment 302682 [details]
log from mkinitrd -v
I upgraded to mkinitrd-6.0.47-1.fc9 and still see the issue.
I am attaching a log from running mkinitrd with the -v option. I see that it
does try to find the driver for cciss/c1d0p3 (which is the device my root LV is
on). I will dig more tomorrow to see why it doesn't find the cciss module in
I see the same thing on an x86_64 HP DL585 w/cciss installed with F9-beta. I am
raising the severity of this because nearly all new HP proliant systems have
cciss as the only storage and none will be able to install Fedora 9 until this
Created attachment 302764 [details]
patch to fix mkinitrd on cciss
The problem is that a device cciss/c0d0p2 corresponds to the sysfs entry
cciss!c0d0p2. This patch modifies the device name so that it finds it in /sys
When this info used to be in /etc/modprobe.conf this wasn't a problem since
mkinitrd pulled in the module based on that.
Please consider this patch for F9 as nearly _all_ new HP server systems (both
x86_64 and ia64, also some high end workstations) are shipped with cciss
storage devices as the only storage.
Created attachment 302807 [details]
this is a patch that might work maybe.
Doug, can you try with the attached patch instead?
Yes, your patch does the trick as well. I like your changes since it will catch
other devices with a / in the name and not just cciss (assuming there are others
and that they also replace / with ! in sysfs).
Ok, patch applied in 6.0.50-1 (building now)
I think this patch is now causing issues on non-cciss disks. I just installed
on a system that use the fusion mpt driver and it does not have that module.
I appologize, yesterday when I tested your patch I only tested it on a cciss
system, not on a system without cciss. I think it breaks there, I am debugging
now and will report back very soon.
Yup, the patch is broken. The while bails on the first pass if the
/sys/block/$device file exists and $sysfs never gets set.
Created attachment 302903 [details]
The fix is to get rid of the while loop. In order to handle cases where it
might have more than one '/' I added a g to the end of the sed command also
(which is my guess as to why the while loop was there).
Tested on systems with and without cciss this time.
Yeah -- I was thinking there might be a problem with the
"cciss!c0d0/cciss!c0d0p1" case, but I think we always get handed "cciss/c0d0p1"
here, never "cciss/c0d0/cciss/c0d0p1" (which obviously won't work with this plan
anyway, now that I think about it)
Could you please use "diff -uP" instead of "diff -c" in the future? Pretty please?
(In reply to comment #10)
> Could you please use "diff -uP" instead of "diff -c" in the future? Pretty
Oops, sorry, meant to do a patch diff but that's what I get for rushing.
Is this fixed now?
Working for me now on ia64 with mkinitrd-6.0.51-1.fc9.
Tested with cciss and regular scsi disks. I am about to do an x86_64 install
All of the mirros I can find still have mkinitrd-6.0.49 for x86_64 which still
was broken so I am unable to verify this is fixed on x86_64.
Was .51 meant to be requested for F9?
(In reply to comment #16)
> mkinitrd-6.0.51-1.fc9 dist-f9
> mkinitrd-6.0.49-1.fc9 f9-final
> Was .51 meant to be requested for F9?
It needs to be in F9 since you cannot install to HP smart array devices without
this. Since probably 90% of the new HP proliant and Integrity servers use smart
array that sounds like a blocker to me, but then again I work for HP so I am
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
At least mkinitrd-6.0.52-2 works for me here on a i386/i686 system.
Yes, this was working on F9 but seem to have broken again in rawhide with mkinitrd-6.0.62-1.fc10 )-: cciss modules are again not included.
Changing the version to rawhide...
Just a meme post....
mkinitrd-6.0.64-1.fc10.x86_64 == teh broked
Before I go and file another BZ ... would this problem cause the Fedora 10 Beta 1 release to not show any cciss drives in Anaconda? When attempting to do an install of F10B1 on a system with a cciss adapter Anaconda does not show any drives in the disk partitioning screen but if I switch over to another virtual console with a shell it appears that the cciss driver is loaded (checked dmesg) and the disks are visible in /dev/cciss/*.
(In reply to comment #22)
> Before I go and file another BZ ... would this problem cause the Fedora 10 Beta
> 1 release to not show any cciss drives in Anaconda? When attempting to do an
> install of F10B1 on a system with a cciss adapter Anaconda does not show any
> drives in the disk partitioning screen but if I switch over to another virtual
> console with a shell it appears that the cciss driver is loaded (checked dmesg)
> and the disks are visible in /dev/cciss/*.
That would certainly be a different issue. It sounds like an anaconda bug given how you mention the disks do appear to be there in /dev.
Can we please get this re-tested with F10 Snap3 or later?
I have tested and verified this in last night's rawhide build with mkinitrd-6.0.67-1.fc10.x86_64. It is working properly now.