/boot/找到一个易于理解的解释来解释什么是和/boot/efi/实际上是有点困难。
我通过测试和谷歌搜索找到了一些可能的答案，但如果有经验的人可以挑战或证实我的发现/思维方式，我会非常高兴。
语境：
- 主板中的兼容性支持模块 (CSM) 已关闭
- 主板中的快速启动和安全启动均已关闭
- 操作系统是Ubuntu Server 22.04
- 安装程序使用两个容量相同的磁盘（对于 RAID 1）
- 两个磁盘都是 GPT 格式，并且两个磁盘上的 EFI 系统分区都是分区号
1和大小512MB（1当然还有类型）。 /是使用创建的软件 RAID 1mdadm。- 更广泛地说：我正在做一些测试，以更好地了解软件 RAID 的工作原理以及将来如何处理可能的 RAID“错误”（例如交换有故障的磁盘、仅从其中一个磁盘启动等）。
我的发现（基于上述背景）/问题
1.) 观察：/boot不是 EFI 系统分区。即它不包含引导加载程序。
但是，它包含 GRUB 配置文件（/boot/grub/在我的例子中）。
我通过在两个磁盘上安装引导加载程序（带有 ubuntu 服务器安装程序）来测试这一点，然后对 grub 配置文件进行更改（/etc/default/grub添加intel_iommu=on为“虚拟”标志然后运行update-grub），关闭服务器并物理删除其驱动器当我进行更改时，EFI 分区已安装）。服务器已启动，但陷入“紧急”模式，因为操作系统找不到具有指定 EFI 分区的驱动器/etc/fstab（ubuntu 服务器安装程序使用我删除的驱动器的 UUID 添加了挂载点）。
然而cat /proc/cmdline 做过显示intel_iommu=on已指定。
这让我相信 grub 配置并不存储在 EFI 分区上，而是我安装系统时创建的软件 RAID 的一部分。
2.) 观察：/boot/efi是 EFI 系统分区的挂载点，它反过来可以访问已安装的引导加载程序。
至少其中一个驱动器需要安装引导加载程序（在此处安装的 EFI 系统分区上），否则系统将无法引导。
可以通过运行 来重新安装引导加载程序 (GRUB) grub-install /dev/sd{x}。
3.) [如果 1. 和 2. 确实为真]，问题：Ubuntu操作系统是否需要挂载EFI系统分区才能运行？
我可以省略里面的安装指令/etc/fstab吗？
这只是出于好奇而提出的问题。
答案1
是的，你可以省略 mount /boot/efi，但是......
您可以注释掉/etc/fstabEFI 系统分区的行，系统仍然可以正常启动。
但除非您进行其他修改，否则对实际引导加载程序（不仅仅是其配置）的任何更新都将失败。换句话说，apt update grub-*一旦发布适用的更新就会导致错误。除非首先采取额外的步骤，否则运行grub-install重新安装 GRUB 也会失败。
实际上/boot/efi并不是为了以下目的而安装的启动操作系统：当Linux内核开始运行时，EFI系统分区已经完成了启动过程中它的部分。相反，安装它的主要目的是使引导加载程序可用于更新。第二个目的可能是让系统管理员可以轻松访问它揭秘 ESP， 并允许 ESP 像常规文件系统一样进行备份。
我认为某些发行版（也许是 Gentoo？）选择仅在引导加载程序或其配置实际更新时才安装 EFI 系统分区，类似于 Microsoft Windows 的处理方式。然而，大多数主要发行版选择像常规文件系统一样安装 ESP。
（你的观察#1和#2是完全正确的，并且不包含任何明显的问题；只有你的观点#3包含一个实际的问题，所以这就是我的回答。）
答案2
引导分区对于大多数用途来说已经过时了。它是像 lilo 这样的简约引导加载程序所需要的，它们不了解加密、LVM、各种文件系统和 RAID 等高级概念。所以解决办法就是把kernel和initrd放到一些lilo可以理解的简单分区上，让initrd里的脚本对Linux环境下的主存储进行复杂的初始化。大多数当前的 grub 设置都不需要它，因为 grub 更加智能，但是传统仍然存在。
然后ESP出现了，其动机基本相同：拥有一个简单的固件，不关心不同操作系统的高级功能，并且独立于它们。要实现这一点，您需要有一个标准化结构的简单分区，其中包含启动操作系统所需的一切。 ESP 可以被认为是一个现代的独立于操作系统的启动分区。
例如，您可以拥有 ESP 而无需专用引导。将内核、initramfs 和 bootloader 放入其中（因此它将是“组合启动和 ESP”），或者拥有带有内置 EFI 存根和 initramfs 的内核映像，在这种情况下，您只需将单个文件放在上面ESP（根本没有专用的引导加载程序）。我的笔记本电脑上有这样的设置已经很长时间了。
有一个警告：ESP 不能成为操作系统提供的软件 RAID 的一部分。 UEFI 规范没有提及软件 RAID。这可以被认为是上一段的结果，但是 lilo 更简单，能够处理它； Linux 的 RAID1 元数据在设备末尾附近有一个超级块，因此对于 lilo 来说，RAID1 启动分区看起来只是有一个比设备稍小的文件系统，并且没有什么可以阻止要求 UEFI 固件在规范中以相同的方式运行。 Microsoft 未能创建具有这种简单结构的 RAID1（哈，尝试创建他们的“软件 RAID”，您就会明白我的意思），因此更有可能的是，他们只是从规范中完全省略了软件 RAID。
使用软件 RAID1 进行冗余启动的常见方法是在两个不同的磁盘上拥有两个独立的 ESP，手动同步它们，并拥有两个固件启动记录（能够从每个启动记录）。此类设置的示例是安装到 ZFS 软件 RAID 上的 Proxmox VE；在这种情况下，它使用 systemd-boot EFI 引导加载程序（即不是 grub），并且有一个钩子脚本，每当更新一些与引导相关的内容时，该脚本就会同步 ESP。这是我所知道的唯一一个创建两个 ESP 的自动安装程序，也是唯一一个负责同步的发行版；在所有其他情况下，您必须进行手动分区，并且当您要依赖软件 RAID 时，您必须自己进行分区。请注意，这些 ESP 最好不要是彼此的映像，因此它们的 FAT UUID 会有所不同；我安装它们并复制文件。 ESP 的更新是非常稀有的。