Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have here a new bought laptop. It's the first device with (U)EFI I was working with. At first I did not get the installation running, so I switched back to BIOS legacy mode and installed ubuntu in that mode.

All right. Now I want to add the preinstalled windows back into the boot loader to allow multiboot. This works only via EFI. So I googled around and found this link. I modified things a bit as I was after some tasting able to boot in efi mode the grub on the live cd and then booted manually into linux.

So in the end I have a grub installed on my EFI system partition and I am able to boot into linux directly from EFI. Now I have seen, that the grub.cfg has two locations: /boot/grub/ and /boot/efi/EFI/grub/. On runing update-grub only the version in /boot/grub/ will be affected. For the (manual) installation this is not an issue but any kernel update will NOT alter the important /boot/efi/EFI/grub/grub.cfg. I tried creating a symlink but it seems that the file gets deleted before rewriting. So the link is lost.

So my questions in detail:

  • What have I to do to make the updates automatically? Should I mount -o bind the directory /boot/efi/EFI/grub to /boot/grub? Any better solutions?
  • Is it possible to make grub look into another position?
  • Where will an updated grub.efi be installed?
  • Are there other issues that I forgot so far?
share|improve this question
To convert Ubuntu BIOS installation to EFI see this Ubuntu Documentation. To convert Windows BIOS installation to EFI see this TechNet thread. – geezanansa May 30 '13 at 16:53
@ChristianWolf As you don't tell what exactly you have changed from the instructions as described on, its impossible to give a correct answer. Better describe the exact commands you have entered. – Pro Backup Aug 11 '14 at 10:43

The last I checked, Ubuntu's version of GRUB 2 places a GRUB binary on the EFI System Partition (ESP), which is mounted at /boot/efi in Linux. The GRUB configuration files (grub.cfg and various support files) remain in /boot/grub, which is on another partition. (IMO, this is a bad design, but that's another matter....) Thus, if you use Ubuntu's GRUB binary, GRUB's menu should be updated automatically.

If you installed GRUB from source code, or perhaps from somebody else's binary, though, it could work differently, with grub.cfg and its support files on the ESP along with the GRUB binary. This setup is actually safer, but Ubuntu's scripts don't support it, so you'd have to manually update things after every kernel update. From your description, you seem to have this setup, although the site to which you linked seems to describe setting it up using Ubuntu's binaries, which is a puzzling inconsistency. Did you try something else at some point, or deviate from the site's instructions to get it working? You could test by making a change to the description of a boot option in one of the grub.cfg files (assuming you've got two of them) and seeing if that change appears in GRUB's menu when you reboot.

Assuming you really do have a GRUB binary that looks on the ESP for its grub.cfg file, there are a number of possible solutions, including:

  • Install Ubuntu's version of GRUB over whatever you've got now. This is risky because it might not work, and could therefore leave you with an unbootable installation. (Your initial description says that your initial installation in EFI mode was unbootable, which suggests you might have a problem with Ubuntu's version of GRUB.)
  • Switch from GRUB to another boot manager/boot loader as your primary boot program. My own rEFInd is likely to be easy to get running, and it will handle kernel updates automatically. There's some risk of creating an unbootable installation if you try this, but the risk is less than that of replacing your working GRUB with another one, since you should be able to use your firmware's boot manager to boot via GRUB even if the new boot program fails completely.

One more comment: New computers invariably ship with Secure Boot active, which creates an extra hurdle to overcome. Ubuntu 12.10 and later come with Secure Boot support, but that doesn't always work. Most third-party boot loaders, including rEFInd, require extra work to get working with Secure Boot. Thus, if you haven't already done so, I recommend you disable Secure Boot in your firmware. If you want to boot with Secure Boot active, it's better to enable it after installing your boot loader, since you'll be able to test the boot loader without Secure Boot first, and then add Secure Boot to the picture and debug it with the knowledge that your basic boot loader configuration is working.

share|improve this answer
I can confirm that in 14.04 Ubuntu's GRUB 2 (=v1.99) places a GRUB binary in /boot/efi alongside with a 3 line grub.cfg that tells that its configfile is at ($root)'/boot/grub/grub.cfg. – Pro Backup Aug 11 '14 at 10:20
up vote 1 down vote accepted

If grub has no configuration in the EFI partition it seems to look under /boot/grub.

boot-repair crashed my EFI partition. I was no more able to boot any of the EFI boot options. Unfortunately I have no clue what exactly did result in the crash so I cannot file a bug.

As I crashed my whole EFI setup, I had to reinstall Windows and Ubuntu once to get all running, but now it seems that all is set up correctly.

share|improve this answer
Taking note of the given http//******* URL would have provided information that would be useful. Doing this would give you access to the famous Boot-Info-Script. You could also have checked the Boot-Repair settings of the recommended repair to get feedback regarding what Boot-Repair was going to do before applying the recommended repair with the opportunity to change them. – geezanansa May 30 '13 at 17:02
Losing EFI partition or if the files that were in EFS partition get corrupted would cause all OS's using that partition to not be able to boot. The OS's do not disappear as only the files that point bootmanager to bootloader are missing. All you had to do was recreate EFS partition if needed and reinstall bootloaders. Which is a lot easier to do than starting from scratch spending several hours watching progress bars. – geezanansa Aug 10 '13 at 23:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.