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: "iIWnFo-ldxv-AD0B-jR5G-bJaF-C3AV-6N2AoP". 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.
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.
Hmm, this seems to work for me. I followed the exact steps to reproduce this, but no problem occured.
Could you post the *exact* commands that you ran when you hit this problem?
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.
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.
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.
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.