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:
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.
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.
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.
Created attachment 302807 [details] this is a patch that might work maybe. Doug, can you try with the attached patch instead?
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
Ok, patch applied in 6.0.50-1 (building now)
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
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.
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.
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 please? 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 w/cciss also.
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.
http://koji.fedoraproject.org/koji/buildinfo?buildID=46610
mkinitrd-6.0.51-1.fc9 dist-f9 mkinitrd-6.0.49-1.fc9 f9-final 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 biased ;)
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
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/*. Help?
(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
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.