9

In Ubuntu and several other distros the EFI partition is mounted at /boot/efi.

As I understand the EFI partition is read before the OS rootfs (/). So after the kernel has loaded and mounted /, what do we still need the EFI partition for? In theory after the initial installation you don't need access to /boot/efi anymore, as it just contains the .efi binary...

So why is it mounted? It seems automounting a partition with sensitive files you don't access very often isn't a very smart thing to do from a design perspective...


EDIT:

Some recent systems may include the grub.cfg on their efi partion. See this bug report, though this is not the case for my 16.04LTS. So for systems with the config file on the ESP it makes more sense to mount it. Yet how often do people need to run update-grub, and couldn't the script mount it then and umount it again after updating?

9

There are several reasons the ESP that may need to be accessed in a variety of circumstances:

  • /boot/efi/EFI/ubuntu/grubx64.efi -- This is the EFI GRUB 2 binary, which must be replaced if the GRUB package is updated.
  • /boot/efi/EFI/ubuntu/grub.cfg -- This is a GRUB configuration file that does very little; mainly it loads /boot/grub/grub.cfg. This redirection is done to enable a "hook" for Secure Boot systems; without Secure Boot, the grubx64.efi binary can be built locally and points directly at /boot/grub/grub.cfg; but as the location of /boot/grub/grub.cfg varies (as seen by the ESP) from one system to another, putting a grub.cfg file on the ESP is necessary for Secure Boot, which doesn't permit grubx64.efi to be built locally. IMHO, it would make more sense to put the main grub.cfg and other GRUB support files on the ESP, but the developers in charge of this have opted for a more conservative approach, relative to what a BIOS-based system does. In any event, the grub.cfg on the ESP will rarely, if ever, be updated; but that might be necessary at some point, particularly if the GRUB Debian package is updated.
  • /boot/efi/EFI/ubuntu/shimx64.efi -- This is the Shim binary, which is required for Secure Boot to function. Like the GRUB 2 binary, it might be updated by a Debian package update, but of the shim-signed package.
  • /boot/efi/EFI/ubuntu/MokManager.efi -- This is the MokManager binary, which is a Shim support tool. Like Shim, it might be updated in a package update.
  • /boot/efi/EFI/ubuntu/fwupx64.efi -- This is a tool to assist in automating the update of firmware on an EFI-based computer. As with the preceding EFI binaries, it might be updated by a Debian package update.
  • EFI firmware files -- Updating the firmware is likely to necessitate copying firmware files to the ESP. This could be a manual process or something that's at least partially automated using the Linux fwupdate binary and matching fwupx64.efi EFI binary. (I'm not 100% positive that the latter requires writing files to the ESP, though. It's pretty new and has minimal documentation at this point.)
  • Other EFI-related tools -- Programs like my rEFInd boot manager and other non-standard EFI boot managers and tools might need to be installed to the ESP. The sheer number of tools that might need to be installed is significant, but most of them are exotic, so the number of systems impacted is small.
  • Manual configuration file adjustments -- If you want to reconfigure a boot loader, you may need to read its configuration file on the ESP, edit it, and save the edited file back out. For that matter, simply examining the configuration requires that the ESP be mounted (although it could be a read-only mount).
  • System information tools -- Tools like the Boot Info Script read configuration files on the ESP in order to generate a report on how the system is configured. The Boot Info Script probably mounts the ESP even if it's unmounted to do its work, but I'm not 100% positive of that. There may be other tools that assume the ESP is already mounted, and their functionality would be degraded if this assumption was not met.

In sum, there are quite a few reasons that the OS itself or you might want or need to read from or write to the ESP. That said, these reasons are few enough in number that a mechanism to temporarily mount the ESP and to then unmount it when done might be beneficial. Certainly a Debian package installation script could do the job, for instance, as could automated tools that modify configuration files on the ESP. AFAIK, though, changing the mount status of the ESP is not on the horizon.

Note that the ESP is mounted with fairly restrictive permissions by default. Recently (starting with 15.10 or 16.04, perhaps -- I'm not sure exactly when), mount permissions were changed so that only root can read from /boot/efi. Even before then, only root could write to the ESP, although read permissions were looser. Since root can mount partitions, there's minimal security benefit to leaving the ESP unmounted at this point, although there would be a benefit in that there'd be less risk of filesystem damage to the ESP because of a bug, power failure, etc.

  • Is it just coincidence that multiple distros have this mounting policy? Or could it be related to POSIX or some other standard? All Debian+ derivatives, Arch+derivs, OpenSUSE. Maybe Fedora... – jiggunjer Feb 10 '17 at 3:28
  • On a stock 17.04 install I don't have any restriction around /boot/efi (above answer mentions only root-accessible; not the case for me; furthermore the mount is rw): fstabentry: UUID=1234-5678 /boot/efi vfat defaults 0 1 – sxc731 May 20 '17 at 8:25
2

You are right: there is no need to mount the ESP at /boot/efi in the default setup (aka with grub 2)

update-grub updates grub.cfg that lies in /boot/grub so the configuration of grub is updated without problem if the ESP is not mounted.

I had it not mounted for a couple of years on my previous install without problem.

You can gain some micro-second during the boot by not mounting it if you wish ;-)

  • It seems like stupid design to me. Deleting it by accident = losing all bootloaders. The openSuse installer actively warns me if I don't add it to the fstab, but unmounting it hasn't caused a nuclear meltdown so far. – jiggunjer Feb 7 '17 at 13:52
  • 1
    You can't delete system files by an accident. There are lots of other file that can ruin your system. And this can be easily restored anyway. – Pilot6 Feb 7 '17 at 14:05
  • 1
    @Pilot6 1)you can. 2) irrelevant. 3)depends on how how the system was configured. – jiggunjer Feb 7 '17 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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