did you try dmraid -rE?

A similar thing was in F11, with the workaround:
http://tinyurl.com/ycehlyw

Tried to find the "array" with dmraid, and could not because not enough disks of the array were present.  I figured that if I found it I could undo it with the util.  But no luck. Didn't try the -rE thing, but I would suspect that you kind of need to to be find I suspect to run the -rE thing.

You can use "dmraid -rE [-f ...]" on a single device.
Use it and remove the ATARAID metadata in turn on all the devives in question.

Interesting  I had figured if it would not find it in the list it would not removed it.   I will have to try this in the future.

Also note that the util-linux-ng version in F-13 has a wipefs command which should
do pretty much what you want, so I think this bug can be closed.

But will it really wipe the WHOLE file system and leave you with a fresh disk?

OK Hans you asked for it. ;-)  I have a set of drives from a dmraid array we outgrew.   They have high sensitivity data on them so I could not just toss them, but was waiting until I had time to full destroy and bulk erase them.  I just checked and they will not allow me to reinstall linux on them without being part of the original array.   So I have put them aside, and as soon as you bring out the alpha I will be building up a server and testing this wipefs thing.   If it doesn't work you will be hearing from me ;-)

> But will it really wipe the WHOLE file system and leave you with a fresh disk? 

Nothing can really do that (short of physically breaking down the disks & then melting the scrap metal - there actually are organisations out there that consider this a requirement for storage disposal).

Using dmraid -E, wipefs or even just regular 'dd' is about as good as you'll get on modern disks writing from the host side. Note that wiping metadata with dmraid -E will not touch the data on the disks - a determined attacker could probably still reconstruct something useful from this.

Reading the documentation for wipefs it seems to be strictly for cleaning up device labels - it makes no claim to be a "secure erase" tool.

Some modern disks also have a "secure erase" facility built into the firmware that tools like smartctl can access (but check with your data disposal guidelines to make sure this is an acceptable level of erasure).

There was a very long thread on fedora-list discussing this last year.

If in doubt: physically destroy the disks or never allow them to leave your site.

Maybe I was not specific enough here in the purpose.

The purpose here is not erasing for security.   Frankly disassembly, a bulk eraser for video tape, and a 357 takes care of that problem ;-)   And the last part of very relaxing after a hard week of dealing with users :-)  :-)  ;-)

The issue is reuse or in many cases just USE.   Or the issue is reloading the OS on the same machine with a slightly different configuration.  Anaconda/linux  keeps detecting that these drives are part of a dmraid array (or lvm set) and insisting that it can't proceed without the entire set of drives and then insists that any new install use the exact same configurations.  There doesn't seem to be a way to simply say "this drive is to be treated as if it is a brand new drive, please ignore all data about how it is set as part of an array, volume set, or other."   Yeah there is an option for "use whole drive" in anaconda, but if the drive has been part of a dmraid or lvm system this will be detected first before this, and you can only then use the whole dmraid system or the whole lvm system as it was originally on the disk as the "whole drive".

A bit of fiddling will generally get the lvm stuff to go away, but I also find that more than just erasing the partition entries is needed.   But it can be done.   That is why it was not directly mentioned here.   But I have yet to find a way to get a dmraid drive or system of drives to be reset to the point where they can be reused in any meaningful manner in other than the exact same configuration with the exact same make and model of controller card.   Which since controller cards can fail and you do frequently want to change things this is not good.

Certainly I see nothing wrong with and a lot right with the system detecting these and saying "hey this is part of an array or volume system if you reuse it then the rest of the drives may become useless" but this refusal inability to reuse drives, that is problematic.

IIRC we agreed, that Anaconda needs to offer such "treat as new disk, You know what you're doing!?" option. Hence closing the dmraid bug.

Hi,

(In reply to comment #10)
> IIRC we agreed, that Anaconda needs to offer such "treat as new disk, You know
> what you're doing!?" option. Hence closing the dmraid bug.    

That is not how I remember things :) Anaconda currently has a warning dialog that a disk is being ignored because it is part of an incomplete BIOS RAID set. That is all anaconda does. The reason we don't offer a "nuke all metadata" button in that dialog is because we consider that to dangerous of a thing to do with just a single click.

When users hit this, we end up advising them to do:
dmraid -rE /dev/diskfoo

See for example:
https://fedoraproject.org/wiki/Common_F11_bugs#dmraid-nodmraid

Where we are also pointing F-12 and F-13 users too. The problem is that
dmraid -rE /dev/diskfoo

Does not always work, yet:
blkid -o udev -p /dev/diskfoo
Says it is a BIOS RAID set member

Note that this bug is in essence the same as 517761, which you've just closed WONTFIX.

I guess this is an RFE to be able to do:
dmraid -rE --force /dev/diskfoo

And then have dmraid remove Firmware RAID signatures even if they do not check out 100%. IOW then have dmraid remove invalid / damaged Firmware RAID signatures.

Note though that util-linux-ng now a days has a wipefs command which should do exactly what we want. So I guess that the answer to this bug is not "CANTFIX", but is use:
wipefs /dev/diskfoo
instead of:
dmraid -rE /dev/diskfoo

Note that I've not tested this!

Regards,

Hans