[Bug 1567534] Re: Placing grub.cfg in /boot/efi causes avoidable problems on EFI-based systems
Launchpad Bug Tracker
1567534 at bugs.launchpad.net
Tue May 24 13:45:35 UTC 2016
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.
Placing grub.cfg in /boot/efi causes avoidable problems on EFI-based
Status in grub2 package in Ubuntu:
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.
* 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
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:
More information about the foundations-bugs