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

ikudyk
  • 83
  • 1
  • 1
  • 9
  • [Some other problem](https://unix.stackexchange.com/a/64977/265994) (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 '17 at 07: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 '17 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 '17 at 04:31

1 Answers1

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
Vlastimil Burián
  • 27,586
  • 56
  • 179
  • 309
  • Well, changing `/dev/mdX` with `/dev/vdX` didn't work too well
    `# mdadm --zero-superblock /dev/vdb`
    `mdadm: Couldn't open /dev/vdb for write - not zeroing`
    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 '17 at 04:32
  • try `/dev/vdX1` – Vlastimil Burián Dec 18 '17 at 04:42
  • 1
    however, I believe you should first look what member in the array are with `cat /proc/mdstat` – Vlastimil Burián Dec 18 '17 at 04: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: ` 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 '17 at 04:50
  • I still don't get how to make newlines in comments, so I will mirror answer in the question bode. – ikudyk Dec 18 '17 at 04:51
  • I will be for a short time in hospital since today, so I hope I helped a little. Cheers. – Vlastimil Burián Dec 18 '17 at 04:54
  • /dev/vdX1 alternative didn't help. But thank you a lot for your effort, `update-initramfs -u` and `cat /proc/mdstat` did a great job. – ikudyk Dec 18 '17 at 04:57
  • 3
    Don't forget to stop first the array before zeroing the disk. `mdadm --stop /dev/md127` – Vlastimil Burián Dec 18 '17 at 04:58