Bug 729919 - Anaconda dies if system includes a disk installed that was part of a raid array
Summary: Anaconda dies if system includes a disk installed that was part of a raid array
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-11 09:42 UTC by Ruth Ivimey-Cook
Modified: 2011-11-02 14:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-11-02 14:00:16 UTC

Attachments (Terms of Use)

Description Ruth Ivimey-Cook 2011-08-11 09:42:49 UTC
Description of problem:
I was recreating my fedora fileserver to f15, using a "new" disk as the boot disk.

This new disk had at one time been part of a raid array, and still had a raid superblock on it.

Anaconda dies when scanning drives (before partitioning the disk) if it comes across a raid disk that was part of an array but is not active.

Version-Release number of selected component (if applicable):
anaconda from recently downloaded F15 KDE Live CD.

How reproducible:
Always, given the presence of the disk. Resolved by using mdadm to stop the array and zero the superblock on the disk, so making the disk "plain" again, then restarting anaconda.

Steps to Reproduce:
1. Insert raid disk component (raid5 1 /4 in my case)
2. Run anaconda installer
Actual results:

Expected results:

Additional info:

Comment 1 Chris Lumens 2011-08-18 21:13:11 UTC
Can you attach either whatever error message you are seeing in a dialog (plus /tmp/storage.log) or /tmp/anaconda-tb-* if you are getting a traceback?  Thanks.

Comment 2 Ruth Ivimey-Cook 2011-08-18 21:23:00 UTC
Very sorry but I can't. At the moment it died, it was running off a CDROM so /tmp was in memory and died with it. I've worked around the problem - created the lvm array myself - and the system is now operational.

Comment 3 David Lehman 2011-08-18 21:53:02 UTC
Sorry for the inconvenience, but we purposely refuse to perform any destructive operation on such disks to avoid accidental loss of data due to misconfiguration. All that was required on your part was to remove the raid metadata. Anaconda could have done the rest for you without issue.

Comment 4 Ruth Ivimey-Cook 2011-08-19 00:01:08 UTC
My point in reporting this as a bug is that Anaconda crashes... no error message, no "I can't use that disk"... In my view a that type of software crash is _always_ a bug.

An acceptable resolution would be for Anaconda to note the existence of the drive but prevent its use, preferably with a message indicating why. At least then the savvy have the info needed to run mdadm (or whatever BIOS tool is appropriate).

A better option would be for it to indicate it's a partial raid array and require a special action to activate it, which would zap the metadata for you.

You say "all that was required... " but in fact it took around 1/2 hour and about 5 runs of the installer to work out why Anaconda crashed and then fix it: it wasn't at all obvious to me, and I do have past history in Linux.

Regards, Ruth

Comment 5 David Lehman 2011-08-19 13:17:43 UTC
My apologies. I must have mistaken the failure you are reporting for something similar. If you had provided some detail I would have known better. I still don't know exactly what failure you have seen.

Comment 6 Chris Lumens 2011-11-02 14:00:16 UTC
Without logs, there's really nothing we can do to debug this problem.  So much of storage problems are dependent on the initial state of the system that they're frequently very difficult for us to reproduce.  Sorry.

Note You need to log in before you can comment on or make changes to this bug.