Home / ubuntu / Questions / 501394
Accepted
Marco van Hilst
Asked: 2014-07-23 20:13:32 +0800 CST

Ubuntu installer overwriting Windows 8 bootloader on disk to which it wasn't installed

  • 772

This all started when I went to install Ubuntu on a partition on my external HDD. In the Ubuntu LiveUSB's installer, the configuration was to create an ext4 partition in empty space on the external HDD (/dev/sdc3) and write the bootloader to /dev/sdc. The install completed nicely and I was able to boot fine into the new Ubuntu partition- with one catch.

Upon restarting, I had been greeted with a complaint from Secure Boot (Secure Boot Violation - Invalid signature), which was odd, given that I had not told the installer to touch the original bootloader (or anything, for that matter) on /dev/sda. I got prompted with GRUB after dismissing the complaint, also strange seeing as I had not gotten to the point where I could choose the boot order. I rebooted without the external HDD to verify that it was on the main drive and not the external one, at which point GRUB gave me a terminal rather than a menu. Typing 'exit' brought me back into Windows 8.

I've attempted to erase GRUB by booting into Windows in command prompt mode and using bootrec /fixmbr and bootrec /fixboot, but it had no effect and GRUB remains.

So my questions are:

  1. Why did Ubuntu's installer decide to write GRUB to both /dev/sda and /dev/sdc when I specified /dev/sdc as the bootloader partition and /dev/sdc3 as the Ubuntu install partition?
  2. How can I get rid of GRUB with something other than Windows in recovery mode?
boot

2 Answers

  1. Best Answer

    Please forget everything you ever knew about boot loader installation, at least with respect to the computer under discussion. You're trying to apply BIOS assumptions to an EFI (non-BIOS) computer, and they don't apply. (Yes, I know that most people, and even manufacturers, refer to EFIs as BIOSes, but that just causes confusion. See Adam Williamson's blog post on this subject for more details.) The Windows bootrec /fixmbr command is intended for dealing with BIOS-mode booting, and so is inapplicable to you. I don't know about bootrec /fixboot; it might or might not be useful on an EFI-based computer.

    Under EFI, all boot loaders and related programs reside in the EFI System Partition (ESP), which is a FAT partition whose purpose is to hold boot loaders and related files. Ordinarily, a computer will have just one ESP, although it is legal for a computer to have multiple ESPs. A two-disk computer might have one, two, three, or more ESPs. In the case of a multi-ESP computer, it's unclear which one the Ubuntu installer will use. In theory, the Ubuntu installer should use the one identified as the "EFI boot partition" (their own non-standard name for the ESP) in the installer; however, I have my doubts about whether Ubuntu does this consistently. (I haven't had the chance to look at this in depth.) In any event, the Ubuntu installer retains a BIOS-mode prompt for where to install the boot loader when installing in EFI mode, but it's completely useless! I think there's a bug report about that on Launchpad, but a quick search didn't turn it up.

    In theory, then, an EFI-based computer can have dozens of boot loaders installed. Which one does the firmware actually use? This is determined by a set of NVRAM entries, which identify the boot loaders and list the order in which they should be tried. The NVRAM entries identify boot loaders by partition and filename.

    It's unclear whether you've got one, two, or more ESPs; however, because the NVRAM entries identify boot loaders by partition and filename, that detail is essentially irrelevant. Chances are that what happened is that Ubuntu added GRUB to an ESP and added an entry to the computer's NVRAM telling it to use GRUB by default. (In fact, it would point to Shim, which is one of Linux's tools for dealing with Secure Boot. Shim will then launch GRUB.) I'm not sure why you're getting a Secure Boot warning followed by GRUB. Maybe you've got an NVRAM entry that points directly to GRUB without going through Shim followed by an entry that points to Shim. That would explain it, but AFAIK the Ubuntu installer doesn't set things up this way.

    Under EFI, you can edit the NVRAM entries to control the boot order. In Linux, the efibootmgr utility does this job. In Windows, you can use bcdedit or a third-party tool like EasyUEFI. Using efibootmgr, type the command alone to see a list of boot entries, then use the -o option to set the boot order, as in efibootmgr -o 5,3,8 to have the firmware try Boot0005 first, then to launch Boot0003 if that fails, and finally to try Boot0008. (Of course, you'll need to set the order for your system, based on the output of efibootmgr without any options.) Most EFIs have their own boot manager to enable you to select a boot loader. Details vary greatly from one computer to another, though. You must typically press a function key early in the boot process to get to this boot manager.

    • 3

    1. I think you would have to tell it to NOT install to /dev/sda as that's where it installs by default.

    2. Using a Windows repair disk follow these instructions http://www.fixedbyvonnie.com/2013/12/how-to-repair-the-efi-bootloader-in-windows-8/ I believe you still need to recreate the Boot Configuration Data (BCD) store to fix your issue (/fixmbr bootrec /fixboot is not enough).

    • 0