Almost the entire little thread of concern is half a page: http://marc.info/?l=linux-raid&m=129790712716243&w=2 I'm reconstructing it from web, because wasn't subscribed then (Feb 2011). > hansbkk@xxxxxxxxx wrote: > > I've only seen this problem with RAID1, but perhaps it applies to other levels. > > > > When adding a member partition to an array, the UUID of that partition > > gets set to that of the array (and all the other members) > > > > However, when fail/remove/zero-superblock 'ing a member back out of > > the array, the UUID gets left behind, along with the label and fs > > type. > > > > Ideally the partition would be left in a state as if it never had any > > filesystem at all on it, as when using dd /if=dev/zero and a fresh > > sfdisk. > > > > If this isn't possible, perhaps the zero-superblock option should > > trigger a reminder message to either zero the drive or re-format the > > partition? > > > > > I recall reading on this list that zero-superblock only zero's the first > superblock that it finds. It may be necessary to run mdadm > zero-superblock several times to remove all superblocks that may be on > the device from historical times. > The latest mdadm will zero all superblocks it can find. How I suspec the OP is actually talking about a 'filesystem' uuid rather than a 'raid' uuid... After all it is "along with the label and fs type". So: kansbkk: What makes you think the uuid is left behind? Knowing that will help know what uuid you are talking about. NeilBrown There. In the first place, thank you for giving the world such great program! Here's my woe, however. Pls. bear with me! I am struggling on system update matters ( https://forums.gentoo.org/viewtopic-p-7146038.html#7145606 raid1/rai5 there too ). I made a fine raid1 /dev/md0 from /dev/sdb2 and /dev/sdc2 as boot patition but grub2 and initrd wouldn't properly work on it. So I did (from memory writing): # mdadm -S /dev/md0 # mdadm --zero-superblock /dev/sdb2 # mdadm --zero-superblock /dev/sdc2 Still, after numerous reboots and many tries, those, the raid's uuid and the part uuids are still there, and I can not use /dev/sdb2 or /dev/sdc2 for boot partition because now I am still getting on them, upon grub2-mkconfig (pls find the line in forums.gentoo link above): /usr/sbin/grub2-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image.. or something to that effect. Wait, I just explained it there in a sequence. Now search for more recent ...Couldn't find physical volume `(null)' in the same forums' thread. Too many numerous tries I made on that grub2 on raid1 and than reverted to plain partitions boot issue, to find now the configuration with the original uuids. But, the construction that blkid shows with my other raid devices, say: # blkid -c /dev/null | egrep 'sdb3|sdc3' /dev/sdb3: UUID="bb6ad459-356a-4801-ad1f-7887fea0a4a5" UUID_SUB="aa20fe15-5856-4ee5-8267-8b1d126e00e7" LABEL="at8-g250-c:1" TYPE="linux_raid_member" /dev/sdc3: UUID="bb6ad459-356a-4801-ad1f-7887fea0a4a5" UUID_SUB="041a185c-91f6-49df-7024-d1ea9c7e09e5" LABEL="at8-g250-c:1" TYPE="linux_raid_member" # which is on raid5 /dev/md1 device: # mdadm -D /dev/md1 | egrep 'sdb3|sdc3|UUID' UUID : bb6ad459:356a4801:ad1f7887:fea0a4a5 0 8 19 0 active sync /dev/sdb3 1 8 35 1 active sync /dev/sdc3 In the same fashion: cf771640-1e0f-4ddf-a0cd-10a191d86f75 from blkid in the forums.gentoo is gotten from the not-killable, no way, can't kill that beast!, raid1 /dev/md0 cf771640:1e0f4ddf:a0cd10a1:91d86f75 How do I recover now plain partitions for me. I tried: mdadm --kill-subarray ... but can't quite figure how exactly to use that. I will be grateful for any insight to resolve this issue so I get my plain partitions back from these UUID that seem to be as sticky as Google cookies! No Liberté, no Tails can run away from them! Or maybe... How do I kill these UUIDs? In general terms. Because I sure want to be able to remake my boot raid1, or even raid5 partition when Grub2 learns to treat them! Thanks again in advance! Miroslav Rovis Pls. allow me to possible add a correction mail if I wrongly or unclearly worded or mispasted some data. I am quite exhausted with this work on my hands. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html