[Bug 1567534] Re: Placing grub.cfg in /boot/efi causes avoidable problems on EFI-based systems

[Launchpad Bug Tracker]

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

** Changed in: grub2 (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1567534

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

Status in grub2 package in Ubuntu:
  Confirmed

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1567534/+subscriptions