Bug 460231 - LVM obtaining duplicate UUIDs, left over test code?
LVM obtaining duplicate UUIDs, left over test code?
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
medium Severity high
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2008-08-26 17:26 EDT by starlight
Modified: 2010-01-11 22:54 EST (History)
9 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description starlight 2008-08-26 17:26:45 EDT
Description of problem:

LVM starts reusing the same UUID.  Looks like
test code that was left in by accident.

Version-Release number of selected component (if applicable):

kernel 2.6.18-92.1.10.el5
lvm2 2.02.32

How reproducible:

Create two VGs 'vg00' and 'vg01' on four disks, each
with four partitions such that each VG has one
PV/partition on each physical disk.  'vg01' has four
900GB partitions and 'vg00' has four 15GB partitions.

# fdisk -l /dev/sda  # same for 'sdb' 'sdc' 'sdd'
Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        1838    14659312+  8e  Linux LVM   # vg00
/dev/sda3            1839        5488    29318625    7  HPFS/NTFS
/dev/sda4            5489       30401   200113672+  8e  Linux LVM   # vg01

Allocate one LV per disk in 'vg01'.  Named them
'lv10' 'lv11' 'lv12' 'lv13'.  These become
four 'ext2' file systems though probably no need
to actually 'mkfs' and mount them.

Start with one LV on first disk in 'vg00' named
'lv00'.  Added three other drive PVs last and used
'vgextend' to add them to 'vg00'.  This is where
the trouble begins.

When adding the third of four PVs to 'lv00', the UUIDs
starting coming out the same value causing havoc:

Finally got the PVs added by specifying --uuid
parameter with values generated with '/usr/bin/uuidgen'

Then tried to run

   lvconvert -m1 vg00/lv00 /dev/sda2 /dev/sdb2 /dev/sdc2

Actual results:

The same stupid UUID came up every time:

# lvconvert -m1 vg00/lv00 /dev/sda2 /dev/sdb2 /dev/sdc2                         
  Internal error: Duplicate LV id iIWnFo-ldxv-AD0B-jR5G-bJaF-C3AV-6N2AoP detected for lv00_mimage_0 and lv00_mlog in vg00.
  Internal error: Duplicate LV id iIWnFo-ldxv-AD0B-jR5G-bJaF-C3AV-6N2AoP detected for lv00_mimage_1 and lv00_mlog in vg00.
  Internal error: Duplicate LV id iIWnFo-ldxv-AD0B-jR5G-bJaF-C3AV-6N2AoP detected for lv00_mimage_1 and lv00_mimage_0 in vg00.

Expected results:

It should work!

Additional info:

This looks like a developer accidently left in some test
code for stressing some corner-case error handling.  The good
news is it doesn't wreck the system so I supposed he succeeded.

The bad news is I can't create the mirror.
Comment 1 starlight 2008-08-31 12:38:16 EDT
Worked around this by exporting 'vg01' and temporarily
deleting the 'fdisk' partitions.  Strange UUID behavior
went away with smaller number of LMV objects present.
Then restored 'vg01' after the mirrors were created.
Comment 2 Peter Rajnoha 2008-12-12 10:47:19 EST
Hmm, this seems to work for me. I followed the exact steps to reproduce this, but no problem occured.
Comment 4 Bryn M. Reeves 2008-12-12 11:00:59 EST
Could you post the *exact* commands that you ran when you hit this problem?
Comment 5 starlight 2008-12-12 12:23:54 EST
You're joking, right?  The exact sequence of commands
for the build of a system from four months ago?  The
issue might for all I know be dependent on some highly
specific aspect of the hardware and the command sequence
would not help.

However I stumbled into it, I was getting duplicate
UUIDs consistently over a multi-day period.  That
should be impossible, so it seems to me that some
bit of code does it intentionally.

So instead of trying to reproduce the problem, recommend
you look for some residual test code that generates
duplicate UUIDs under some unusual circumstance.
Comment 6 Milan Broz 2008-12-12 12:51:41 EST
There is no residual test code left for uuid generation code. And it uses /dev/urandom for random sequence.
It can be of course consequence of bug elsewhere in the code but without exact steps how it happened we are not able to say what was wrong.
Comment 7 starlight 2008-12-12 13:47:13 EST
Then probably this bug get to live on.

I built a second server with exactly the same
layout a month after the first and did not hit
the problem.  So whatever it is is not simple
to reproduce.
Comment 8 Dave Wysochanski 2009-03-16 07:23:35 EDT
We've made attempts to reproduce and inspected the code but have no way to reproduce.  Closing in the absence of information needed to make forward progress.

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