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