Red Hat Bugzilla – Bug 461086
Cannot install Fedora 11 on Compaq DL380 with Compaq Smart Array
Last modified: 2013-03-05 22:56:44 EST
Description of problem:
I cannot install Fedora 9 on a Compaq DL380 with a Compaq Smart/2 RAID controller. The controller has 4x18.2 SCSI disks attached in a RAID 5 configuration with a hot spare.
The installer claims that no disks are available for installation.
If I boot into rescue mode I can use fdisk to create partitions, use mkfs.ext3 to format the root partition, and even mount the partitions. If I try to start anaconda at this point it still does not see the disks as being available for install.
I have on the system
/dev/ida/c0d0, which is the RAID logical volume
/dev/ida/c0d0p1, System Utilities Partition
/dev/ida/c0d0p2, 1GB SWAP
/dev/ida/c0d0p3, ~33GB root partition (remainder of the disk)
None of these are ever visible within the installer regardless of what I do. I have tried noprobe, noacpi, acpi=off, acpi=noirq, askmethod, and an assortment of other options at the grub menu based off posts from individuals having problems with prior versions of Fedora; none of these have had any impact.
Steps to Reproduce:
1.Insert Fedora 9 Installation CD-ROM 1
2.Power on computer.
3.Follow the prompts until you get the screen for formatting your hard drive. Attempt to proceed
You will be notified that no disks were found in the system
Disks should be seen by the installer and installation should proceed normally
Can you switch to tty2 and get the output of lshal and attach it here?
Created attachment 315819 [details]
Output from lshal
Created attachment 315820 [details]
lspci -vv output
Created attachment 315821 [details]
The above, as well as what is included in this comment were the result of running the commands on tty2 when I got to the disk partitioning page of the installer. I did not pass any parameters at anytime during the boot process, load any drivers by hand, or anything else; the most I did was mount the disk to show that it was accessible, and then start the iscsi setup to (more easily) configure network access so I could ftp the files off...
Below is the output from running mount; previous commands were mkdir /disk and
mount /dev/ida/c0d0p3 /disk. Below is the result of ls -l /dev/ida
rootfs on / type rootfs (rw,relatime)
/proc on /proc type proc (rw,relatime)
/dev on /dev type tmpfs (rw,relatime)
/dev/pts on /dev/pts type devpts (rw,relatime,mode=600)
/sys on /sys type sysfs (rw,relatime)
none on /tmp type ramfs (rw,relatime)
/dev/sr0 on /mnt/source type iso9660 (ro,relatime)
/dev/loop0 on /mnt/runtime type squashfs (ro,relatime)
/selinux on /selinux type selinuxfs (rw,relatime)
/dev/ida/c0d0p3 on /disk type ext3 (rw,relatime,errors=continue,data=ordered)
brw-r----- 1 root disk 72, 0 Sep 4 17:22 c0d0
brw-r----- 1 root disk 72, 1 Sep 4 17:22 c0d0p1
brw-r----- 1 root disk 72, 2 Sep 4 17:22 c0d0p2
brw-r----- 1 root disk 72, 3 Sep 4 17:22 c0d0p3
hal isn't finding the drive, thus anaconda doesn't know about it.
I tried installing Fedora 10 Alpha and it also exhibited this problem. I tried openSUSE 11.0 as well and it works correctly, though my intention is to get Fedora 9 (or at least 10) working. I'm not even sure if YaST relies on hal the same way anaconda does; before now I didn't know anaconda relied on hal...
Have you tried Fedora 10 GA or Rawhide? In either case, can you let us know whether the issue is still happening, and give the current version of the HAL packages you're using?
Fedora 10 GA does not see the disk either. Fedora 11 Beta does see it as ida/c0d0 (/dev/ida/c0d0) which is correct, however when i choose to replace existing partitions or do a custom partition setup it fails and I'm prompted to save the debug info. However, it cannot properly initialize the network card (e100), so I can't save to the network, and if I try to save to the local filesystem (to a mounted foppy) nothing happens when I click OK. I'm still trying to come up with some way to get the info, but nothing yet.
When i attempt to do a network install I have the same problem with the network card no initializing properly, and when I attempt to do a text install it sees the disc, however no matter which partitioning scheme I choose it tells me there is not enough space (even if I choose to replace current system, etc.)
I can verify the hardware is good, as I have RHEL 5.3 installed and it is working properly.
I had to install an additional nic card temporarily as it appears I'm being hit by some bug in the e100 driver now too, and then had to do a VNC install, as the scp from the traceback tool would not complete unless the network was already up, but I'm uploading it now.
Created attachment 338652 [details]
traceback of partition attempt in Fedora 11 Beta install
I can confirm the same behavior on my Compaq DL380 with an integrated SmartArray2 controller. I was trying to do a new install of FC10 (on new disks) on a system running FC5. FC10 is unable to detect the ida drives in Anaconda. FC11beta detects the drives but crashes upon "custom partition".
I tested with FC11 preview, and it detects the drives, but crashes out immediately.
With FC11 due in days, I suspect this won't be resolved by then, but can we get this pointed to FC12 (or future or somesuch) instead of FC9, since it still occurs even in the latest beta?
I can't reliably install Fedora onto Compaq servers with a hardware raid controller.. that is an incredibly common configuration, right?
I can confirm this still does not work properly on FC11 Preview
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Have you tried with the latest hal package in Fedora 11 or tried Rawhide? In
either case, can you let us know whether the issue is still happening, and give
the current version of the HAL packages you're using?
Fedora Bugzappers volunteer triage team
Fedora 12 Alpha installs successfully installs on Compaq DL380 with a Compaq Smart/2 RAID controller.
Based on the information in comment 17 I am closing this bug, should you experience these symptoms again please file a new bug report against the applicable component. Thanks for the input.
Fedora Bugzappers volunteer triage team