Bug 729919

Summary:	Anaconda dies if system includes a disk installed that was part of a raid array
Product:	[Fedora] Fedora	Reporter:	Ruth Ivimey-Cook <ruth>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	anaconda-maint-list, jonathan, vanmeeuwen+fedora
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-11-02 14:00:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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
3.
  
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.