Gnu Grub doesn't let me use Windows

Question

Ok, long story short: I have a Surface Pro 3 running Windows 10 and wanted to run Ubuntu (version 17.04) on it, but didn't have enough storage, so I tried to boot it from a SD card. Everything was working fine and I could use both OSs for half a day until my problems started.

Every time I try to boot my computer with Secured Boot disabled and the SD card connected, it opens a menu with the option of running Ubuntu or Windows. The Windows option actually opens Windows Bitlocker or something like this which gives me the option of booting Windows 10, when I click on it, it goes back to the previous menu.

I tried to take the SD card out and enabling Secure Boot, then it opens GNU Grub and it doesn't let me use the boot command because it asks me to load kernel first.

Apparently, GNU Grub got installed on the same partition of UEFI, that would be not on my SD card, where I expected it to be. So, when I try to boot Windows, it actually boots Linux and, when I take my SD card out, it just doesn't know what to do.

Can somebody please help me? I can access Ubuntu normally, but not Windows. Thank you in advance! :)

Answer 1

You've described two problems, one of which you've worked around:

• Secure Boot -- I'm not an expert on BitLocker, but my understanding is that it requires Secure Boot to be active, at least under some circumstances. Thus, you'll need to leave Secure Boot enabled if you want to keep using BitLocker. Maybe you could find a way to coax BitLocker into working with Secure Boot disabled, but if so, I don't know how; and as Secure Boot does provide some benefits, it's probably better to keep it active.
• GRUB configuration -- By default, Ubuntu uses the GRUB boot loader, and splits it across two partitions. Part of it goes on the EFI System Partition (ESP), which is presumably on your internal "disk." The other part, though, resides in Ubuntu's /boot/grub directory, which is probably on the SD card. Ubuntu sets GRUB to booting by default, so when you try to boot with the SD card unplugged, GRUB loads but can't find its configuration or support files and spits out that unhelpful grub> prompt. There are several possible solutions to this problem:
  • Leave the SD card inserted -- You could leave the SD card with Ubuntu inserted at all times, at least when booting. (You could remove it once you've booted to Windows, if necessary.)
  • Put /boot on the internal disk -- You can re-install (or, for more advanced users, reconfigure your existing installation) with a separate /boot partition on your internal disk. This will keep everything GRUB needs available even with the SD card unplugged.
  • Use the computer's built-in boot manager -- Most computers have built-in boot managers you can use to select which OS to boot. How you access them varies from one OS to another, though. You may have used this tool to boot the Ubuntu installation medium. If you can find it, you should be able to select the option to boot Windows directly, bypassing GRUB. If you usually boot Windows, you could adjust the boot order (with efibootmgr in Ubuntu or EasyUEFI in Windows so that Windows is the default and use the built-in boot manager to select GRUB when desired.
  • Use another boot loader/boot manager -- Some boot loaders don't split their configurations across disks the way GRUB does. The easiest to use is likely to be my rEFInd boot manager. You should be able to boot to Ubuntu, install the Debian package or PPA, and be good to go, with one caveat: With Secure Boot active, you'll need to install at least one Machine Owner Key (MOK), as described on the rEFInd Secure Boot page. (To summarize: When you first boot, you'll probably get a primitive blue text-mode screen that enables you to select a MOK file. Navigate to EFI\refind\keys on the ESP and enter the refind.cer and refind_local.cer keys.)
  • Reconfigure GRUB -- GRUB can be configured to not split its files across partitions. This type of advanced configuration is a nearly lost art, though. This Ubuntu wiki page describes how to do it. Note that you'll have even bigger Secure Boot hurdles with this approach than you would with rEFInd, too.