Comment 15 for bug 22301

(In reply to comment #14)
> I'm not sure what dataloss you're referring to, unless you're talking about
problems with reformatting RAID partitions that hold
> data, and you don't want to reformat them.

At present, we have no user interface code for saying "this partition appears to
be part of an existing RAID set; are you sure you want to use it?" or for
displaying such partitions in a different way. We should certainly have such a
UI. Without that UI, though, the RAID configuration screen can't offer
partitions that appear to be part of an existing RAID set, because it could
easily cause people to overwrite their existing data with a new RAID by accident.

> I deleted all partitions and then created RAID partitions on the empty disks.
 Perhaps when a RAID partition is added, it needs to
> be flagged with something that says "this is an empty RAID partition, so you
can clobber it".

So, what happens is that, when you delete the partition, the partition manager
fails to zero the RAID superblock; all it really does is remove the entry from
the partition table. If you then create a partition starting at the same
position on the disk, the old RAID superblock will still be in place, and the
kernel will think that the partition is part of a deactivated RAID set. Your
/proc/mdstat confirms this:

  md0 : inactive hdd1[2]

To work around this, you need to do the following:

  mdadm --stop /dev/md/0
  mdadm --zero-superblock /dev/hdd1

It should then be possible (possibly after a reboot to de-confuse parted) to
proceed to use this as a physical RAID volume.

> Is there something about what I'm doing that makes this thing think that I
want to keep the data in the volumes?

It's definitely a partitioner bug that it doesn't zero out the superblock when
the partition is deleted, but with two days to go until the release candidate I
think I'd rather leave this as "known bug with known workaround" than as
"probable fix with unknown consequences".

Thanks for your patience!