![EFI 系统分区、GRUB2 配置和软件 RAID 1](https://linux22.com/image/224248/EFI%20%E7%B3%BB%E7%BB%9F%E5%88%86%E5%8C%BA%E3%80%81GRUB2%20%E9%85%8D%E7%BD%AE%E5%92%8C%E8%BD%AF%E4%BB%B6%20RAID%201.png)
/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/fstab
EFI 系统分区的行,系统仍然可以正常启动。
但除非您进行其他修改,否则对实际引导加载程序(不仅仅是其配置)的任何更新都将失败。换句话说,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 的更新是非常稀有的。