Ubuntu drops to emergency mode after cloning LUKS-root to a new SSD — cryptsetup mapping not found

Environment

Desktop: Ubuntu 22.04 LTS, original boot drive (NVMe) cloned bit-for-bit to a second NVMe using dd; both NVMe present in system and boot order set to new NVMe; system uses LUKS-encrypted root with a separate /home LVM logical volume.

Symptoms

After moving the cloned drive into the machine and selecting the new NVMe in BIOS, boot process stops and systemd drops to emergency mode showing 'cryptsetup: couldn't find key for ...' and 'mount: mounting / on /dev/mapper/ubuntu--vg-root failed'.

Observations

From emergency shell: 'blkid' shows different UUIDs for the partitions compared to entries in /etc/crypttab and /etc/fstab. /etc/crypttab inside root filesystem (on the cloned drive) refers to original device UUIDs from the source disk. Running 'ls /dev/disk/by-uuid' shows the new NVMe partitions have new UUIDs (expected after cloning to a different device). update-initramfs was not run after cloning. cryptsetup luksOpen fails with 'No such device' for UUID listed in crypttab.

Already attempted

Attempted to edit /etc/crypttab and /etc/fstab from emergency shell to match new UUIDs, then run 'mount -a' — cannot because initramfs still expects original mapping. Booted from live USB, chrooted into cloned root, edited crypttab/fstab to match blkid output, ran 'update-initramfs -u' and 'grub-install' to the new NVMe. Rebooted — still drops into emergency mode with same cryptsetup error.

Question

After cloning an encrypted LUKS root to a different NVMe and updating crypttab/fstab, why does the system still fail to unlock the LUKS mapping during early initramfs, and which steps will reliably rebuild initramfs/boot so the cloned disk boots without requiring repair-mode intervention for each boot?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Bootloader (GRUB/EFI) entry still points to the old/incorrect initramfs or kernel on a different disk/ESP. 90%

Initramfs image on the cloned disk still contains old device UUIDs and was not regenerated for the new device mapping. 60%

Cryptsetup/LVM hooks omitted from the regenerated initramfs (e.g., missing 'cryptsetup' or 'lvm2' initramfs hooks), so early userspace cannot discover or open encrypted volumes. 20%

Summary

The failure is occurring during early boot before the updated root filesystem's /etc/crypttab is read; that indicates the initramfs embedded on the target disk still contains references to the original devices/UUIDs or lacks the cryptsetup/udev hooks reflecting the new device layout. Common issues after cloning: stale initramfs with old UUIDs, missing cryptsetup or LVM hooks in initramfs, or /boot/grub pointing to the wrong initramfs image. Chrooting and regenerating initramfs should help, but if steps were applied to the wrong disk, or the system boots a different EFI entry that still references the old initramfs, boot will continue to fail.

Suggested Fixes

Diagnostic step 1

Boot from a live USB, mount the cloned root and bind /dev /proc /sys, chroot into it and confirm /etc/crypttab and /etc/fstab use the correct UUIDs from 'blkid'.

Diagnostic step 2

Inside the chroot, ensure 'cryptsetup' and 'lvm2' packages are installed, then run 'update-initramfs -c -k all' (or '-u') to create fresh initramfs images that include the correct hooks.

Diagnostic step 3

Reinstall GRUB to the target disk's EFI partition (e.g., 'grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu') and update-grub to ensure EFI entries reference the regenerated initramfs.