Re: Shouldn't --zero-superblock reset the UUID?

["mirovis" <mirovis@inet.hr>]

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@gmail.com 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html