Placing grub.cfg in /boot/efi causes avoidable problems on EFI-based systems

[Rod Smith]

On an EFI-based computer, the GRUB binary (grubx64.efi) will normally reside on the EFI System Partition (ESP); however, this binary relies on a configuration file (grub.cfg) that resides in Ubuntu's /boot/grub directory. This split is a result of history -- on BIOS-based computers, there is no ESP or close equivalent, so placing grub.cfg in a Linux directory is perfectly reasonable. Under EFI, though, this arrangement creates two points of failure rather than one -- that is, if EITHER the ESP OR the /boot/grub directory is inaccessible, GRUB will fail. The result is that there are real-world scenarios in which problems occur because /boot/grub becomes unavailable at boot time. These include:

* USB installs -- If a user installs Ubuntu to a USB drive, Ubiquity normally uses the ESP on the hard disk and /boot/grub goes on the USB drive. Thus, if the user unplugs the USB drive and reboots, the user sees an unhelpful (and useless) GRUB command prompt. As such configurations normally dual-boot with Windows or OS X on the internal disk, this is an awkward (and sometimes panic-inducing) situation.
* Ubuntu uninstallations -- If the user attempts to uninstall Ubuntu by deleting the Ubuntu partition(s), GRUB will remain behind, but it will produce that unhelpful GRUB command line. As with the preceding condition, this one is likely to occur in a (former) dual-boot scenario.
* Disk swaps -- Advanced users sometimes try to temporarily unplug disks for various purposes. If Ubuntu is on a separate physical disk from the ESP and the user unplugs the Ubuntu disk, then the GRUB command prompt will appear when the system is booted.
* Filesystem damage -- If the Ubuntu partition suffers serious filesystem damage, the same GRUB command line prompt will result. This scenario might or might not occur in a dual-boot scenario, and when single-booting, the system would be unbootable, so it's not clear that the placement of grub.cfg is important; but in a dual-boot scenario, it would be better to be able to boot to the alternative OS.

I've seen questions related to this problem on several Web forums; for instance:

* http://askubuntu.com/questions/633504/uefi-boot-order-depending-if-usb-stick-is-plugged
* http://askubuntu.com/questions/664677/i-deleted-my-ubuntu-partition-win8-dual-boot-without-first-resetting-my-uefi-b

There are many more such examples, but finding them is tricky because relevant keywords are too common.

Of course, many computers provide their own boot managers that enable recovery from these problems when dual-booting -- the user can select the alternative OS in the firmware's own boot manager. Unfortunately, many users don't understand this fact or know how to use their boot managers. A few computers lack such boot managers, or they're so awkward that they're virtually useless. Thus, Ubuntu's placement of grub.cfg causes confusion and frustration for many users.

Two solutions to this problem occur to me:

* Install grub.cfg to the ESP -- If the configuration file were to reside on the ESP, presumably in the same directory as grubx64.efi, then these problems would disappear. This would create a difference in grub.cfg location between EFI and BIOS installations, which would presumably require a set of changes to GRUB's setup scripts. Fedora and Red Hat use this approach.
* Mount the ESP at /boot -- In this case, GRUB's binary would be in the ESP's "EFI/ubuntu" directory and its configuration file would go in "grub" on the ESP. The Linux kernels and initrd files would also reside in the ESP. This approach is what's advocated by the FreeDesktop.org Boot Loader Specification (https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/). Unfortunately, it has several problems, such as the fact that the available ESP on many systems pre-installed with Windows is too small for Ubuntu's /boot partition (often ~100 MB), and the fact that some kernel updates in Ubuntu seem to rely on symbolic links. Thus, this isn't really a viable solution in most cases, although it might be for some, especially if kernel updates could be made to never rely on symbolic links.

Overall, I think that moving grub.cfg from /boot/grub to the ESP is the best solution to this problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ben Creasy (jcrben)]

Related: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1571354 ("(This specific issue is a subset of bug #1567534.)"

And of course https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/704763 makes it a pain to install to a USB anyhow.