Notes: Rescuing a Box & Downgrading Win10 GPT/UEFI to MBR/BIOS Boot

A week ago, I was busy attending to another one of those “family emergency” style tech support calls. This time, I had an old box arrive at the house seemingly completely dead, in the hopes we could revive it as soon as possible for as little as possible. It had some important software and data on it – so everything had to be preserved as much as possible.

What’s the Prognosis?

The box in question was a pre-built Lenovo H30-05 dating back from 2015. This was a small-form-factor box which shipped with Windows 10 Home and an old fashioned rotating hard disk of 500GB capacity. It’s no wonder that it was not well loved, with many complaints about it being slow beyond belief. The board did not use traditional ATX or miniature variations for power supply, instead opting to use the rectangular-plug laptop 65W power supplies, thus suggesting that it had a heart that is more akin to a laptop shoehorned into a desktop.

Nevertheless, troubleshooting began with the obvious checks. Clearing the CMOS, reseating all RAM, removing unnecessary connections, plugging in power supply and hitting the power button. Nothing. Nada. Not even a twitch of a fan or a click of an inductor – everything was dead silent.

Perhaps it was the power supply itself? I measure the output and it’s happily putting out 20V into the motherboard, but for good measure, I swap it with a unit I used with my Lenovo E431 laptop that I know works fine … no change.

It seemed likely there was something wrong with the board’s power conversion circuitry – perhaps a dead MOSFET or controller somewhere. My thermal camera is at the university doing research, so I didn’t have a chance to see if I could spot something amiss, but by now, the prognosis was grim. The finger and smell test did not reveal anything amiss either.

Measuring the power button pins, +5VSB or its equivalent was available. Shorting it to ground did absolutely nothing. By now, I’ve stripped the whole machine apart in case there was a hidden short somewhere and still, the board was not coming up.

It was then I decided to delve deeper into the specs – for a 2015 machine, this one had an AMD E1-7010 APU of 10W TDP rating with a CPU Mark of just 582. That was so cruelly poor that it’s basically only around netbook performance carrying a full Windows 10 install. No wonder – paired with a rotating hard disk and just 4GB of RAM, this thing would have been a snail. I decided that even if it were to be repaired, the performance would not be worth the hassle, so the board was written off entirely.

Looking for a Donor

Since we would like to keep the install as original as possible to keep the software and data on it going, I decided to try and match it with something I had spare in stock. Unfortunately, APUs never really had my fancy, so I was reduced to looking for something that was AMD-based of the era.

In the end, I settled for my backup AMD Phenom X6 1055T from two years earlier in 2013 which scores a CPU Mark of 3189, paired with an Asrock 880GM-LE FX mATX motherboard which has integrated graphics. Still with its stock heatsink, this was my “daily driver” two machines ago and still worked well when packed away. With this, I would put in 8GB of DDR3 1600MHz RAM to give modern apps a bit more breathing room. For their relatively minimal word-processing and web-browsing demands, even such an old board approaching a decade could still handle the tasks, assuming it physically lasts.

Only problem is … it’s a BIOS-based machine.

Booting Technicalities

In parallel with diagnosing the board, I had whacked out the hard drive, stuck it into a cradle and began imaging it. Thankfully, the SMART data was all clean on the drive, so imaging was straightforward with no errors.

But one thing I did notice was that it was partitioned GPT with UEFI boot despite the drive being just 500GB. I suppose that was the “Microsoft recommendation” where possible to eschew legacy to ensure newer technologies work well, but it also complicates the migration a lot. Merely imaging the drive across would not make a bootable system simply because the BIOS wouldn’t know what to do and how to interpret the format of the new drive.

What Didn’t Work …

Nevertheless, I embarked on a journey of discovery, as a downgrade of an install from GPT/UEFI to MBR/BIOS is not a common operation. I thought that it wouldn’t be too hard, so the first thing I did was to write the whole image to my Kioxia Exceria 960GB SSD (as I had intended to banish HDDs from the role of booting machines once and for all).

Afterward, I booted Linux from a live USB key and corrected the GPT as the backup GPT is in the wrong place due to the mismatched drive size. Just for fun, I rebooted again to see what the BIOS would do – it didn’t boot as expected.

The next step was to try converting the GPT disk to MBR. There were a few threads online stating various methods of doing it without data loss – I could have worked out where partitions started and ended and manually keyed in these values into an MBR partition table, but I decided to try taking the easy way out using EaseUS Partition Master. It is understood that such a conversion would not result in a bootable system in itself, but I did the conversion anyway as the first step.

Now left with an unbootable MBR-based disk, I booted into the Windows 10 installation media to the “recovery console” to try and repair the boot using the standard procedure if using various bootrec commands.

This is where I hit my first major snag – on trying a bootrec /FixBoot, I received an error about Element not found. I suspected this meant one of the system/EFI partitions wasn’t where it expected it to be, so I followed some of the suggestions to check that it was mounted (it was), even through to destroying it and attempting to recreate it (which went disastrously and led nowhere as various commands for this did not apply to BIOS-based systems). Following through to the other steps and going back led nowhere either, so now I was well and truly stuck …

From here, I decided to just blow away the EFI-system and recovery partitions, leaving the main partition intact. As I have other MBR-based systems that boot Windows 10, I thought I’d cheat and bring out Acronis TrueImage and just grab an image of their EFI-system and recovery partitions and restore them over the top of this MBR disk. Despite selecting to put the EFI-system partition up-front, TrueImage decided not to use the “gap” at the beginning and shuffle partition numbers and instead put the two restored partitions towards the end … resulting in this odd partition table (output from fdisk in Linux):

I tried twiddling the active flags and trying to repair the boot after restoring this but had no luck. In my desperation, I decided to use fdisk to redraw a new partition table, making the EFI-boot partition as number 1 with it allocated in the “gap” before the main data partition, followed by the recovery, then formatting the EFI-boot as FAT32 as recommended. Unfortunately, startup repair was not able to fix this nor was I able to get the bootrec commands to play ball.

By now, I was a few hours down (mostly due to the slowness of the drives), so I decided I needed a new approach.

What Worked …

Given the above result, I decided to take a different approach for the second attempt. I decided to image the main partition containing the OS and user data using Acronis TrueImage first.

Then, I installed Windows 10 from the install media and got a basic installation bootable on the machine. This was relatively straightforward and worked first time.

Then, I restored the backup of the OS and user data only and put it over the top of this fresh installation. By doing this, I would essentially be keeping the boot structures from the fresh install, but substituting the OS and user data.

Surprisingly, this approach worked fine enough to get the boot screen up … but very soon after, I hit a BSOD due to dissimilar hardware and incorrect drivers. Despite sticking with an AMD platform, it was still not close enough.

In the past, I would boot Linux and start nuking various .sys driver files based on what I saw on BSODs to try and make it bootable. This time, I did one better and used Acronis Universal Restore without any extra drivers just to strip out the troublesome ones and have the default drivers load. This worked well, but caused some devices to have Code 32 errors. This was only fixed by reinstalling the drivers for affected devices … but eventually, the system was up and running again and as the license was tied to a Microsoft Account, it seems that activation didn’t even blink!

Of course, what resulted was a bit of a Frankenstein of spare parts along with some driver hassles as the integrated AMD Radeon HD4250 graphics wasn’t “Windows 10” ready and the later drivers gave worse results than older ones which did manage graphics acceleration and native resolutions.

Building a Frankenstein

In all, the box now looks a bit like a hotrod. The full-size Corsair VS450 which I had spare now hangs outside the box since the SFF wouldn’t accomodate a full-size power supply.

I drilled some holes and cut some of the grille to install an external 120mm fan to blow into the case from the side to stop the board and chipset from overheating. After all, replacing a 10W TDP CPU with a 125W TDP CPU using a stock heatsink also means needing to add proper active cooling to the box. I had to put it from the outside, since the clearances internally were not enough – the stock heatsink pretty much just fits inside the case as it is. Hot glue stops the fan wires from shorting out on the sharp edges.

I repinned the power button and LEDs since the front-panel blocks were non-standard. The front USB and media ports used a moulded cable construction which would need a lot of work to cut, strip, crimp and repin, so I didn’t bother. Later, I added a “tail” of two USB ports just hanging out of an air ventilation grille to provide some front-accessible USB ports for convenience.

The original optical drive is retained and the SSD is mounted on a 3D printed adapter. Copious amounts of cable ties hold wires in place in an otherwise messy case. It’s not pretty, but it works and that’s what’s important.

Conclusion

A downward migration from GPT/UEFI boot to MBR/BIOS boot is not a common operation – in fact, this was the first time I had tried it out of desperation to revive a box using old parts in an emergency. Ultimately, I was successful by installing a fresh install and restoring only the OS/data while leaving the boot partitions intact. The other approach of trying to “repair” a straight image didn’t seem to work, but I don’t know exactly why. Regardless, now this SFF has been hotrodded with older parts, but is now much faster than it used to be – about six times the CPU Marks, twice the RAM, twice the storage which is now SSD versus HDD – this thing boots up pretty quickly especially when its age is considered. Hopefully this will be enough to keep things going until the next bargain computer upgrade comes along …