Fixing the “root=UUID not found” error after cloning an SSD with Clonezilla

 Posted on 11 October 2026  |  3 minutes  |  534 words  |  Tom

When Clonezilla says root=UUID not found

Cloning a bootable SSD with Clonezilla is usually painless, but the new machine can stall at the kernel prompt with:

root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx not found

The kernel can’t locate the root filesystem because the UUIDs in the boot configuration still point to the original disk. The fix is a handful of targeted edits and rebuilds.

1. Verify the new UUIDs

Boot from a live USB, open a terminal and list the block devices:

sudo blkid

or

lsblk -o NAME,FSTYPE,UUID,MOUNTPOINT

Note the UUID for the partition that contains your root filesystem (usually /dev/sda1 or /dev/nvme0n1p1). If you’re using LUKS, the UUID shown by blkid is for the encrypted container; the underlying filesystem UUID is inside the container.

2. Update /etc/fstab

Mount the new root partition if it isn’t already:

sudo mount /dev/sda1 /mnt

Edit the fstab file:

sudo nano /mnt/etc/fstab

Replace the old UUID with the new one:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults 0 1

If you’re using LVM or encrypted LUKS, make sure the entry matches the correct device path or UUID.

3. Re‑generate the initramfs

The initramfs contains the modules and scripts that mount the root filesystem during boot. Rebuild it with the updated UUID:

sudo chroot /mnt
update-initramfs -u
exit

For systems that use dracut (Fedora, RHEL, CentOS):

sudo chroot /mnt
dracut -f
exit

4. Update the bootloader

GRUB (most distros)

sudo chroot /mnt
grub-mkconfig -o /boot/grub/grub.cfg
exit

If the kernel command line still contains the old UUID, edit /etc/default/grub inside the chroot and replace it, then run grub-mkconfig again.

systemd‑boot (Arch, some minimal installs)

sudo nano /mnt/loader/entries/arch.conf

Change the options root=UUID=... line, then run:

sudo bootctl update

5. Check the kernel command line

Reboot and hold Esc (or Shift) to view the GRUB menu. Press c to drop to the GRUB command prompt and type:

linux /vmlinuz-linux root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ro quiet

If the system boots, the UUID is correct. If it still fails, double‑check the UUID in /etc/fstab and the initramfs.

6. Special cases

Scenario What to do
LUKS encryption The kernel command line must point to the encrypted device (root=/dev/mapper/cryptroot). The initramfs must include the cryptsetup hook.
Btrfs subvolumes Ensure subvol= is present in the kernel line and that the subvolume exists.
Multiple root partitions If you cloned a system with separate /boot and /, update both UUIDs in /etc/fstab and the bootloader.
UEFI Verify that the EFI partition’s UUID is correct in /etc/fstab and that the EFI entry in the bootloader points to the right EFI file.

7. Security note

After fixing the boot, consider tightening the bootloader:

  • Secure Boot – If your firmware supports it, enable Secure Boot to prevent unsigned kernels from loading.
  • Password‑protected initramfs – For LUKS setups, the initramfs already prompts for a passphrase; ensure the passphrase is strong and stored securely.
  • Minimal initramfs – Removing unused modules reduces the attack surface. Use dracut --omit-drivers or update-initramfs -k all -c to trim the image.

8. Quick checklist

  • blkid → new UUIDs
  • /etc/fstab → updated
  • initramfs → rebuilt
  • Bootloader → regenerated
  • Kernel line → correct UUID
  • Reboot → test

If you hit a wall, the kernel’s dmesg output often points to the missing UUID. Use journalctl -b after a failed boot for more context.

linux  systemd  boot  clonezilla  troubleshooting 

See also