On Wed, September 26, 2007 9:27 pm, Erik de Castro Lopo wrote:
> Hi all,
>
> I've got something thats been bugging me for a while. I have an Ubuntu
> Fiesty box which has this in /etc/mdamd/mdadm.conf:
>
> ARRAY /dev/md0 level=raid1 num-devices=2
> UUID=7cff1ce4:b67054ef:e558e8bc:3d496b47
>
> and this in /etc/fstab:
>
> # /dev/md0
> UUID=2956c339-fa5e-45d9-ab13-e92a9597ab20 /home ext3 defaults 0 2
>
> The UUIDs don't match, but the device still mounts on bootup as expected.
>
> Questions:
>
> - Should the UUIDs match and if so, which one is wrong?
> - How do I fix it?
> - How the hell is it workin now?
Q1, Q2, Q3
A1)
A quirk of raid1 mirror's on Linux software raid is you can usually mount
one of the components for recovery. IE they're pretty much exactly the
same. EG if /dev/md0 is made up from /dev/hda1 and /dev/hdc1 and you
booted from a CD that doesen't do RAID you could do "mount -o ro /dev/hda1
/mnt/recovery". This can also happen with some hardware raid cards if you
pop the drive onto a non-raid controller. It's much more interesting for
other raid types.
So much so that if you have Logical Volumes on a raid1 and zero out the
raid blocks then LVM goes to hell because it now finds two duplicate
volumes. Further fun happens when you plug in another hard disk from
another system which has the same Volume Group but you can play with that
another day - at least it lets you know and choses only one to run at a
time.
Anyway.. I digress. Yeah for software raid1 the uuid for the array, and
each of it's components will be the same.
A2)
To change it... you'd better boot off a rescue CD and learn/practise using
the mdadm utility. I'd suggest something like...
mdadm --assemble -U --uuid=956c339-fa5e-45d9-ab13-e92a9597ab20 \
/dev/md0 /dev/hda1 /dev/hdc1
Or as the case may be editing the /etc/mdadm.conf (/etc/raidtab on really
old systems) and/or /etc/fstab
A3) <smile> think how the kernel starts up and runs from the initial
ramdisk. The answer lies within... because frankly all the stuff on your
regular filesystem, eg /etc/fstab and /etc/mdadm.conf can't be read until
the kernel can find the filesystem. So you will find that whatever
created your /boot/initrd* file did so by thinking about what sort of
filesystem it would need to find.
On Fedora for example the initrd is a gzip'd cpio'd filesystem in which
you'll find /etc/init which happens to be a nash script (red hat's
cut-down bash). In there you'll find magic stuff like insmod scsi, insmod
raid1, raidstart /dev/md0, mount /dev/md0 /rootfs, switchroot
Of course once the initial ramdisk mounts the root filesystem proper it
then may go run something like /bin/init which finds it's way to
/etc/rc.d/rc.sysinit (fedora/Redhat/Centos) which as part of it's process
THEN looks at /etc/fstab and here's the funny bit... it tries to mount all
the filesystems mentioned (with the auto attribute) but only if not
mounted already.. now the root filesystem IS mounted already so again the
/etc/fstab entry for the root filesystem is not used.
--
---<GRiP>---
Electronic Hobbyist, Former Arcadia BBS nut, Occasional nudist, Linux
Guru, SLUG President, AUUG and Linux Australia member, Sydney
Flashmobber, Tenpin Bowler, BMX rider, Walker, Raver & rave music lover,
Big kid that refuses to grow up. I'd make a good family pet, take me home
today!
Some people actually read these things it seems.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
