Bug 473138 - blkid give same UUID for different mirrored partitions with LVM
blkid give same UUID for different mirrored partitions with LVM
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-26 13:35 EST by Josh Cogliati
Modified: 2009-07-30 23:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-30 23:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Josh Cogliati 2008-11-26 13:35:58 EST
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.
Comment 1 Eric Sandeen 2008-11-26 16:05:45 EST
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?
Comment 2 Josh Cogliati 2008-11-26 23:20:34 EST
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.
Comment 3 Eric Sandeen 2008-11-26 23:46:32 EST
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.
Comment 4 Josh Cogliati 2008-12-01 14:32:53 EST
$ 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.
Comment 5 Josh Cogliati 2009-01-23 12:36:59 EST
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.
Comment 6 Bug Zapper 2009-06-09 05:56:27 EDT
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
Comment 7 Eric Sandeen 2009-07-30 17:40:01 EDT
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
Comment 8 Josh Cogliati 2009-07-30 22:26:30 EDT
This seems to work now.  I don't know what fixed it for sure.  Feel free to close it as CURRENTRELEASE
Comment 9 Eric Sandeen 2009-07-30 23:00:27 EDT
Magically fixed by the mount-pixies ;)

Note You need to log in before you can comment on or make changes to this bug.