Is there any way to remove/delete/deactivate RAID metadata (aka
"signatures") from my hard drives? A long time ago I had the drives in
a RAID set, but quickly reconsidered and decided to use them as
independent drives. My disaster-recovery CD (for restoration of a
disk image) boots into SuSE Linux (with DMRAID) and insists on seeing
the two drives as a RAID set because of the metadata present on them.
Thus, the disaster-recovery CD is useless. I want to remove the
metadata from these drives so the recovery CD will see them as
separate drives. I have gone into the SATA/RAID BIOS for my Silicon
Image 3112 controller, but it reports that no RAID sets exist and that
there are no conflicts to resolve. Can anyone advise? Would the
DMRAID tool allow me to deactivate the metadata? Many thanks.

Previously Howard Griffin <(E-Mail Removed)> wrote:
> Is there any way to remove/delete/deactivate RAID metadata (aka
> "signatures") from my hard drives? A long time ago I had the drives in
> a RAID set, but quickly reconsidered and decided to use them as
> independent drives. My disaster-recovery CD (for restoration of a
> disk image) boots into SuSE Linux (with DMRAID) and insists on seeing
> the two drives as a RAID set because of the metadata present on them.
> Thus, the disaster-recovery CD is useless. I want to remove the
> metadata from these drives so the recovery CD will see them as
> separate drives. I have gone into the SATA/RAID BIOS for my Silicon
> Image 3112 controller, but it reports that no RAID sets exist and that
> there are no conflicts to resolve. Can anyone advise? Would the
> DMRAID tool allow me to deactivate the metadata? Many thanks.

Complete disk/parition blanking under Linux:

cat /dev/zero > /dev/hd<target> (or /dev/sd<target> for SCSI/SATA)

or with comfortable progress output

dd_rescue -w /dev/zero /dev/hd<target> (see above)

This will remove any data from the drive, including the
matadata. If this is Linux software RAID, you can speed things
up by overwtriting only the last MBs of the raid devices
(drive or partition), since the dm stores the RAID superblock
there. Use option -S <size - 100MB, e.g.> of dd_rescue. I don't
know whether SuSe has dd_rescue, but Knoppix does.

Arno

So, I guess there's no way to do this non-destructively, correct?

On 27 Feb 2006 17:37:44 GMT, Arno Wagner <(E-Mail Removed)> wrote:

>Previously Howard Griffin <(E-Mail Removed)> wrote:
>> Is there any way to remove/delete/deactivate RAID metadata (aka
>> "signatures") from my hard drives? A long time ago I had the drives in
>> a RAID set, but quickly reconsidered and decided to use them as
>> independent drives. My disaster-recovery CD (for restoration of a
>> disk image) boots into SuSE Linux (with DMRAID) and insists on seeing
>> the two drives as a RAID set because of the metadata present on them.
>> Thus, the disaster-recovery CD is useless. I want to remove the
>> metadata from these drives so the recovery CD will see them as
>> separate drives. I have gone into the SATA/RAID BIOS for my Silicon
>> Image 3112 controller, but it reports that no RAID sets exist and that
>> there are no conflicts to resolve. Can anyone advise? Would the
>> DMRAID tool allow me to deactivate the metadata? Many thanks.
>
>Complete disk/parition blanking under Linux:
>
> cat /dev/zero > /dev/hd<target> (or /dev/sd<target> for SCSI/SATA)
>
>or with comfortable progress output
>
> dd_rescue -w /dev/zero /dev/hd<target> (see above)
>
>This will remove any data from the drive, including the
>matadata. If this is Linux software RAID, you can speed things
>up by overwtriting only the last MBs of the raid devices
>(drive or partition), since the dm stores the RAID superblock
>there. Use option -S <size - 100MB, e.g.> of dd_rescue. I don't
>know whether SuSe has dd_rescue, but Knoppix does.
>
>Arno

Howard Griffin <(E-Mail Removed)> wrote:

> Is there any way to remove/delete/deactivate RAID metadata (aka
> "signatures") from my hard drives? A long time ago I had the drives
> in a RAID set, but quickly reconsidered and decided to use them as
> independent drives. My disaster-recovery CD (for restoration of a
> disk image) boots into SuSE Linux (with DMRAID) and insists on seeing
> the two drives as a RAID set because of the metadata present on them.
> Thus, the disaster-recovery CD is useless. I want to remove the
> metadata from these drives so the recovery CD will see them as
> separate drives. I have gone into the SATA/RAID BIOS for my Silicon
> Image 3112 controller, but it reports that no RAID sets exist and that
> there are no conflicts to resolve. Can anyone advise? Would the
> DMRAID tool allow me to deactivate the metadata? Many thanks.

You can always wipe the drives with something like clearhdd from
http://www.samsung.com/Products/Hard...s/clearhdd.htm

That writes zeros thru every sector on the drive, so no data survives that.

Previously Howard Griffin <(E-Mail Removed)> wrote:
> So, I guess there's no way to do this non-destructively, correct?

Oh, you want to do it nondestructively. Sotty, missed that.
There is. But you need to calculate the position of the
metadata block right and give the correct offset to dd_rescue.
Better avoid that, since it is likely to go wrong on the first
attempt.

You can mount the disks individually by first breaking
the RAID set. Depending on the version of the RAID tools
you have, ''raidstop'' or ''mdadm'' with some option is
what you are looking for. As soon as the raid is stopped,
you can use an ordinary mount to mount the individual
disks or paritions. The next autodetect will assemble the
RAID though.

Another thing that may prevent autodetection is setting the
partition type back from "fb" (raid autodetect) to "82"
(or was it "83"? Don't remember, but is marks an ordinary
Linux parition). This only prevents auto-start/assembly by
the kernel, not by some additonal scripts your partition
may have.

Arno

Previously Arno Wagner <(E-Mail Removed)> wrote:
> Previously Howard Griffin <(E-Mail Removed)> wrote:
>> So, I guess there's no way to do this non-destructively, correct?

> Oh, you want to do it nondestructively. Sotty, missed that.
> There is. But you need to calculate the position of the
> metadata block right and give the correct offset to dd_rescue.
> Better avoid that, since it is likely to go wrong on the first
> attempt.

> You can mount the disks individually by first breaking
> the RAID set. Depending on the version of the RAID tools
> you have, ''raidstop'' or ''mdadm'' with some option is
> what you are looking for. As soon as the raid is stopped,
> you can use an ordinary mount to mount the individual
> disks or paritions. The next autodetect will assemble the
> RAID though.

> Another thing that may prevent autodetection is setting the
> partition type back from "fb" (raid autodetect) to "82"
> (or was it "83"? Don't remember, but is marks an ordinary
> Linux parition). This only prevents auto-start/assembly by
> the kernel, not by some additonal scripts your partition
> may have.

I just had a look at the madam man-page. It seems deleting
the metadata is as easy as a
"mdadm --zero-superblock <disk/partition>".
Of course you have to stop the RAID array the disk/partition is
part of first. "mdadm --stop /dev/md<device>" should do that.

Sorry for not spotting this first, I am still a novice user
of the new mdadm tool.

Arno

In article <(E-Mail Removed)>, Arno Wagner <(E-Mail Removed)>
writes

>Another thing that may prevent autodetection is setting the
>partition type back from "fb" (raid autodetect)

0xfd, actually.

> to "82"
>(or was it "83"?

83. 82 is Linux swap.

--
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

Previously Mike Tomlinson <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)>, Arno Wagner <(E-Mail Removed)>
> writes

>>Another thing that may prevent autodetection is setting the
>>partition type back from "fb" (raid autodetect)

> 0xfd, actually.

>> to "82"
>>(or was it "83"?

> 83. 82 is Linux swap.

Yes. I allways have to look it up. Fortunately fdisk has the
table build in.

Arno