Description of problem: I have a mirrored logical volume. (Created with a lvcreate -m 1 ... command) However, the mirrored partitions and the created partition have the same uuid: $ /sbin/blkid /dev/mapper/VolGroup00-lvol0_mimage_1: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0_mimage_0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" TYPE="ext3" LABEL="mirrored" SEC_TYPE="ext2" This causes problems if you try and mount the lvol0 partition with using a UUID to specify it, since mount can pick up on the lvol0_mimage_1 partition instead of the correct lvol0 partition. Version-Release number of selected component (if applicable): e2fsprogs-1.41.3-2.fc10.x86_64 How reproducible: Every time I run blkid I get the same uuid's. I have not tried to create another mirrored logical volume to see if I get the same thing. Steps to Reproduce: 1. create a mirrored logical volume lvcreate -m 1 ... 2. run blkid 3. Check if the UUID's are different. Actual results: $ /sbin/blkid /dev/mapper/VolGroup00-lvol0_mimage_1: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0_mimage_0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" TYPE="ext3" LABEL="mirrored" SEC_TYPE="ext2" Expected results: Three different UUID's. Practically by definition, I would expect that blkid should not report the same universal unique id for multiple partitions. Additional info: Also reported as Bug 473136 since the release notes say you don't need labels, but until this bug is fixed, you do for mirrored drives.
A mirror, by definition (modulo some implementation), presents an exact copy of its components... I do not think that this is specific to e2fsprogs or to lvm; see for example my md mirror with xfs on it: # blkid | grep 662cf0ef-7619-4acb-aefd-90ef9d7664bb /dev/sda3: UUID="662cf0ef-7619-4acb-aefd-90ef9d7664bb" TYPE="xfs" /dev/sdb3: UUID="662cf0ef-7619-4acb-aefd-90ef9d7664bb" TYPE="xfs" /dev/md1: UUID="662cf0ef-7619-4acb-aefd-90ef9d7664bb" TYPE="xfs" I see that your example above shows the label only on the mirror, which surprises me a little, but I would be more surprised if that persists across a reboot, does it?
I'll have to get back to you on what happens to the label when I next reboot (Monday). Basically, when I rebooted the computer after installing Fedora 10, anaconda had 'helpfully' changed the line in fstab that had been: /dev/mapper/VolGroup00-lvol0 ... to UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" ... and then mount decided to try and mount /dev/mapper/VolGroup00-lvol0_mimage_1 which in LVM is an error by default (it can be ignored if you want to recover the mirror, but this is not the default) so the end result was that the first time I booted after upgrading was mounting failed and I got to figure out what happened in single user mode. I think there is a bug either in mount, blkid, or anaconda, and it seemed most logical to me that it was blkid's problem since it had multiple UUID's that were not unique. I can also believe that this is an mount problem, since in the face of multiple non-unique UUID's it should pick up the /dev/mapper/VolGroup00-lvol0 instead of /dev/mapper/VolGroup00-lvol0_mimage_1 I can also believe that this is an anaconda problem for not properly handling the case of multiple non-unique UUID's. If there is good reason for blkid's current behaviour, then I can filed a different bug for one of those other programs.
What do you get when you do # blkid -l -t UUID=c9bee71a-ebda-4357-a509-cd92e4a60697 ? On my box w/ a mirror and therefore duplicate UUIDS: # blkid | grep 05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3 /dev/sda1: LABEL="boot2" UUID="05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3" SEC_TYPE="ext2" TYPE="ext3" /dev/sdb1: LABEL="boot2" UUID="05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3" SEC_TYPE="ext2" TYPE="ext3" /dev/md0: LABEL="boot2" UUID="05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3" SEC_TYPE="ext2" TYPE="ext3" I get: # blkid -l -t UUID=05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3 /dev/md0: LABEL="boot2" UUID="05d9ddd9-dc75-4e7b-9bfd-2b27d06e36b3" SEC_TYPE="ext2" TYPE="ext3" and -l is supposed to handle a hierarchy: -l Look up one device that matches the search parameter specified using the -t option. If there are multiple devices that match the specified search parameter, then the device with the highest priority is returned, and/or the first device found at a given priority. Device types in order of decreasing priority are Device Mapper, EVMS, LVM, MD, and finally regular block devices. If this option is not specified, blkid will print all of the devices that match the search parameter. so as long as mount is invoking it this same way, it should work. If it's not, we'll need to look into why.
$ blkid -l -t UUID=c9bee71a-ebda-4357-a509-cd92e4a60697 /dev/mapper/VolGroup00-lvol0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" TYPE="ext3" LABEL="mirrored" SEC_TYPE="ext2" $ blkid -t UUID=c9bee71a-ebda-4357-a509-cd92e4a60697 /dev/mapper/VolGroup00-lvol0_mimage_1: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0_mimage_0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" SEC_TYPE="ext2" TYPE="ext3" /dev/mapper/VolGroup00-lvol0: UUID="c9bee71a-ebda-4357-a509-cd92e4a60697" TYPE="ext3" LABEL="mirrored" SEC_TYPE="ext2" So it looks like blkid is giving the correct partition with the -l parameter. As well, the label persists across a reboot (since the above is after a reboot). I changed by fstab back to the version created by anaconda, and now mount seems to be working. Both mount /mirrored and mount UUID=c9bee71a-ebda-4357-a509-cd92e4a60697 /mirrored Do not give any errors and /mirrored is mounted. I did install the util-linux update, but the changelog does not mention any mount fixes: https://www.redhat.com/archives/fedora-package-announce/2008-November/msg00776.html I'll leave the fstab with the UUID and see if it continues to work.
Well, I have been using the UUID in my fstab, and I have not seen the bug again where mount uses the wrong partition. There was a mount update after F10 was released, so maybe that fixed the problem.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Josh, this all seems to be ok now? I guess I'd like to know what fixed it for sure, but as long as it all seems good now I'm tempted to close it as CURRENTRELEASE. Thanks, -Eric
This seems to work now. I don't know what fixed it for sure. Feel free to close it as CURRENTRELEASE
Magically fixed by the mount-pixies ;)