cloned drive won't boot. (It was a LUKS encrypted drive)

Question

I have an SSD I removed from a system. It had full disk encryption via LUKS (without using LVM).

I want to reuse this drive for a different purpose (in a different system). I cloned (using dd) a non-encrypted Arch Linux system (which is known to be good and does boot) to this previously encrypted drive. However, the cloned drive will not boot.

The dd command I used was:

dd if=/dev/sda of=/dev/sdb bs=1M status=progress

(I got the input and output devices correct too.) The disk I cloned from is back in its original hardware and it booted and runs fine. The new (cloned) disk is in identical hardware.

The newly cloned disk has the same partition structure and the UUID's are the same (as expected). Furthermore, when I mount the new disk and browse through the directories, all files appear to be as expected. The newly cloned disk appears identical upon inspection and it is not obviously corrupted. For example, I can open and read the UEFI loader config files to inspect the UUID numbers. I can also run blkid to verify that the UUID's are correct (they are).

Both systems use UEFI boot. The vfat EFI partition is on the newly cloned drive and it appears to be normal. As stated, the default loader config has the appropriate UUID (because nothing has changed from the drive that was cloned).

The error upon trying to boot from the cloned disk is:

:: running early hook udev
starting version 231
:: running hook [udev]
Waiting 10 seconds for device /dev.. (it lists the partition ID)
ERROR: device [partition UUID] not found. Skipping fsck.
ERROR: unable to find root device [partition UUID]
You are being dropped into a rescue shell

Then Arch drops into a rescue shell.

EDIT:

The cloned drive was connected to the system via USB. When I changed the connection to SATA, the problem went away. The drive works and the system boots as expected.

I expected the cloned drive to work when mounted via USB because this system has already been tested to boot from a btrfs snapshot residing on a USB drive and that works without any issues.

Answer 1

Your system boots up to the point where it tries to find the root filesystem, and fails at that point. This is often a sign that the kernel is missing a necessary driver. As your system, like most non-embedded systems, uses an initramfs, “kernel” here means the set of drivers compiled in the kernel image (/boot/bzImage or wherever it's located) plus the set of drivers that are present on the initramfs. The necessary drivers include everything that's needed to access the filesystem: bus controller, disk controller, disk type, partition, software RAID layer, encryption layer, LVM, filesystem… In your case, evidently the higher layers are present, but if you connected the disk to a different interface (say USB instead of SATA, or a different SATA port on a different controller, etc.) then maybe the driver for that interface is missing. You probably need to regenerate the initramfs.

As it says on the Arch wiki:

Boot succeeds on one machine and fails on another

(…) If you transfer your /boot directory to another machine and the boot sequence fails during early userspace, it may be because the new hardware is not detected due to missing kernel modules. (…) try manually adding modules to the initramfs.