The partition UUIDs cannot be identical on 2 different devices or partitions or it confuses the OS.
Using clonezilla then leaving both devices in the same machine causes that.
One must change the UUID(s) on the device that is being migrated FROM so the new device has full control.
Usually one would disconnect the new device then boot from a live USB device and while running the live image make the changes to the older device (or just wipe out all the partitions on the older device). Then when the new device (in your case the nvme drive) is reconnected the UUIDs would no longer conflict.
Since one is seen as nvme and one is (likely) seen as sda then it may not even be necessary to remove the nvme, but booting from the live media would allow modifying the partitions on the SSD device while not altering the nvme device. – problem solved
get into chroot environment for the installed media.
a. open a terminal then use su to become root.
b. use lsblk -f to identify all the partitions on the nvme drive. Note the device names such as (/dev/nvme0n1p3) etc. Of particular need is the btrfs file system partition.
c. mount the root file system on the installed file system mount -t btrfs -o subvol=root,compress=zstd:1 UUID=<uuid of the btrfs filesystem> /mnt
where you use the actual uuid of the file system seen in 2.b. above.
d. for i in proc sys run dev ; do mount -o bind /$i /mnt/$i ; done
e. chroot /mnt
f. mount -a (which finishes mounting all the file systems for the installed system.)
g. At this point it is critical that one know the kernel used for booting and that that kernel is actually installed. uname -r provides the running kernel and dnf list installed kernel provides the installed kernels. If the running kernel is already installed then proceed – if not then it must be installed before continuing. Note that the 6.2.9 kernel is the base kernel that was on the released version of F38, and it may be the one currently running. If so and not already installed it may be installed with dnf install kernel*6.2.9*.
Now one may regenerate the initramfs with dracut --force
Once that is done then exit from the chroot environment with exit and a simple reboot should now work properly.
Probably because you may not be familiar with a chroot process. Most of those steps are to properly set up the chroot from the live media.
ddrescue and clonezilla would seem to have the same result – duplicate UUIDs on the devices.
Probably also have the same issue with the initramfs where it expects the SSD device and now has the NVME device which does not match – including the drivers that must be in the initramfs image.
The OP had an original SSD drive and replaced it with an NVME drive. This seems the source of the failure to boot and the initramfs issue. Your migration was simply nvme to nvme.
I am familiar chroot. It’s essential for diagnosing and fixing some things, such as disk repairs and booting problems. And I understand perfectly why the list in the thread you cited had to be gone through. (I’m not sure about Clonezilla, though, because I’ve never tried to use it.)
One thing nice thing about using the Fedora live iso, is that one doesn’t even have to disable Secure Boot in the BIOS to boot it.
Anyway, here, in the OPs case, he is replacing an NVME ssd with a larger one, which is exactly what I did. There’s no need to go through all of these other steps to get that done. He’ll want the same /etc/fstab settings, e.g. My / and /home are on a LUKS-encrypted btrfs partition. My C: windows drive is Bitlocker encrypted. All of that just worked. The most time-consuming part of the whole matter was the cloning operation.
Clonezilla works, dd or ddrescue works.
The way to make sure it works in the future without needing to recover like this time would be to insert the nvme drive and reboot. Then run the dracut --force command before doing the actual clone so the nvme driver is stored in the initramfs image. After that performing the clone and removing the SSD (or repartitioning it) should just work without the driver issue.
In the instructions I showed booting to a live media (step 1), then doing a chroot into the installed (real) system (step 2), then running dracut (step 3).
Dracut is to properly build the initramfs image to boot the installed system but since the installed system cannot be booted it must be done while booted to the live system and from a chroot environment in the installed system.