#!/bin/bash
set -xeu
parted --version
rm -f image.img
truncate -s 1G image.img
n=$(uuidgen | cut -d- -f1)
dev="$(losetup -Pf --show image.img)"
mdadm --create --metadata 0.90 --force --level 1 -n 1 --assume-clean /dev/md/$n $dev
mdadm --stop /dev/md/$n
losetup -d $dev
parted --script --align optimal image.img -- mklabel msdos
wipefs image.img
and here's the output on my system:
+ parted --version
parted (GNU parted) 3.2
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by <
http://git.debian.org/?p=parted/parted.git;a=blob_plain;f=AUTHORS>.
+ rm -f image.img
+ truncate -s 1G image.img
++ uuidgen
++ cut -d- -f1
+ n=e0c43267
++ losetup -Pf --show image.img
+ dev=/dev/loop44
+ mdadm --create --metadata 0.90 --force --level 1 -n 1 --assume-clean /dev/md/e0c43267 /dev/loop44
mdadm: array /dev/md/e0c43267 started.
+ mdadm --stop /dev/md/e0c43267
mdadm: stopped /dev/md/e0c43267
+ losetup -d /dev/loop44
+ parted --script --align optimal image.img -- mklabel msdos
+ wipefs image.img
DEVICE OFFSET TYPE UUID LABEL
image.img 0x3fff0000 linux_raid_member 6dbbfe69-809c-7a77-14d5-894fb9296617
image.img 0x1fe dos
Looking at ped_disk_clobber none of this is surprising: the 0.90 metadata is somewhere between 127 and 64 kiB from the end of the device and this isn't touched.
If this is indeed deemed a bug it could be pragmatically fixed by wiping more from the end of the disk or more cleverly by using libblkid to locate and zap all superblocks.
Cheers,
mwh