When working with LVM (Logical Volume Manager) in Linux, having multiple volumes with identical UUIDs can create conflicts. This commonly occurs when:

• Cloning disks using dd or similar tools
• Creating backup drives meant to be exact replicas
• Testing disaster recovery scenarios

The fundamental issue arises because LVM uses UUIDs to uniquely identify:

Physical Volumes (PVs)
Volume Groups (VGs)
Logical Volumes (LVs)

When you attempt to mount a cloned volume while the original is active, you'll encounter errors like:

Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0

Here's a step-by-step approach to work around this limitation:

# First, rename the original VG to avoid conflicts
vgrename original_vg original_vg_live

# Scan for the new VG configuration
vgscan --mknodes

# Activate the backup VG (this will be detected with original name)
vgchange -ay

The issue with missing /dev/test/ directory occurs because:

• Device nodes aren't automatically created for renamed VGs
• The udev system needs to be triggered to create them

Solution:

# Force udev to update device nodes
udevadm trigger

# Alternatively, create the directory manually
mkdir -p /dev/test
mknod /dev/test/root b 252 1
mknod /dev/test/swap_1 b 252 2

For a more permanent solution, consider changing UUIDs on the backup:

# Change PV UUID
pvchange --uuid /dev/sdX

# Change VG UUID
vgchange --uuid original_vg

# Then you can safely import both volumes
vgimportclone /dev/sdX

When working with duplicate LVM volumes:

• Never activate both the original and clone simultaneously in production
• Test all procedures in a non-critical environment first
• Document which UUIDs belong to which physical devices
• Consider using vgimportclone for safer cloning operations

Here's a complete example of mounting a cloned LVM volume:

# Rename the live VG
vgrename main_vg main_vg_live

# Rescan volumes
vgscan --mknodes

# Activate the backup VG
vgchange -ay backup_vg

# Update device nodes
udevadm trigger --action=add

# Verify LV availability
lvdisplay /dev/backup_vg/root

# Mount the backup root
mkdir /mnt/backup_root
mount /dev/backup_vg/root /mnt/backup_root

When dealing with cloned LVM volumes (created via dd or similar block-level copy methods), you'll encounter UUID conflicts that prevent simultaneous access. The fundamental issue stems from:

• Identical Physical Volume (PV) UUIDs across devices
• Duplicate Volume Group (VG) names
• Matching Logical Volume (LV) identifiers

Here's the complete procedure to access your backup while maintaining the original system's LVM structure:

# First rename the LIVE system's VG (temporarily)
vgrename original_vg original_vg-live

# Scan for the backup device's VG
vgscan --mknodes

# Activate the backup VG with a temporary name
vgimportclone --basevgname backup_vg /dev/sdX

Let's walk through a real-world scenario where /dev/sda contains the live system and /dev/sdb is the backup:

# Identify the live VG
vgs
# Output shows VG named "system_vg"

# Rename the live VG
vgrename system_vg system_vg-live

# Import the backup with modified identifiers
vgimportclone -n backup_vg /dev/sdb2

# Verify both VGs are now visible
vgs
# Should show both "system_vg-live" and "backup_vg"

For long-term solutions, consider regenerating UUIDs on backup media:

# WARNING: Destructive operation - for backup media only
pvchange -u /dev/sdb2
vgrename /dev/system_vg /dev/backup_vg

Remember that filesystems within LVs also have UUIDs. After mounting duplicate volumes, you may need to:

• Use mount -o nouuid for XFS
• Update /etc/fstab with temporary mount points
• Handle potential filesystem journal inconsistencies