A few weeks ago I helped a friend with his computer, an older HP based desktop machine. What I noticed when checking his installation was that his HDD has some issues and as part of upgrading the machine to make it more usable we also agreed to move from an old spinning disk / HDD to a modern SSD. What we saw on the machine was in the Windows task manager that the system was hanging and waiting for IO. The HDD clearly had a problem and he started to at least make backups of his drive regularly (I hope).
To make a long story short, I ordered a nice Crucial 1TB SSD and started to work on the machine, using Linux and simply cloning the disk via dd – which simply did not and the machine would not boot, not even the repaid partition…. So what to do as the systen was fully secured and used a Uefi enabled boot process. This technology had been introduced some time back to protect systems from rootkits, malicious software that changes the boot process and gets very deeply embedded within a given system.
After multiple tries and failures (and some research I got it working, here is the process I used), based from an Ubuntu 22.04 live CD.
- clone the partition table
In this case it was pretty easy to do so as both disks had the same size. sfdisk is your friend here. You basically copy the old partition table into a file and then rewrite the partition table to the new disk. Step one done. - cloning the NTFS partitions
now we need to start looking at the partitions. When using Linux you can either use a commandline tool like “lsblk”, fdisk or if you prefer a UI (assuming you don’t use command line), gparted is your friend. In my case I had 5 partitions on the disk, 3 of them were NTFS (Windows partition, some hidden windows partition and the recovery partition) – to of them were fat and unknown.
To clone the NTFS partition ntfsclone helps and does the job quickly. In my case I did a disk to disk copy without writing to an image, so I used the “–overwrite” option. One problem I ran into was that indeed the HDD had issues and quite a lot of faulty sectors. the “–rescue” option tries to fix them or skips the sectore, so I cloud in the end clone the Windows partitions. - clone the efi and boot partition
for the other 2 partitions, dd did the job quickly, unsing the “bs=1M” option. Business as usual there. - cloning the MBR
For the system to boot, I finally cloned the MasterBootRecord (MBR) from the old disk to the new disk.
For me the following command worked well
sudo dd if=/dev/old_disk of=/dev/new_disk bs=512 count=1 - rebooting the system
After this I could simply reboot the system. Of course, Windows complained, collected data and rebooted into a working system.
As I said, this solved the issue for me, no problem rebooting from the SSD afterwards multiple times. The trick I think is that sfdisk copies the whole partition table plus the IDs, so Windows does not see a big enough change there. To be sure I also triggered a “chkdsk /f” from an elevate rights shell (Shift-Ctrl pressed when opening the terminal). On the next reboot Windows will check the disk before booting the system.
Random thoughts and bits 