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