Inconsistent UUIDs between mkconf vs blkid

I'm a bit of a Linux noob, feel free to redirect me elsewhere if this
is an inappropriate post for this list - also, apologies for the many
questions.

I've got a set of arrays that I boot up using Ubuntu (latest MM) and a
couple of Live CD distros for doing maintanence, particularly System
Rescue (gentoo) and Grml (debian), as well as the regular production
server OS, which is rpath-based, pretty close to "stable" (read:
ancient) rhel.

When one of the RAID1 arrays kept dropping all but two of the members,
I re-created it with options "-e=0.90 --auto=md". This was the boot
array for Ubuntu, which failed at boot time due to its UUID changing.
I figured the best thing to do would be to simply set the array's UUID
back to what it was before, so I ran e2fstune to do so, but
unfortunately I got it wrong (UUIDs are so human-unfriendly!), so now
it seems I'm doubly hosed, but I'm taking it on as a learning
experience 8-)

When I ran update-initramfs I got an extended message, apparently from
mdadm, about making sure that my UUIDs were consistent between
mdadm.conf and fstab. Well my fstab is based on filesystem labels (so
much better!), so I thought no worries, but when I ran the suggested
script - /usr/share/mdadm/mkconf, that returned a UUID for the array
that is completely different from that shown by blkid!

So, first the simple questions:

Q1 between mkconf and blkid, which should I trust for the current UUID
of the array (both the filesystem and the underlying component
partitions are the same right?)

Q2 I've noticed that fail/removing a component doesn't always re-set
the UUID, even when --zero-superblock'ing I sometimes need to actually
re-format the partition or use e2fstune to reset the UUID manually,
but other times no problems. Is this a version-specific difference?

Q3 Can I take the UUIDs out of my mdadmconf and just use the
super-minor? I'd really like to use the filesystem label, but that
doesn't seem to be an option.


The more complex question (I realize it's OT for the list so feel free
to ignore)

Q4 Besides the following, are there other places need to be changed
when the UUID changes?

bootloader kernel statements
fstab
mdadm.conf
update-initramfs

grub2 is handling my booting from a dedicated partition where I
manually maintain the grub.conf, so I'm using filesystem labels there
as well, but I'm thinking I'll also have to re-run grub-install and
grub-mkconfig to rebuild the boot-sector images and get a new
intra-partition grub.conf for Ubuntu? I'm chaining from my manually
maintained "uber grub.cfg" into Ubuntu's automatically-maintained
grub.cfg via configfile.

Finally, a big-picture question:

Q5 I've noticed that my arrays aren't quite as as stable as I'd like,
and I'm wondering if that might be due to the different
flavors/versions of mdadm running? The kernels range from 24 to 35,
and while I'm using .0.90.3 metadata for the boot arrays, I've gone
with 1.2 for the big storage RAID6's.


Thanks in advance. . .
--
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

Re: Inconsistent UUIDs between mkconf vs blkid

Sorry, but I just noticed a new wrinkle that may be helpful
(particularly for others googling this later)

mdadm -D reports a UUID that agrees with blkid as opposed to mkconf

However I noticed that the "section delimiters" within the UUID are
colons rather than dashes, and in a few places these colons are in
different places compared to blkid's dashes.

I've tested mdadm --update=uuid and this has (quite logically)
allowed me to just use a number string without any dashes or colons.

I've got a big RAID6 currently rebuilding under sysresccd, so I can't
test with the debian/ubuntu tools ATM, but I'll try to remember to do
so in the 10-12 hours that'll take to finish.
--
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

Re: Inconsistent UUIDs between mkconf vs blkid

Sorry to be talking to myself here, but wanted to close the issue(s)
out. As a practical matter, some combination of everything I've done
(all mentioned in the above post) has caused Ubuntu to resume booting
without the help of Super Grub2 boot disc.

I would still like feedback on this one:

Q5 I've noticed that my arrays aren't quite as as stable as I'd like,
and I'm wondering if that might be due to the different
flavors/versions of mdadm running? The kernels range from 24 to 35,
and while I'm using .0.90.3 metadata for the boot arrays, I've gone
with 1.2 for the big storage RAID6's.

Lessons I've learned (for future googlers):

Since mkconf is a debian/ubuntu-specific tool, I've decided to use
blkid instead from now on instead.

I now check after --zero-superblock'ing a removed member that the
partition's UUID has been re-set (to something other than the
array's).

I'll still use UUIDs in my mdadm.conf, as one of the "unstable" issues
is my .90 RAID1s getting moved to new preferred-minors, e.g. md1 ->
md1_0. I believe this happens when the kernel is still doing
autoassembly too early in the process, before mdadm's had a chance to
kick in - SystemRescueCD bad (ironically the fix is a boot option
called "nomdadm", but in fact the arrays do still auto-assemble, just
properly this time), Grml handles this properly as is.
--
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