2

I have Ubuntu 16.04 host with 3 Ubuntu 17.10 guests in KVM (Virtual Machine Manager 1.3.2).

I export several block devices from 2 guests to the other guest (let's call it frontend) via iSCSI portal created by targetcli util. Having imported them, I heavily use multipath to find same "physical" disks and md to create RAID 10 (say, mdadm --create --quiet --metadata=1.2 /dev/md1 --level=1 --raid-devices=2 /dev/dm-10 /dev/dm-1). Then I need to wipe this information out.

Here comes the problem: it does not wipe. I go through usual steps (say, to clean md1):

1) mdadm -S /dev/md1

2) mdadm --zero-superblock /dev/md1

3) mdadm --zero-superblock /dev/mapper/md1

Everything seems fine until I remove imported disks and re-import them some time later: they stochastically appear grouped in RAID. Sometimes RAID group names are far from originally created (e.g. md126 and md127, while I only created md1, md2, ... md12). These zombie RAIDs can be buried with mdadm -S, but they appear again the next time block devices are imported.

Why does --zero-superblock fail to do its work?

UPD: As @roaima mentioned, commands 2 and 3 and alike really return errors:

Couldn't open /dev/md1 for write - not zeroing

Couldn't open /dev/mapper for write - not zeroing

Couldn't open /dev/mapper/ for write - not zeroing

That is pretty much the same answer as if there are no such devices - any rubbish as argument will return the same error.

UPD2: I used # cat /proc/mdstat, which told me more about raids:

md124 : inactive vdg[0](S)
      5238784 blocks super 1.2

md127 : inactive vdb[1](S)
      5238784 blocks super 1.2

However, I still can not wipe neither /dev/vdg (Couldn't open /dev/vdg for write - not zeroing) nor /dev/md124 (Unrecognised md component device - /dev/md124).

3
  • Some other problem (namely, mdadm.conf problem) seems to be able to create md-126 and other big md numbers. However, it all comes from rusty meta information left from md.
    – ikudyk
    Dec 16, 2017 at 7:30
  • 1
    Your step 2 should have reported an error about there being no metadata. Did it? If so, please add it to your question - error messages are really really important.
    – roaima
    Dec 16, 2017 at 10:15
  • @roaima, added error on metadata deletion. I should've added it earlier, but my script didn't print all the output.
    – ikudyk
    Dec 18, 2017 at 4:31

1 Answer 1

6

It fails, because the following command:

mdadm --zero-superblock device

Takes the device argument as the disk(s), not the array.

So, for example this is valid and working for sda drive:

mdadm --zero-superblock /dev/sda

or

mdadm --zero-superblock /dev/sda1

depending on how you have set up the RAID.

As usual, don't forget to update your initramfs:

update-initramfs -u
8
  • Well, changing /dev/mdX with /dev/vdX didn't work too well <br/> # mdadm --zero-superblock /dev/vdb <br/> mdadm: Couldn't open /dev/vdb for write - not zeroing <br/> It reacts as if there is no device /dev/vdb for mdadm - any rubbish will return the same error. However, this device is real and is seen by lsblk and alike.
    – ikudyk
    Dec 18, 2017 at 4:32
  • try /dev/vdX1 Dec 18, 2017 at 4:42
  • 1
    however, I believe you should first look what member in the array are with cat /proc/mdstat Dec 18, 2017 at 4:43
  • What a handy command you gave me: # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md124 : inactive vdg[0](S) 5238784 blocks super 1.2 md127 : inactive vdb[1](S) 5238784 blocks super 1.2 unused devices: <none> However, I still can not wipe /dev/vdb. Furthermore, mdadm --zero-superblock /dev/md127 returns new error: # mdadm: Unrecognised md component device - /dev/md127
    – ikudyk
    Dec 18, 2017 at 4:50
  • 2
    Don't forget to stop first the array before zeroing the disk. mdadm --stop /dev/md127 Dec 18, 2017 at 4:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.