Installer does not detect hard drive partitions

Bug #573618 reported by ronny
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: ubiquity

I tried installing Ubuntu 10.04 but the installer does not detect any hard drive partition. In /var/log/user.log I noticed the following line:
------------
... ubuntu activate-dmraid: Serial ATA RAID disk(s) detected. If this was bad, boot with 'nodmraid'.
------------

So I rebooted with the nodmraid option selected. Unfortunately, the installer still did not detect any hard drive partition. The messages in /var/log/user.log now read:
------------
... ubuntu activate-dmraid: Serial ATA RAID disk(s) detected. If this was bad, boot with 'nodmraid'.
... ubuntu activate-dmraid: Enabling dmraid support.
... ubuntu dmraid-activate: WARNING: dmraid disabled by boot option
------------

So, basically, the system decided that my choice of 'nodmraid' was stupid and ignored it. I had to fire up KPackageKit and remove the dmraid and libdmraid packages so that the installer could detect my hard drive partitions.

This bug is a regression since Ubuntu 9.04 where installation works out-of-the-box. Installation fails identically with Ubuntu 9.10 and Ubuntu 10.04.

Here is the output of lspci on my system:

00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 02)
00:01.0 PCI bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE Host-to-AGP Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV44A [GeForce 6200] (rev a1)
02:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 80)
02:04.0 RAID bus controller: Promise Technology, Inc. PDC20376 (FastTrak 376) (rev 02)
02:05.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5702X Gigabit Ethernet (rev 02)

Revision history for this message
ronny (ronny-standtke) wrote :
Revision history for this message
ronny (ronny-standtke) wrote :
Revision history for this message
Willem Ligtenberg (wligtenberg) wrote :

Today I had a similar experience and so did: http://www.longren.org/2010/05/11/how-to-make-ubuntu-recognize-all-drives-during-install/

I had to remove dmraid from the livecd session to see all the drives in my computer. Even though I don' use raid!

Revision history for this message
Mendez (ubuntu-mendez) wrote :

The solution in this link ("sudo apt-get remove dmraid") worked for me, however the "nodmraid" boot option didn't (assuming I did it correctly).

At least one of the drives in the system has been used for RAID in the past which likely explains the cause. There is perhaps a problem though that previously the Alternative installers would detect this and ask you about it whereas the Desktop installers wouldn't look for it - the situation now seems to be that the Desktop CDs are silently ignoring anything they're confused about.

Revision history for this message
D. Hugh Redelmeier (hugh-mimosa) wrote :

See this bug that has been determined (correctly, I think) to be "not a dmraid bug" https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/543008

My particular experience was quite a surprise and wasted a lot of time. Some details are in that bug report.

dmraid decided that my (only) disk was part of (broken?) RAID array so Ubiquity wouldn't even show its partitions. It never told me why. I could not guess because the drive had never been part of a RAID nor did the machine have Promise hardware. Still a mystery.

My fix was to delete the RAID fingerprints from the disk (sudo dmraid -r -E). Easy, once I knew that this was the problem.

Feature request: make ubiquity report detected broken RAID arrays. Say *why* disks are being ignored.

BTW, why does https://bugs.launchpad.net/ubiquity say "Ubiquity does not use Launchpad for bug tracking."?

Revision history for this message
ronny (ronny-standtke) wrote :

I just installed a completely new hard drive in my system (I guess it has no RAID fingerprints on it by default that I have to delete), booted with the Kubuntu-10.10 CD and... run into just this bug again. Too bad...

Revision history for this message
Claude Oesterle (cfoesterle) wrote :

In my case, I had two WD 160GB SATA HDD's that had been part of a Asus/Promise raid configuration on another system, that I wanted to reuse again on newer systems used for Ubuntu/Windows dual boot. I had to both go back and use the BIOS raid setup on that older system to remove them from the raid configuration, and then run "sudo dmraid -r -E /dev/sda" afterwards from an UBUNTU CDROM bootup window to completely clean these disks up before the UBUNTU installer would recognise and use them. Even running a "sudo dd if=/dev/zero of=/dev/sda" before hand did not clean out whatever metadata gets installed by the raid controller on these disks. Only the Ubuntu installer had this issue, Windows XP did not apparently care about the raid metadata.

Revision history for this message
Gurv (gcfs) wrote :

I have add this bug on two different computers (one never had any raid activated) with 2 versions of ubuntu : 10.10 and 11.04.
I am quite disappointed by Ubuntu, seeing as this bug is not even taken care of, more than a year later.
Especially since it breaks user experience so bad.
Meanwhile Windows just installs fine...

tags: added: ubiquity-2.2.23
tags: added: lucid
Revision history for this message
Mauricio Mora Meza (mauricio.mora) wrote :

Hahahaha!
Being Aug.2013 and this problem/bug remains the same :D
openSUSE installs easily in that hdd with raid, but it does not detect any windows to dual boot.
Ubuntu's 12.04, 12.10 and 13.04 just do not see any hdd/partition. Really sad. I will have to backup Windows and try to remove/deactivate RAID.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Phillip Susi (psusi) wrote :

If you no longer wish to use the drives in raid mode, you must destroy the raid volume with either the bios utility, or dmraid -E.

Changed in ubiquity (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
DrPsychick (drpsychick) wrote :

I'm new to launchpad, but I've been using Ubuntu personally and at work for many years now. I never had this problem until yesterday.
A 250GB Disk with Ubuntu 14.04 32bit installed. Put it into a new computer which is capable of 64bit. Realized that a reinstall would be the best option and rebooted with Ubuntu 14.04 USB stick to install Ubuntu.

Same error: Step 3 "Installation Type" shows the disk in the dropdown without a name and absolutely no partitions -> no way to install. The disk is fine though, I can even boot the 32bit Ubuntu etc.

After stumbling upon this thread, doing a simple "dmraid -r -E", I could install just fine.
The disk was NEVER used in a raid, Ubuntu 32bit was installed from CDROM or USB stick as well without any issues.

Seems to happen not very often, but to improve ubiquity I would too suggest to check for broken raid metadata and inform the user instead of leaving him in the dark.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.