SSD part 3: Upgrading to Windows 10

The first SSD I installed was into my laptop, back in April 2014. But since then I’ve shuffled them around, and I was back to having an old HDD. This was just about tolerable, but with the 240GB OCZ Trion 100 (a ‘meh’ quality SSD) available for under £40, and Windows 10 upgrades nagging, I thought I’d rectify the situation. Unfortunately, it didn’t exactly go well.

Initial transfer

As this was in fact my third/fourth SSD transfer scenario, it felt like a breeze. Again, using an EaseUs USB bootable, I transferred my dual-boot Windows 7-Ubuntu setup from HDD to SSD. So far, so good.

However, when I tried to upgrade to Windows 10, things didn’t go great. Instead, I got an ambiguous C1900101 error, which basically could have meant anything. By the time I got the update working some 24 hours later, I’d done three things: disabled a load of auxiliary devices; extended the system reserved partition; and disabled GRUB, reverting back to Windows’ own MBR. I think the last was probably the killer, but it could have been a mix of all three.

Disabling devices

The most common diagnosis of C1900101 is incompatible drivers. The secret is to wait for the download phase of the Windows 10 update to complete, then nip into the Device Manager and disable anything auxiliary — they’ll be automatically reenabled when the update completes. Personally, I didn’t risk disabling the mouse or keyboard, but did disable sounds, some VirtualBox network adapters, and both WiFi and wired ethernet.

Extending the System Reserved Partition

The System Reserved Partition (SRP), hidden away from view by default, contains the information Windows uses to boot. Since its inception in Windows 7, it’s gained a few other functions: the minimum desirable size is at least 350MB. Unfortunately, perhaps because of the more minimal demands placed on it in Windows 7, or because of the effect of moving things between different drives, mine was only 100MB.

The SRP sits on the far left of the disk. So to expand it, the first step is to resize the next partition along, almost certainly C:. This was painless and can be done with Windows’ own partition manager. However, what it can’t do is to move C: to the right to create space for the SRP to expand into, not least because it would have to move itself. I used GParted Live, installed onto a USB via Tuxboot for this purpose. However, I then immediately found I couldn’t boot into Windows, because the C: drive was no longer where the SRP thought it ought to be:

To cut a long story short, this is actually quite easy to fix (H/T Tom Wijsman for his answer on superuser.com). As the error message suggests, it does require a Windows recovery disk — but any will do. (Fortunately I had a Windows 8 disk though I was initially under the misapprehension that I needed a Windows 7 one — and versions of these are no longer available for free online.) First, boot into the recovery disk (in my case, F12, then selecting ODD and pressing Any Key). Then choose Next > Repair > Troubleshoot >Advanced > Command Line. Use active in diskpart to make the partition activate again and run:

While you’re there, you can temporarily disable GRUB (below).

Temporarily disabling GRUB

Because I dual boot, I used GRUB as my primary bootloader. The key point is that this is not the bootloader built into Windows. Thus the Windows 10 update process, which involves many restarts and (I believe) a custom pseudo-OS, is fundamentally incompatible with it.

The first step is to reinstate the Windows default bootloader. This is pretty easy: from the same command line as used to tell Windows where the C: drive is, run Bootmgr /FixMbr . This will (re)create the Windows bootloader and give it priority over GRUB.

At this point, I booted into Windows and was finally able to update at the third or so attempt. Woohoo, what an amazing customer experience (and TOTALLY worth it?)… Anyway, when I was done, I could reinstate GRUB using boot-repair. As described on that page (option #1) I used UnetBootin to create a live USB,  used Shift+Shutdown to suppress Windows’ new fast startup wizardry, and ran it using the recommended settings. And voilà. Time taken, >5 hours.

Leave a Reply

Your email address will not be published. Required fields are marked *