Published in Technology on A Place For My Head. Tagged , , , , & .

My computer has an SSD where I install Windows and all my other applications, plus four regular HDDs for my data. The SSD was always running out of space, so I needed to upgrade it. I thought I’d switch from a regular SATA disk to a PCIe NVMe disk at the same time, not so much for speed but for futureproofing. Using the NVMe port on my ASUS PRIME B350-PLUS motherboard disables the last two SATA ports, meaning I can’t use the SATA SSD as a secondary cache.

I’ve been eyeing high-end 2 TB SSDs since 2019, when I last performed a major upgrade. I hoped prices would fall enough to make a good one affordable, but the pandemic put paid to that idea. Given the extant or looming shortages in every industry, I couldn’t afford to wait any further. I got a good deal on a Samsung EVO 970 1 TB, so I snapped it up.

A series of frustrating events

Once the new disk arrived, I opened my cabinet, pulled up a diagram of my motherboard, and examined the ports. I found the NVMe slot and determined the correct position for the screw that would hold the disk down. Said screws are usually provided along with the motherboard. Unfortunately, I seemed to remember placing the motherboard box in storage shortly after installing it. I had to rely on the kindness of a friend, who sent me a spare set from a different motherboard a few days later.

I once again opened the cabinet, but now I had a new problem: the screw didn’t fit. Apparently, they’re not all the same. I was about ready to scream.

Rescuezilla works well but it desperately needs UI scaling, doesn’t quite get the transfer speed right, and insists my battery-less desktop’s battery is dead

This inspired me to drop my assumptions… and what do you know, I found the motherboard box after five minutes of searching, not in storage but under my bed. Carefully tucked away inside was the right kind of screw. I triumphantly carried it over to the cabinet and installed the new SSD on my second attempt, once I understood how much force the screw needed to apply. I disconnected one of the magnetic disks since the port was no longer available and left the old SSD connected with the case open. I used Rescuezilla to clone the contents to the new one. It was done!

Sadly, my troubles were far from over. All my disks are encrypted using VeraCrypt. It deals specially with the system disk (i.e. the disk on which the OS is installed). When I booted from the new disk, which was in theory a bit-perfect clone of the old one, the boot loader was unable to decrypt the disk. I’m not sure why. I tried several times, and even typed out the password character-by-character with my eyes on the keyboard, but nothing worked. I repeated the cloning process and tried again too, without success.

I installed Windows from scratch on the new disk and halfheartedly went about setting up the fundamentals of my environment while I considered my next move. With my patience wearing thin and out of concern for my data, I decided I needed to decrypt the old disk. I put it in an external USB enclosure so I could get it out of my cabinet, booted from the VeraCrypt rescue disk, and chose the option to decrypt the OS. I had a moment of panic when it first said it couldn’t decrypt the partition, but it got to the right partition afterwards and began the process. The estimated time? 10 hours, at a blazing 12 MB/s. Why? Per Alex (one of the developers, I believe):

Rescue disk works in BIOS legacy mode. The mode is 16 bit and one thread. In addition to slow CPU mode it uses BIOS R/W. It is slow also. So the result is very slow.

To avoid slow decryption it is better to decrypt on other computer or OS. We are working to solve the problem

There was much wailing and gnashing of teeth, some of which may even have come from me.

10 hours to decrypt the volume

I was stuck. The process was underway. Although I found one or two comments online saying the decryption was unimpeded by rebooting in the middle, others said it would cause corruption (which seemed logical). In any case, the only way I could speed up the process was by booting into an OS and decrypting it from there, which was impossible: I couldn’t mount the data at all under the OS on the new disk, and the old one was already partially decrypted, which might prevent me from booting that OS at all. I was stuck.

It was a bad time for me to be without distractions, for unrelated reasons. I spent the next 10 hours reading a lot and anxiously checking the progress. In future, I’ll have to dispense with the cloning entirely and copy the data somewhere else before switching disks.

At last, nearly 10 ½ hours later, the entire process was complete. I was able to boot into the installation on the new disk and access the (completely unencrypted) data on the old disk. Given that it was nearly 6:00 a.m. by then, I called it a night without having accomplished much.

Getting things up and running

I maintain an Emacs Org Mode file documenting all the steps I need to take to reconfigure Windows after installation. As a compulsive tweaker and tinkerer, there are an endless number of fiddly details I need to watch out for, including innumerable annoying little Control Panel, File Explorer, and Internet Explorer (…for File Explorer) settings, and I do my best to keep the file up-to-date. Installing and configuring keyboard layouts is also very tedious.

I only have a few registry files to help me. Doing it all by hand is difficult; I need to automate more of the process. In fact, several times now, I’ve started exploring the world of automated Windows installation & configuration, but shrunk from the complexity. I think I have no choice but to learn now, to be prepared for next time.

As an easy starting point, I decided to try Scoop, a ‘command-line installer for Windows’. I was a little confused about the installation directories at first, but once that was resolved I found it to be smart and easy to use. A few applications (e.g. IrfanView) can’t be set as Windows defaults in their portable incarnations, so those need to be installed normally.

I think there may be an issue with the order of installation between Scoop, PowerShell, and Windows Terminal. Scoop needs a newer version of PowerShell than what Windows ships with. I believe upgrading to PowerShell 7 usually adds an entry to the WT configuration, but I had to upgrade PowerShell before I could install Scoop, which I then used to install WT, so there was no file to add the entry to. Repeating the process afterwards had no effect. I had to manually change powershell.exe to pwsh.exe in the WT settings in order to switch from the builtin PowerShell 5 to the upgraded PowerShell 7 and trigger my custom profile scripts and settings.

I made a bit of a mistake while trying to uninstall some useless default apps. I entered this at the PowerShell prompt:

PowerShell$packages = ("3dbuilder", "windowsalarms", "windowscommunicationsapp", "zunemusic", "windowsmaps", "zunevideo", "onenote", "people", "photos", "xboxapp")

Foreach ($package in $packages) { Get-AppxPackage "*$_*" | Remove-AppxPackage }

I thought it would only affect the listed packages, but I was horrified to see it remove a long list of builtins. I terminated the process out of fear. Almost everything disappeared from the Start Menu tiles. I have no idea whether that included essential apps. It certainly included the Microsoft Store, which I had to reinstall. I suppose I’ll find out soon whether I’ve broken anything else.

Miscellany

A sense of relief

This entire migration has been a real chore, but all the angst was worth it. I now have practically the entirety of my old disk sitting in a directory in my new disk alongside all the new data, and yet I’m left with over 360 GB free—a far cry from the 4–5 GB I managed before.