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.
Since I just did this six months ago, using ddrescue and gparted, this procedure looks super complicated to me.
My method was:
Boot to a live cd; I used the latest Fedora Workstation iso for this.
Ensure it’s on your network; sudo dnf install ddrescue gparted.
Open gparted and figure out which drive is which.
ddrescue the entire old nvme drive onto the new, larger drive (I forget the exact ddrescue arguments to do this, but is was a very basic set.)
From gparted, reload all drives; you’ll be prompted that the target drive appears larger than the size in the gpt and whether you’d like it to be adjusted to the correct size; answer yes.
Close all apps, and shut your live system down.
Physically swap drives out;
Fin.
If your system is like mine, which was and is dual booting Windows and Fedora, it’ll boot without doing anything else.
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.
Switching from the ssd to the nvme drive seems the issue with it not booting. Had both devices been nvme as was your case it would not have been an issue.
Yep, in my case it was pretty much the fact the when booting it appeared that it was looking for a sda device and not nvme, and no driver was enabled for it.
In future if I need to clone a 2.5 SSD to NVMe.
What is the optimal way of doing things in future. This time I used Clonezilla but happy to use DD or another method.
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.
Just one quick clarification. When I run the dracut --force. Is that done from a Live Fedora boot or should that be done after a normal boot to Fedora.
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.