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

7

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
  • 3
    Don't forget to stop first the array before zeroing the disk. mdadm --stop /dev/md127 Dec 18, 2017 at 4:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .