User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 I am installing F12 on an HP ML-350 G6 with SAS drives connected to a Smart Array P410i controller. After the "keyboard type" selection, a pop-up window with "Finding storage devices" appears. At this point, the installation hangs. I've left it for over an hour with no movement. Installing F11 on the same machine proceeds normally; installing F12 from the same DVD on other (non ML-350) machines also works. Reproducible: Always Steps to Reproduce: 1. Boot from install DVD 2. Click "Next" on intro, language, and keyboard type 3. Actual Results: Hangs with "Finding storage devices" pop-up Expected Results: Continue install Machine is a new HP ML-350 G6 with an Intel quad core processor, 4 Gb memory, 2 72 Gb SAS drives connected to a Smart Array P410i configured as RAID 1. There is also a DVD drive and a USB DAT tape. There are no other storage or USB devices attached. The same result occurs when the tape is disconnected. After the hang, I've gone to the console session. dmesg shows that the controller was recognized and the HP CISS driver v 3.6.20 was loaded. The disk information is correct and it sees that there are three partitions on the drive (from the F11 installation). The appropriate entries in /dev (/dev/cciss/c0d0, /dev/cciss/c0d0p1, etc.) are present. Console session 1 shows the message "udevadm settle - timeout of 30 seconds reached" followed by an event queue listing with an entry for the disk device (c0d0) and one for each of the three partitions. Console session 3 shows (I assume) debug entries from anaconda. The last two are "added disk cciss/c0d0 (id 1) to device tree" and "looking up parted Device: /dev/cciss/c0d0". After the hang, on rebooting, the controller reports "a controller failure event (lock up code 0x12)".
(In reply to comment #0) > Console session 1 shows the message "udevadm settle - timeout of 30 seconds > reached" followed by an event queue listing with an entry for the disk device > (c0d0) and one for each of the three partitions. > Hmm, can you try again with this updates.img: http://people.fedoraproject.org/~jwrdegoede/updates-544177.img (Add "updates=http://people.fedoraproject.org/~jwrdegoede/updates-544177.img" to the end of the syslinux loader cmdline when starting the installer). > Console session 3 shows (I assume) debug entries from anaconda. The last two > are "added disk cciss/c0d0 (id 1) to device tree" and "looking up parted > Device: /dev/cciss/c0d0". > > After the hang, on rebooting, the controller reports "a controller failure > event (lock up code 0x12)". Hmm, this could be a kernel issue then, but the timeout reached is not good either (although that could be caused by the kernel issue). As said can you please try with the provided updates.img. And when you do that, please also switch to tty2 (Console session 2) and save the log files under /tmp somewhere, you can use for example scp to get them of the system, and then attach the log files to this bug report. Thanks, Hans
Created attachment 377277 [details] anaconda log from requested test
Created attachment 377278 [details] program.log from requested test
Created attachment 377279 [details] storage.log from requested test
Created attachment 377280 [details] syslog from requested test
I've retried the install with the requested update, and attached the log files. Thanks! -- bill
(In reply to comment #6) > I've retried the install with the requested update, and attached the log files. > > Thanks! > OK, looking at the syslog it seems this indeed is a kernel bug changing component to kernel. As the hung task dump includes a usb stack trace, you could try disconnecting your USB dat tape drive for the installation.
Actually, the tape drive *was* disconnected during the test. There was nothing connected to any USB port. -- bill
Some additional information: I've found that it works if I specify acpi=off at boot. -- bill
I want to thank you for this information. I ran into the same problem installing Fedora 12 on HP DL380 G6 server. I disabled the acpi support like you suggested and it worked fine. So thank you again for sharing this information.
Thanks for posting this Bill. This has saved me as well. HP ML370 G6, Smart Array P410i, 500GB SAS's. Started with F11, then decided to go with F12, found the same bug.
Another follow-up: I've updated the firmware for the P410i to HP's latest as of this date - version 2.74(B) dated 12 Feb 10. Same problem.
Yet another follow-up, in case this helps the developers. Today I configured an HP DL-160. It has the Smart Array P410, which, if I understand correctly, is the same as the P410i, but is a PCI card rather than on the motherboard. The P410 works fine.
I had the same problem with a HP DL-350 G6. Problem goes away and everything seems to work fine if I disable VT-d in the BIOS.
I have confirmed this works on the ML-350 as well - specifically, if VT-d is disabled in the BIOS, I can remove the acpi=off from the boot options and the machine boots with no problem. Turning VT-d back on causes the hang after boot. As a side note to my comment in #13, it runs out that the DL-160 has all virualization turned off by default, so presumably that's why the DL-160 worked while the ML-350 did not.
Same problem on HP DL360 G6 servers running Fedora12. Servers would crash while booting up unless acpi=off parameter was included in grub. Disabling VT-d in BIOS fixed the issue and we can now run Fedora 12 fine.
HP DL380 G5 also has the same issue. This looks like it is more Linux generic, I have seen issues with other distros that seem to be related to this type of raid controller and VT-d (kernel panics, failures to initialize drives, etc).
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.