Boot Repair provides a simple user interface to a tool that is in fact extremely complex.
Originally written: 4/27/2013; last update: 7/29/2013; archival note: 6/13/2015
This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
| Donate $1.00 | Donate $2.50 | Donate $5.00 | Donate $10.00 | Donate another value |
Archival Note: This page is largely obsolete because of changes in Boot Repair's default options. Specifically, Boot Repair no longer automatically performs the "Backup and rename EFI files" operation described later on this page. Nonetheless, I'm leaving this page in place both as a warning to not use that option unless you're reasonably certain it's necessary and as a cautionary tale to be careful about over-application of fixes that are necessary in only a few cases.
This page is part of my Managing EFI Boot Loaders for Linux document. If a Web search has brought you to this page, you may want to start at the beginning.
Ubuntu's Boot Repair tool is a user-friendly GUI program that's intended to fix a wide variety of boot issues. Although it often works, its user interface is intentionally very simple, and it therefore often does more than is necessary. In an EFI context, this can create new problems, particularly if you don't want to use Ubuntu's version of GRUB 2. This page will help you overcome these problems.
Boot Repair provides a simple user interface to a tool that is in fact extremely complex.
Boot Repair presents a simple user interface with just a few options in its main window, as shown to the right. Most users, confronted with a computer that's not booting one or more OSes, will naturally click the button labeled Recommended Repair. Experts might click Advanced Options to see what else is available—but the result is a dialog box with a plethora of options that can be a little unclear even to an expert.
To understand what Boot Repair does (and, in some cases, does wrong), I prerformed an experiment. I began by doing a fresh installation of Ubuntu 13.04 in a VirtualBox environment. I then installed two copies of rEFInd on the virtual computer: Once as the fallback boot loader and a second copy as a stand-in for the Windows boot loader. The result was the following boot loader files in the EFI System Partition (ESP):
EFI/BOOT/bootx64.efi EFI/Microsoft/Boot/bootmgfw.efi EFI/ubuntu/grubx64.efi
The copy of grubx64.efi was installed by the Ubuntu installer, and did work; however, because of a quirk of VirtualBox, its (virtual) NVRAM entries tend to be forgotten, so I needed to select grubx64.efi using VirtualBox's EFI user interface to boot Ubuntu the first time. Thereafter, I installed rEFInd as EFI/BOOT/bootx64.efi; it became the virtual machine's boot loader. I also installed a copy of rEFInd as EFI/Microsoft/Boot/bootmgfw.efi, just for this demonstration, since it illustrates what would happen to a computer that dual-boots with Windows.
With this system in place, I ran Boot Repair. The number of boot loaders on the ESP doubled:
EFI/BOOT/bkpbootx64.efi EFI/BOOT/bootx64.efi EFI/Microsoft/Boot/bkpbootmgfw.efi EFI/Microsoft/Boot/bootmgfw.efi EFI/Microsoft/Boot/bootx64.efi EFI/ubuntu/grubx64.efi
By default, Boot Repair replaces both EFI/BOOT/bootx64.efi and EFI/Microsoft/Boot/bootmgfw.efi with a copy of GRUB, renaming the original files so that they can be accessed or restored. It also places a copy of GRUB as EFI/Microsoft/Boot/bootx64.efi. Thus, after running Boot Repair, the number of copies of GRUB on the ESP quadrupled, from one to four! The reason for placing GRUB in these extra locations is to work around problems with a handful of buggy firmware implementations that ignore or forget their NVRAM entries. In fact, VirtualBox qualifies as one of these implementations, so if I'd run Boot Repair on the system before installing rEFInd, Boot Repair would have done the right thing.
The main problem with this approach is that it's blind. Many EFI boot problems are not caused by buggy firmware that can't remember NVRAM settings. In such cases, adding three extra boot loader files to the ESP just adds clutter that makes it harder for a human to figure out what's going on. Other boot managers, such as rEFIt, rEFInd, and even other distributions' copies of GRUB, may end up with menus that are cluttered with extra boot options, as well. Furthermore, the boot entries don't always work. When I rebooted my VirtualBox machine, GRUB presented the following options:
Ubuntu Advanced options for Ubuntu Windows UEFI bkpbootmgfw.efi EFI/boot/bkpbootx64.efi EFI/boot/drivers_x64/ext4_x64.efi
Unfortunately, the options for the rEFInd backups (bkpbootmgfw.efi and bkpbootx64.efi did not work reliably—when I selected either option, I usually saw a line of text appear on the screen too quickly to read and then the GRUB menu returned. In my efforts to read the text, though, I tried these options repeatedly, and after about ten or fifteen tries, rEFInd appeared! Judging by posts I've seen on Web forums, the Windows boot loader often doesn't fare any better—many users report being unable to launch Windows from GRUB after running Boot Repair. The GRUB entry for ext4_x64.efi, when selected, loaded rEFInd's ext4fs driver—but this driver is useless to GRUB.
If you run Boot Repair and subsequently install another boot manager (such as gummiboot or rEFIt), or even reconfigure your system to boot a version of GRUB that does not know about the Boot Repair changes, the result is likely to be an inability to launch the Windows boot loader—most boot managers don't look for the EFI/Microsoft/Boot/bkpbootmgfw.efi file, and so won't add it to their menus. rEFInd is a partial exception to this rule; since version 0.7.1, rEFInd does scan for this filename. Even then, though, the result is extra boot entries.
One other problem with juggling EFI boot files deserves mention: Windows can undo it. I've seen reports to the effect that Windows will reverse these changes when it boots, rendering Boot Repair's efforts moot. If you run into such problems, you should probably use one of the alternative methods of registering a boot loader with the EFI mentioned on my page on installing EFI boot loaders. The use of Windows' own bcdedit program seems particularly likely to work in such cases, according to reports I've seen on Web forums. To be sure, this problem doesn't always crop up, but it does with enough regularity that it's a real problem.
Of course, Boot Repair does more than simply juggle EFI files around: It completely re-installs GRUB and generates a new grub.cfg file. The Advanced Options menu enables you to add kernel options, enable or disable Secure Boot support, and more. These capabilities can be worthwhile.
In fact, if you check the Main tab of the Advanced Options menu, you'll see a setting that controls the creation of those backup files, as shown here:
The Backup and Rename EFI Files option is set by default, and it's the culprit behind the overzealous renaming of files. If you're having problems with GRUB configuration but are not having problems launching GRUB, I strongly recommend that you uncheck this option before letting Boot Repair do its thing.
I can offer no advice on fixing problems with launching Windows or another boot loader from a version of GRUB that's been adjusted by Boot Repair, except to try another boot manager. As you can tell if you've read my GRUB 2 page, I'm not a big fan of GRUB 2. Other boot loaders have been much more reliable, in my experience.
If you've wound up with the backup boot loader files described on this page and you want to return to the original setup, Boot Repair does offer an option to do this: It's the Restore EFI Backups option on the Main Options tab of the Advanced Options menu (shown earlier). Check that box (Backup and Rename EFI Files will automatically uncheck itself) and click Apply. This will cause Boot Repair to restore the files that were originally present. This can help you if Boot Repair has, as in my demonstration, hijacked a boot manager or boot loader that you actually wanted to run first. It can also help if you've installed rEFIt or rEFInd and you want to trim the boot options in that boot loader's menu.
You can, of course, do a similar repair manually. As I write, Boot Repair renames files so that the originals have bkp prepended to their names. Previous versions of the utility have used other naming conventions, though, such as adding a secondary .bkp extension. You may need to peruse your files and make an educated guess about how they've been renamed. If in doubt, move or rename the bootx64.efi and bootmgfw.efi files so that you can restore them easily should that be necessary. You can then rename the backup files to their original names. Note also that you might not have both bootx64.efi and bootmgfw.efi files; one or the other (or even both) might be missing on your computer.
Once you've juggled the files to restore them to what you hope to be the correct state, you may need to type sudo update-grub or sudo grub-mkconfig -o /boot/grub/grub.cfg to re-create the GRUB configuration file. The reason this may be necessary is because the GRUB configuration file created by Boot Repair includes references to the backup files, which you probably want to excise. Re-creating the configuration file using GRUB's own scripts should do this.
If you're left with boot problems after undoing unwanted Boot Repair modifications, I recommend you start by learning more about the EFI boot process. This page is part of a set that can help. You may want to peruse the table of contents, and pay particular attention to the pages on EFI boot principles and EFI boot loader installation. An understanding of the boot process and boot loader installation will help you to repair whatever problem troubles you; you'll be able to apply your human intelligence to the issue at hand rather than rely on a utility that blindly applies a set of broad "fixes" that sometimes cause more problems than they cure.
My own boot manager, rEFInd, often works better than GRUB if you're having problems booting Windows; GRUB seems to be particularly finicky about launching other EFI boot loaders (including Windows' boot loader), whereas rEFInd usually succeeds. If you install rEFInd before correcting Boot Repair's overzealous renaming of files, though, you'll end up with too many boot entries, and the entry for Windows will probably boot GRUB instead. Thus, undoing those changes before installing rEFInd is imperative.
Go on to "CSM: The Good, the Bad, and the Ugly"
Return to "Managing EFI Boot Loaders for Linux" main page
copyright © 2013–2015 by Roderick W. Smith
If you have problems with or comments about this web page, please e-mail me at rodsmith@rodsbooks.com. Thanks.
Return to my main Web page.