Bug 442811 - mkinitrd not adding cciss module to initrd
mkinitrd not adding cciss module to initrd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
NEEDSRETESTING
:
Depends On:
Blocks: fedora-ia64 F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-04-16 18:28 EDT by Doug Chapman
Modified: 2013-01-09 23:40 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-27 13:34:16 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)
log from mkinitrd -v (7.31 KB, text/plain)
2008-04-16 19:29 EDT, Doug Chapman
no flags Details
patch to fix mkinitrd on cciss (541 bytes, patch)
2008-04-17 12:45 EDT, Doug Chapman
no flags Details | Diff
this is a patch that might work maybe. (985 bytes, patch)
2008-04-17 16:50 EDT, Peter Jones
no flags Details | Diff
fix (1.18 KB, patch)
2008-04-18 12:34 EDT, Doug Chapman
no flags Details | Diff

  None (edit)
Description Doug Chapman 2008-04-16 18:28:00 EDT
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
the initrd.img.

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):
mkinitrd-6.0.43-1.fc9
(I am now building a new ia64 tree with mkinitrd-6.0.47-1.fc9 to see if that
addresses the issue)


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Doug Chapman 2008-04-16 19:29:09 EDT
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
this case.
Comment 2 Doug Chapman 2008-04-17 11:15:36 EDT
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
is resolved.
Comment 3 Doug Chapman 2008-04-17 12:45:14 EDT
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
properly.

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.
Comment 4 Peter Jones 2008-04-17 16:50:03 EDT
Created attachment 302807 [details]
this is a patch that might work maybe.

Doug, can you try with the attached patch instead?
Comment 5 Doug Chapman 2008-04-17 17:14:47 EDT
Peter,

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).

- Doug
Comment 6 Peter Jones 2008-04-17 17:23:20 EDT
Ok, patch applied in 6.0.50-1 (building now)
Comment 7 Doug Chapman 2008-04-18 12:07:53 EDT
Peter,

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.

- Doug
Comment 8 Doug Chapman 2008-04-18 12:18:05 EDT
Peter,

Yup, the patch is broken.  The while bails on the first pass if the
/sys/block/$device file exists and $sysfs never gets set.

Comment 9 Doug Chapman 2008-04-18 12:34:04 EDT
Created attachment 302903 [details]
fix

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.
Comment 10 Peter Jones 2008-04-18 17:33:46 EDT
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?
Comment 11 Doug Chapman 2008-04-18 18:59:57 EDT
(In reply to comment #10)
> 
> Could you please use "diff -uP" instead of "diff -c" in the future?  Pretty
please?

Oops, sorry, meant to do a patch diff but that's what I get for rushing.
Comment 12 Jeremy Katz 2008-04-23 22:39:10 EDT
Is this fixed now?
Comment 13 Doug Chapman 2008-04-24 16:16:06 EDT
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
w/cciss also.
Comment 14 Doug Chapman 2008-04-24 17:50:23 EDT
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.
Comment 16 Warren Togami 2008-04-25 11:03:43 EDT
mkinitrd-6.0.51-1.fc9 dist-f9
mkinitrd-6.0.49-1.fc9 f9-final

Was .51 meant to be requested for F9?
Comment 17 Doug Chapman 2008-04-25 11:29:31 EDT
(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
biased ;)
Comment 18 Bug Zapper 2008-05-14 05:33:40 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Robert Scheck 2008-05-17 17:21:51 EDT
At least mkinitrd-6.0.52-2 works for me here on a i386/i686 system.
Comment 20 David Juran 2008-09-09 04:49:21 EDT
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...
Comment 21 Eric Paris 2008-09-29 09:39:58 EDT
Just a meme post....

mkinitrd-6.0.64-1.fc10.x86_64 == teh broked
Comment 22 Paul Moore 2008-10-08 17:12:25 EDT
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/*.

Help?
Comment 23 Doug Chapman 2008-10-08 17:23:05 EDT
(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/*.
> 
> Help?

Paul,

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.

- Doug
Comment 24 Jesse Keating 2008-10-24 20:14:08 EDT
Can we please get this re-tested with F10 Snap3 or later?
Comment 25 Doug Chapman 2008-10-27 13:34:16 EDT
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.

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