在Ubuntu和其他发行版中，EFI分区安装在/boot/efi。
据我了解，EFI分区是在操作系统rootfs（/）之前读取的。因此，在内核加载和挂载之后/，我们仍然需要EFI分区做什么？理论上，在初始安装后，您不再需要访问/boot/efi，因为它仅包含.efi二进制文件...
那么为什么要安装呢？从设计的角度来看，用不经常访问的敏感文件自动挂载分区似乎不是一件很聪明的事情。
编辑：
一些最近的系统可能grub.cfg在其efi 部分上包括。请参阅此错误报告，尽管我的16.04LTS并非如此。因此，对于在ESP上具有config文件的系统而言，挂载它更有意义。但是人们需要多久运行一次update-grub，而脚本无法在安装后再运行并在更新后再次将其卸载？
Answers:
在多种情况下可能需要访问ESP的原因有几个：
/boot/efi/EFI/ubuntu/grubx64.efi -这是EFI GRUB 2二进制文件，如果更新了GRUB软件包，则必须将其替换。/boot/efi/EFI/ubuntu/grub.cfg-这是一个GRUB配置文件，只做很少的事；主要是加载/boot/grub/grub.cfg。进行此重定向是为了为安全启动系统启用“挂机”。如果没有安全启动，grubx64.efi二进制文件可以在本地构建并直接指向/boot/grub/grub.cfg; 但是随着/boot/grub/grub.cfg一个系统到另一个系统的位置变化（如ESP所见），grub.cfg为了安全启动，必须在ESP上放置一个文件，该文件不允许grubx64.efi在本地构建。恕我直言，将主grub.cfg文件和其他GRUB支持文件放在ESP上会更有意义，但是负责此工作的开发人员相对于基于BIOS的系统，选择了一种更为保守的方法。无论如何，grub.cfg在ESP上很少（如果有的话）进行更新；但是在某些时候这可能是必要的，特别是如果GRUB Debian软件包已更新。/boot/efi/EFI/ubuntu/shimx64.efi-这是Shim二进制文件，安全启动才能正常运行。像GRUB 2二进制文件一样，它可以通过Debian软件包更新（但对于软件包）进行更新shim-signed。/boot/efi/EFI/ubuntu/MokManager.efi-这是MokManager二进制文件，是Shim支持工具。与Shim一样，它可能会在软件包更新中进行更新。/boot/efi/EFI/ubuntu/fwupx64.efi-这是一个工具，可帮助在基于EFI的计算机上自动化固件更新。与前面的EFI二进制文件一样，它可以通过Debian软件包更新进行更新。fwupdate二进制文件和匹配的fwupx64.efiEFI二进制文件至少部分自动化的程序。（不过，我不是100％肯定后者需要将文件写入ESP。这是很新的东西，目前文档很少。）总而言之，OS本身或您可能想要或需要读取或写入ESP的原因有很多。也就是说，这些原因数量很少，因此暂时安装ESP然后在完成后卸载ESP的机制可能是有益的。可以肯定地说，例如Debian软件包安装脚本可以完成此任务，就像修改ESP上的配置文件的自动化工具一样。但是，AFAIK尚未改变ESP的安装状态。
请注意，默认情况下，ESP装载时具有相当严格的权限。最近（也许从15.10或16.04开始-我不确定确切的时间），安装权限已更改，因此只能root从读取/boot/efi。即使在此之前，也只能root写入ESP，尽管读取权限比较宽松。由于root可以挂载分区，因此此时卸载ESP具有最小的安全性好处，尽管这样做的好处是，由于错误，断电等原因，ESP损坏文件系统的风险较小。
/boot/efi（以上答案仅提及root用户可访问；对我而言不是这种情况；而且挂载是rw）：fstab条目：UUID=1234-5678 /boot/efi vfat defaults 0 1
没错，您无需/boot/efi在默认设置下安装ESP （也称为grub 2）
update-grub中存在的更新grub.cfg，/boot/grub因此，如果未安装ESP，则grub的配置将更新而不会出现问题。
在以前的安装中，我已经好几年没有安装它了，没有问题。
如果需要，您可以通过不安装它来在启动过程中获得一些微秒；-)
fstab，openSuse安装程序会主动警告我，但是到目前为止，卸载尚未引起核崩溃。