Linux · critical · Storage, filesystems & NFS

A cloned machine will not boot — device names and UUIDs have changed

fstab or the boot configuration references a device that no longer has that name or identifier on this machine.

What you see

The clone drops to emergency mode, or waits 90 seconds per missing device before giving up. Common after cloning, moving a disk, or adding storage.

What is actually wrong

Device names like /dev/sdb are assigned in detection order and change. A clone also duplicates filesystem UUIDs, so two filesystems claim the same identity.

Codes and articles

dependency failed for /mntTimed out waiting for deviceemergency modeblkidPARTUUID

Fixes (2)

Reference filesystems by UUID rather than device name

Emergency shell or rescue media30 minutesmedium riskreversible

A device name has changed.

At the emergency prompt, sign in as root and remount the root filesystem writable.
Shell
```
mount -o remount,rw /
```

List every filesystem with its UUID.

Shell

blkidlsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINT

Replace device names in fstab with UUIDs.
Shell
```
cp /etc/fstab /etc/fstab.bakblkid -s UUID -o value /dev/sdb1
```
A UUID follows the filesystem wherever it is attached. Device names follow detection order, which changes when a disk is added, a controller is changed, or a machine is virtualised.
Add nofail to any non-essential mount so a missing device does not stop the boot.
Shell
```
sed -i 's|\(/mnt/data.*defaults\)|\1,nofail,x-systemd.device-timeout=10|' /etc/fstab
```
Without nofail, systemd waits the full device timeout and then drops to emergency mode because a data volume is absent. That turns a missing backup disk into a machine that will not boot.

Validate before rebooting.

Shell

systemctl daemon-reloadmount -afindmnt --verify

Confirm it workedmount -a completes silently and the machine boots unattended.

Shell

findmnt --verify; systemctl --failed

If you need to undo itRestore /etc/fstab.bak.

Give the clone new identifiers

Rescue media, filesystems unmounted40 minuteshigh riskreversible

A cloned disk shares UUIDs with the original and both are attached.

Boot from rescue media with only the clone attached where possible.
Find the duplicates.
Shell
```
sudo blkid | sort -t= -k2
```

Change the filesystem UUID. The command differs by filesystem type.

Shell

sudo tune2fs -U random /dev/sdb1          # ext4sudo xfs_admin -U generate /dev/sdb1      # xfssudo swaplabel -U $(uuidgen) /dev/sdb2    # swap

Rename the LVM volume group if LVM is in use — two groups with the same name is worse than duplicate UUIDs.
Shell
```
sudo vgdisplay | grep -E 'VG Name|VG UUID'sudo vgrename OldVGUUID newvg0
```
With two identically named volume groups visible, LVM activates one of them and there is no way to predict which. This makes a clone boot from the original's disk without any error to indicate it.

Update fstab and the boot configuration with the new UUIDs.

Shell

sudo blkidsudo nano /etc/fstabsudo update-grub || sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Rebuild the initramfs so the root UUID it embeds is correct.
Shell
```
sudo update-initramfs -u -k all || sudo dracut -f --regenerate-all
```

Confirm it workedBoth machines boot with the original and the clone attached, each using its own filesystems.

Shell

blkid; findmnt /

If you need to undo itUUIDs can be set back explicitly with tune2fs -U <uuid> if the originals were recorded.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.