[original question in https://stackoverflow.com/questions/73959107/clonezilla-generates-disk-clone-with-wrong-unupdated-uuids]
I recently used clonezilla (disk-to-disk) - both stable and alternative stable to clone my SSHD ( 1TB ) to NVMe ( 2TB ) with Fedora 36 x64 in SSHD drive. Both times system is not bootable when only M.2 NVMe v1.4 is connected.
The result is the emergency shell, where no dracut (as some reported they just had to do
dracut --regenerate-all -f) or anything like that is available. That also includes Troubleshooting menu from Live USB, where emergency shell is not even listed.
I have checked Gnome Disks and noticed that for some reason the new drive is mounting the EFI/CSM partition correctly ( from NVMe disk ), but then mounting the /boot and /home from SATA3 SSHD disk.
I have attempted to use FC36 Live USB to mount the partition and it failed, therefore I tried to do
btrfs check --repair and
btrfs filesystem rescue and all options fails in one or another way.
- If I disconnect M.2 NVMe and keep SATA3 SSHD, then system with SSHD is booting into Fedora 36 just fine.
- If I disconnect SATA3 SSHD and keep M.2 NVMe, then the system screams the device with UUID cannot be found and I am thrown into useless emergency shell.
The UUIDs are identical in both disks for all partitions. My guess is that there is some additional device UUID, which points to wrong physical device within cloned M.2 NVMe disk, but I do not have such in-depth knowledge on Linux Storage to identify and/or alter the related config. Might be something similar to Linux mounts cloned partition instead of original, but since partitions use btrfs filesystem, I am not feeling safe on my own.
Other issues I noticed:
- when using boot-repair-disk X32 and X64 (https://sourceforge.net/projects/boot-repair-cd/), the nvme hits the pooling issue (https://bugzilla.kernel.org/show_bug.cgi?id=204887) and thus not starting up.
Any solution known here w/o losing the data to make my M.2 NVMe mountable and thus bootable after cloning?
UPDATE: After checking Blivet GUI Seems more closely in FC36 Live USB, like Clonezilla has somehow screwed up btrfs volumes and created the following sitation:
- The partition with same name (e.g "myLabel") is present both in /dev/nvme0n1p3 ( ~ 2TB, NVMe ) and /dev/sdc3 ( ~ 1TB, SSHD ). Seems like the Clonezillas created partition on my NVMe was attached to the excisting partition by matching label and thus formed some sort of "unified" volume. That feels like legit explanation, why system cannot boot w/o SATA3 drive, but can w/o NVMe one...
Reference: How to change filesystem UUID (2 same UUID)?
I gave up and installed it freshly via FC36 Live USB, but I had some issues:
- system was randomly freezing in anaconda
- system was crashing when installing boot loader ( the re-installation via automatics partitioning and preserving boot partitions did the trick and installer was able to finish successfully )
- still, it had additional partition empty ( the EFI and CSM ones were not reused apparently )