An unwelcome recovery
I recently upgraded my gaming laptop from an MSI G75 Titan (Core i9 with a 1080 GTX) to an ROG Strix Scar 17 (Ryzen 9 with a 3080 RTX).
The Titan is still a great machine though, especially after the SSD and RAM upgrades I’ve given it (6TB and 64GB respectively), and so rather than sell it I decided to make it a dual-boot Windows/Linux desktop replacement laptop for productivity. I could even leave Steam installed on Windows, install it on Linux, and leave a couple of my favourite non-RTX games installed on a shared SSD for a couple of rounds after work.
Since Windows was already installed and, other than games, it was pretty much a clean install, I decided not to bother with a reinstall and instead to just install Linux on one of the other SSDs. Since my daily is a MacBook with MacOS, I’d make Linux the default OS and use Grub as my default bootloader.
Out of an abundance of caution, I disabled BitLocker on Windows and then installed Ubuntu onto a separate SSD. Once done, I booted back into Windows and re-enabled BitLocker.
After setting up a few things in Linux, I was surprised to find when attempting to boot back into Windows that I was presented with the BitLocker recovery screen.
I tried a few of the more obvious things like disabling BitLocker, rebooting, re-enabling it, disabling “secure boot” in the BIOS, changing the SSD boot priority… none of which worked. So I Googled.
Trial and error
Among the many SuperUsers, StackOverflows, forums and guides, I found a ton of suggestions that a couple of people would swear by while others would complain didn’t work. From experience, I know that whenever a problem has “lots” of solutions, it means none of them actually work reliably, and so I took a deep breath before trying most of them out in turn.
One of the more popular suggestions was to enter BitLocker management on Windows and to suspend it. The user claimed that doing so allowed his machine to boot into Windows without a problem while leaving the protection of the encryption intact. Other users replied and confirmed that it worked. So I tried it.
While it worked for a single reboot, rebooting again after that resulted in the recovery screen making a return. It was literally a one-hit wonder. This seemed to be the expected behaviour really though as the popup asking me if I wanted to confirm the change actually stated in black and white that the feature would be disabled for a single reboot and would then be reapplied after logging back into Windows.
A more promising route lay in a workaround that someone said they had found by accident, which was to escape out of Grub with the Escape key and then to type “exit” at the resulting prompt. This would quit Grub and defer control to the Windows bootloader without a chainload, which the Windows bootloader was satisfied with and so would subsequently load Windows. I tried it. It worked!
However, pressing Escape at Grub and then typing
exit every time I wanted to boot into Windows was not an elegant solution and was very much a temporary workaround. But with no desire to spend more time on this problem, I decided to look for a way to make this solution more elegant rather than to continue to look for entirely different solutions.
As a proof of concept, I went back to Grub and pressed E with the Windows option in focus in order to edit the code behind it. Above the conditional, I simply entered
exit 0, with the intention being to exit Grub and defer control to the Windows bootloader when the Windows option was selected and bypassing the chainloader entirely:
exit 0 insmod part_gpt insmod fat if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root 20CE-363B else search --no-floppy --fs-uuid --set=root 20CE-363B fi chainloader /efi/Microsoft/Boot/bootmgfw.efi
As an aside, I have no idea why there’s a conditional in here that just ends up running the exact same code in either case. It doesn’t inspire a whole lot of confidence in the rest of the code but I digress.
So, with the change made, I then executed it with CTRL-X… and yep, Windows booted.
Editing the code behind an option from Grub itself only changes the code for that one occasion, and in order to make it a permanent fix it needs to be changed in the Grub config. So I rebooted, signed into Ubuntu and then performed what I would say is the TLDR in this particular case:
Grub Customizerfrom Ubuntu Software.
- Open it and select the Windows entry and select the Modify option.
- Simply enter
exit 0above the rest of the code.
- At this point you can also do some housekeeping. I changed the needlessly long title to just “Windows” and I moved it to just below “Ubuntu”, above the debugging options. You may want to refactor out the pointless conditonal as well but I didn’t bother as this code will no longer be executed anyway.
- Hit save.
After rebooting, select the Windows option from Grub and you should hopefully see that Windows boots up without issue, and that it continues to do so from that point onward regardless of reboot count.