Did you try running the repair to see if it fixes it?

The reason is the boot drive now has a different ID, so Windows can’t boot from it. So it assumes (rightly so) that the boot drive has changed and launches into repair to fix it. This is something repair can fix for you normally.

Another way is to open up a command prompt in the repair environment (or from a Windows USB stick). Then use the bcdtool to edit the boot options and tell it to use the correct drive. There are plenty of instructions on this found with a simple Google search.

The cloning probably went fine, so don’t assume it has anything to do with that. Just a completely different ssd which trips up the boot.

Notably on Linux device ID are also normally used, so you would have the same kind of issue. Ignore all the Linux fanboys that go Windows bad Linux good and don’t actually help you.

I had the same issue, you need to run sysprep inside Windows immediately before you create the image. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation?view=windows-11

If you can, I recommend taking a full image of the old device and dumping it onto the new one (since the new one is bigger, this should work just fine. This will preserve all filesystem IDs and partition table quirks that may be triggering windows to repair itself.

You can do this with a command like:

dd if=/dev/sda of=/path/to/full_image.dat

Where /dev/sda is your old disk (may be sdb or sdc, use blkid to find out)

Then do the opposite on the new drive

dd if=/path/to/full_image.dat of=/dev/sdb

Where /dev/sdb is your new drive (may have a different letter)

If you can plug th both in to the same machine, you can copy the image directly

dd if=/dev/sda of=/dev/sdb

There are other dd params that may make the copy faster, but they don’t change the result. Note that dd is silent when working, but you can send signal USR1 to get progress

Ctrl-z to interrupt dd bg To continue the dd job in the background kill -s USR1 $(pgrep dd) to get a progress message

Typically, I’ve fixed this with a Windows install stick and using the bcdboot command to rebuild the BCD from scratch.

Are you booting EFI with Windows, or is the old drive MBR?

There’s lots of variables here including your expertise level with tech. I would suggest doing it again, sometimes clones don’t work and a second clone could.

Also I assume that that the new drive works with a fresh install (excluding intel RST shenanigans) and that you tested this?

Also when you go into automatic repair what options does it suggest? I’ve had many clone go weird and yet booting once in safe mode with just a reboot in safe mode fixes it.

Also if I might why Clonezilla rather than a windows aware cloner like Acronis? Also did you have both drives in the motherboard when you clone or were you using a USB adapter?

Do it again but do this first.

Make sure your new drive is recognized on your old setup. This makes sure the drive and controller is set up in the OS.

If it’s still problematic, look up “sysprep” and do that before shutting down and cloning.

If that doesn’t work, see if the new drive has a migration until provided by its OEM.

I use disk genius. It’s pretty great. Haven’t had a single failed clone yet.

Another approach is to use ddrescue instead of Clonezilla.

I never have luck doing anything like this with windows.

I’m not really sure about what it could be, did you try messing around with the hibernation settings? Maybe its trying to recover hibernation info and its somehow upset with the new disk? Also how did you expand the partition? There is a chance that something didn’t get updated properly during the expantion.

Sorry if i’m spewing bullshit, i havent touched win10 in such an extended matter in years.

It’s been a while but I always had good luck with macrium reflect

clones are never reliable

always use a fresh install