Description of problem: MegaRAID 428/Dell PERCII driver loads during install, but states "No hard drives have been found. You probably need to manually choose device drivers for the installation to succeed. Would you like to select drivers now? [Y/N]". Version-Release number of selected component (if applicable): Fedora Core 3 Test 3 How reproducible: Begin installation of Fedora Core 3 Test 3 on a machine with a MegaRAID 428 card, AKA a Dell PERC II card. Steps to Reproduce: 1. Insert CD 2. Boot 3. Watch it autodetect your card, then say there are no hard drives found. Actual results: Fails with above message Expected results: Installs to the pre-configured drive array. Additional info: This same machine worked fine with Fedora Core 1 and 2 released versions. When you answer Yes to the question above, you see that the megaraid_mbox driver is listed in the detected hardware list. General specifications: Dual 300MHz P-II machine 128MB RAM Dell PERC II RAID card 3 80-pin SCSI hard disks configured in a RAID 5 array SoundBlaster 16 PNP card EISA/PCI slots 10 MBit NIC card (DEC 21040 chipset) If any questions or if additional info needed, please let me know. Brian
What kernel messages are there on tty3/tty4?
Created attachment 105110 [details] Output from dmesg during install. This is taken at the point where it says no hard drives are found.
If you need more than this, I haven't figured out how to scroll back in the tty to get more than just the screen I can see when I switch to tty3 and 4. If you'll kick me some instructions as to how to get what you most need, I'll be happy to get it. Thanks!
*** Bug 135496 has been marked as a duplicate of this bug. ***
*** Bug 135527 has been marked as a duplicate of this bug. ***
Additional information: Attempted to update to latest firmware levels for this card, but was unable to. Possibly firmware revision related? I'm currently at U.75, latest is U.84. If newer firmware is needed, that puts me clean out of the running on this card, which refuses to update.
I have no new information to add here. I'd simply like to add a "me 2" to reinforce the point that this isn't an isolated instance. I removed RedHat 9 from a PowerEdge 2400 running a Perc2/Si (Megaraid) card and tried to install FC3 test 3, and observed the exact behavior described in this bug thread.
The PERC series, the HP NetRAID 3Si, 1M, and the MegaRAID Express 500 use the megaraid driver as they are all either LSI or OEM of LSI MegaRAID cards. They all seem to experience the same issue of not recognizing logical drives with the driver included in FC3. This is not firmware dependant as different firmware results in the same symptom. The installer will report "No drives found" when trying to use the SCSI RAID controller. Apparently this was an update to the installer for FC3 that fails to work with these controllers. It recognizes there is a RAID controller present but unlike the driver in FC1 and FC2 it is not able to see or use the presented logical drives. In testing, both the NetRAID 1M and the MegaRAID Express 500 (on various versions of firmware) display the same issue in the test system. The cards work fine with the driver used in the installation of FC1, FC2, RHEL 2.1 and RHEL 3. This issue will likely affect anyone attempting to use any version of these SCSI adapters with FC3.
Thanks for the update, Dave! FYI, the new driver was supposed to have been piloted out with FC3 test 2, but was not properly inserted, something about a wrong file name. When FC3 test 3 came out, the driver was loaded for the card, but saw no hard disk drives. Clearly the problem is related to the new driver, but this information shoots down my theory. (My theory was that the new driver required more up-to-date firmware to provide it with whatever expected services the newer firmware have that older versions did not.) Anyway, that being said, there does seem to be some activity on the Linux Kernel Mailing list, but none of it (on an initial Google scan) indicates any problems along these lines. Any theories or additional information? Brian
The megaraid driver has been replaced with a two-part driver - the management module (megaraid_mm) and the low-level driver (megaraid_mbox) that is supposed to interface with the hardware. LSI's description is, "The Common Management Module is implemented in megaraid_mm.[ch] files. This module acts as a registry for low level hba drivers. The low level drivers (currently only megaraid) register each controller with the common module." The megaraid_mbox driver is supposed to understand the firmware control commands for all classes of controllers from LSI. Obviously there's a problem with legacy/low-end controllers. Even with the newest firmware from LSI, the MegaRAID Express 500 I have is not able to work with this driver. According to LSI, "The lower level drivers now understand only a new improved ioctl packet called uioc_t. The management module converts the older ioctl packets from the older applications into uioc_t. After driver handles the uioc_t, the common module will convert that back into the old format before returning to applications." In theory, this is a great idea. Obviously in this implementation it doesn't work with legacy controllers yet. Including this new driver in FC3 without option for the legacy megaraid driver might not have been such a good idea when there are so many of these controllers still in use. It appears that either the firmware control commands are slightly different or something is just wrong between the two driver components where logical drive information is not being passed to the OS. The only option I can think of off hand would potentially be a driver disk with a legacy version of the megaraid driver that could be installed using the "linux dd" install option. Another option would be a different RAID controller like the Smart Array that does not use this driver. Hopefully LSI Logic will fix the problem in future updates to their driver (and they may have already addressed the issue since I haven't seen what version Red Hat used here). Even then, the installer for FC3 will still be broken without a new release.
Just wanted to confirm I'm having the exact same problem on a Dell PowerEdge 6450 that uses the PERC2/DC. FC 2 installed fine, but FC3 is behaving as described.
I encountered this problem today as well with a Dell PE2300 while trying to install FC3. Now what...
Ditto for a Dell PowerEdge 2300 with the MegaRAID 466. Could someone *please* post a driver disk with the legacy driver so we can get on with things?
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138590 Cross reference to identical bug identified in FC3 released version.
I have one of these cards too. It appears that the megaraid_legacy module was never compiled. Note that this seems to also be a problem on the latest 2.6.9 FC2 kernel as well. megaraid driver is gone, replaced with megaraid_mbox, which only supports the newer cards. (according to /lib/modules/2.6.9-1.3_FC2/build/drivers/scsi/megaraid/ Kconfig.megaraid)
Same thing happens on a HP Netserver LH3. No problems with FC2. Eagerly awaiting fix/legacy driver disk... please?
I just tried building a kernel from the 684 source rpm with CONFIG_MEGARAID_NEWGEN=n in the config. It fails with: + for i in '*.config' + mv kernel-2.6.9-i586-smp.config .config ++ echo kernel-2.6.9-i586-smp.config ++ cut -d- -f3 ++ cut -d. -f1 ++ sed -e s/i.86/i386/ -e s/s390x/s390/ -e s/ppc64.series/ppc64/ + make ARCH=i386 nonint_oldconfig CONFIG_MEGARAID_LEGACY make[1]: *** [nonint_oldconfig] Error 1 make: *** [nonint_oldconfig] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.9681 (%prep)
I have a Dell poeredge 2600 and I updated to FC3 from FC2 using apt-get , the update went fine but the system will not boot the new kernel i.e. 2.6.9-1.681_FC3smp, but the older kernels from FC2 i.e 2.6.8-1.521smp work fine.Are there any plans to release updated kernel for FC3 with this bug removed.
It seems Novell/SuSE has opted to include both megaraid drivers in their latest release and it is selectable at installation time. This would be a nice feature for Red Hat/Fedora to include. As you can see from the "New" status of this and other related bug reports for both Fedora and RHEL, no one from Red Hat has accepted there is an issue with the new driver yet. FC3 made it to full release buggy. The question now is will they release the same bug in Enterprise Linux 4?
Can we hear from a redhat developer on the status of this bug, and whether they are even considering it as a bug or not.
Yes, could we please hear something about whether Fedora will follow SuSE's lead on a workable install? It makes a difference on how some us us proceed.
the current tree in cvs has both drivers enabled. It'll go out soon to updates-testing.
What kind of lead time is usually involved from updates-testing stage to an iso release (or some other workable way for mortals to install)? Thanks much for the information so far given, Dave.
the next ISOs created will be FC4-test1 (sorry, dont have dates for when). For these, the same fix has already been checked into the kernels you can pick up from rawhide. As for updates-testing stuff, it sits there until I'm happy that any issues that arise through testing are resolved. (Right now theres 1-2 nasties that still need fixing before we can push out a proper update).
The smp and non-smp kernels in rawhide work like a champ on my 466 controller. Thanks!
OK, I see the rawhide smp kernel at http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/Fedora/RPMS/kernel-smp-2.6.9-1.1021_FC4.i686.rpm but it's not coming to me how to install a kernel rpm on a system that can't see its disks, even though I know my way around /boot. Probably not the right place to ask.
138590 has solution.
138590 solution worked a treat - perfect! Thank you!
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Just yum updated to 2.6.12-1.1372_FC3smp from 2.6.11-1.35_FC3smp. As usual, kudzu switched modprobe.conf from megaraid aliases to megaraid_mbox, so I applied my usual workaround of fixing it back and remaking the initrd image (as posted in bug 138590). Now even the workaround doesn't work. Get the "no drives found" and kernel panic. This is a PERC2/DC.
Latest mkinitrd-4.1.18.1-1 does allow modprobe.conf and mkinitrd fix in comment 37 of bug 138590 to work again. Can now run kernel-smp-2.6.12-1.1372_FC3 with legacy megaraid after applying fix. Since fix is necessary only because kernel rpm install changes existing megaraid aliases to megaraid_mbox in modprobe.conf, it would be nice if it stopped doing that.
That's /sbin/module_upgrade (part of kudzu)'s doing. Bill ?
WC: What pci id is this for?
lspci info for this PERC2/DC: 03:0c.1 Class 0e00: 8086:1960 (rev 02) (prog-if 01) Subsystem: 1028:0467 Flags: bus master, medium devsel, latency 64, IRQ 169 Memory at f8000000 (32-bit, prefetchable) [size=4M] Capabilities: [80] Power Management version 2
Does this look like something that can be addressed by a new version of Kudzu? If it helps, here is the output of "lspci -vv" for the PERC2/DC on my system: 04:02.0 PCI bridge: Intel Corp. 80960RP [i960 RP Microprocessor/Bridge] (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64, Cache Line Size 10 Bus: primary=04, secondary=05, subordinate=05, sec-latency=64 Memory behind bridge: fe800000-fe8fffff Prefetchable memory behind bridge: fba00000-fbafffff Secondary status: 66Mhz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 04:02.1 I2O: Intel Corp. 80960RP [i960RP Microprocessor] (rev 02) (prog-if 01) Subsystem: Dell PowerEdge Expandable RAID Controller 2/DC Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 64, Cache Line Size 10 Interrupt: pin A routed to IRQ 177 Region 0: Memory at fc000000 (32-bit, prefetchable) [size=4M] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
From User-Agent: XML-RPC hwdata-0.146.1-1 has been pushed for FC3, which should resolve this issue. If these issues are still present in this version, then please re-open this bug.
This fix is confirmed for install of kernel-smp-2.6.12-1.1376_FC3 with the PERC2/DC identified in comment 34. No modprobe/initrd quirks seen. Yippee. Thanks, Dave, Bill, RedHat.