💻1. grubx64.efi

ubuntu下不开启安全模式的引导程序

💻2. shimx64.efi

ubuntu下开启安全模式的引导程序，它提供了一种在激活安全启动的情况下在计算机上启动的方法。

💻3.MokManager.efi

是一个用于管理机器所有者密钥（MOK）的工具，这些密钥是Shim使用的安全启动密钥，使您可以在安全启动处于活动状态时启动所选的OS。如果计算机上的安全启动处于活动状态，则可能应该已安装MokManager并可以从GRUB访问它，以便在需要时可以启动所需的应急工具。如果您的计算机上的安全启动处于非活动状态或不受支持，则MokManager的重量很重-但重量不是很多，因此我不必为此担心太多。（在任何现成的Linux发行版中，您都会发现更多无用的东西，而且很少有人去挖掘所有这些文件以进行清理。

  • /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软件包更新进行更新。
  • EFI固件文件-更新固件可能需要将固件文件复制到ESP。这可以是手动过程，也可以是使用Linux fwupdate二进制文件和匹配的fwupx64.efiEFI二进制文件至少部分自动化的程序。（不过，我不是100％肯定后者需要将文件写入ESP。这是很新的东西，目前文档很少。）
  • 其他与EFI相关的工具- 可能需要将诸如rEFInd引导管理器和其他非标准EFI引导管理器之类的程序和工具安装到ESP。可能需要安装的工具数量巨大，但是其中大多数都是奇特的，因此受影响的系统数量很少。
  • 手动配置文件调整-如果要重新配置引导加载程序，则可能需要在ESP上读取其配置文件，对其进行编辑，然后将编辑后的文件保存回去。因此，仅检查配置就需要安装ESP（尽管它可以是只读安装）。
  • 系统信息工具-诸如引导信息脚本之类的工具在ESP上读取配置文件，以生成有关系统配置方式的报告。即使未安装ESP来执行工作，Boot Info Script也可能会安装ESP，但我对此并不是100％积极的。可能还有其他工具假定已经安装了ESP，如果不满足此假设，其功能将降低。

总而言之，OS本身或您可能想要或需要读取或写入ESP的原因有很多。也就是说，这些原因数量很少，因此暂时安装ESP然后在完成后卸载ESP的机制可能是有益的。可以肯定地说，例如Debian软件包安装脚本可以完成此任务，就像修改ESP上的配置文件的自动化工具一样。但是，AFAIK尚未改变ESP的安装状态。

请注意，默认情况下，ESP装载时具有相当严格的权限。最近（也许从15.10或16.04开始-我不确定确切的时间），安装权限已更改，因此只能root从读取/boot/efi。即使在此之前，也只能root写入ESP，尽管读取权限比较宽松。由于root可以挂载分区，因此此时卸载ESP具有最小的安全性好处，尽管这样做的好处是，由于错误，断电等原因，ESP损坏文件系统的风险较小。