[aklug] Re: UUIDs

Lee wrote:
>> Can you elaborate on this? While I don't use UUIDs for mounting purposes, mdadm
>> uses them by default for RAID members, and I've never had a problem.
>> Of course, all my filesystems are LVs, so all the RAIDs are just PVs, so that may be
>> where our configs differ.
>
> Apologies ahead of time. This is rather disorganized.
>
> from Shane Spencer:
>
>> So assigning a raid volumes UUID to a mount in /etc/fstab and so forth won't do
>> a lick of good.
>
> hm, that's exactly what I tried to do. Because that seemed to be what the googles and
> whatnot indicated. And that's what it looked like the ubuntu-alternate install I
> tried on a virtualbox using raid10 did. But admittedly I did not keep rigorous
> notes, so can't the backtrack the vbox work exactly.
>
> Anyway, here's the /etc/fstab:
>
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point> <type> <options> <dump> <pass>
> proc /proc proc defaults 0 0
>
> # /dev/mapper/michelle-root
> UUID=24348468-38df-4a1f-83a8-6d01e3781906 / ext3
> relatime,errors=remount-ro 0 1
>
> # /dev/sda5
> UUID=746b6aae-0e2e-4aa5-9eec-a2c610ddc92e /boot ext3 relatime
> 0 2
>
> # /dev/mapper/michelle-swap_1
> UUID=9e1c17fc-3e21-4e96-b589-87ab276df97f none swap sw
> 0 0
>
> ## added to include raid5 /home. Used /dev/md13 because it didn't mount on boot using
> the UUID.
> /dev/md13 /home ext3 relatime 0 2
> #UUID=453a5046:3bdcf374:791e86ce:5f3c851e /home ext3
> relatime,errors=remount-ro 0 2
>
> /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
> /dev/scd1 /media/cdrom1 udf,iso9660 user,noauto,exec,utf8 0 0
>
> --------------------------------
>
> /etc/mdadm/mdadm.conf:
>
>
> # mdadm.conf
> #
> # Please refer to mdadm.conf(5) for information about this file.
> #
>
> # by default, scan all partitions (/proc/partitions) for MD superblocks.
> # alternatively, specify devices to scan, using wildcards if desired.
> DEVICE partitions
>
> # auto-create devices with Debian standard permissions
> CREATE owner=root group=disk mode=0660 auto=yes
>
> # automatically tag new arrays as belonging to the local system
> HOMEHOST <system>
>
> # instruct the monitoring daemon where to send mail alerts
> MAILADDR root
>
> # definitions of existing MD arrays
>
> # This file was auto-generated on Mon, 16 Mar 2009 18:41:53 -0800
> # by mkconf $Id$
> ARRAY /dev/md13 level=raid5 num-devices=3 UUID=453a5046:3bdcf374:791e86ce:5f3c851e
>
> ---------------------------------------
>
> so the UUID's are the same. But if what Shane says is correct, that's irrelevant.
> Also, I have in my notes that one or the other of the three 'component' UUIDs of the
> physical drives kept popping up as the raid array UUID at some point during boot, but
> of course I didn't write down where or how, since it always 'settled' to the same
> UUID, which I put in the /etc/fstab.
>
> Now, two things come to mind:
>
> 1. I don't think I made the md13 into a PV, but do I need to? I thought the answer
> was no; now I think it's 'probably'. But how is that preserved between boots?
>
> 2. Does the raid5 need to be mapped into the /dev/mapper mess some sort of way? I've
> been able to avoid dev-mapper foibles so far, but maybe it's time. I'm needing
> another excuse to put off finishing the drywall in the house....
>
> On the other hand the box works now, it's just not done 'right'. On the third hand,
> it looks like UUID's are the way of the future so may be worthwhile to go ahead and
> bite the bullet and learn to work with them.
>
You assigned the raid devices UUID (not the filesystem). Run blkid once
and it should tell you the filesystem type on top of your raid device as
well as the filesystems UUID.

Shane

-- Attached file included as plaintext by Ecartis --
-- File: signature.asc
-- Desc: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknbno8ACgkQXK/vGhypreJucACgspq2bKY47HbBVtudDQ8cs0Rk
C+wAoICTWDN4ZMFYDCLlPBs9yPcNIt/n
=1kaZ
-----END PGP SIGNATURE-----

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Apr 7 10:42:12 2009