Arch 启动过程

出自 ArchWiki
（重定向自 启动引导程序）

相关文章

为了启动 Arch Linux，必须设置一个支持 Linux 的启动引导程序。启动引导程序负责加载内核和 初始内存盘，然后再启动引导过程。对于 BIOS 和 UEFI 系统，此过程截然不同。 本页面或链接页面上提供了详细描述。

固件类型

固件是系统启动后执行的第一个程序。

提示： BIOS 和 UEFI 这两个词通常用来代替固件。

UEFI

统一可扩展固件接口 支持读取分区表和文件系统。UEFI 不会从 主引导记录 (MBR) 启动任何引导代码，无论 MBR 是否存在，而是依赖于 NVRAM 中的引导项进行引导。

UEFI 规范强制要求支持 FAT12、FAT16 和 FAT32 文件系统（参见 UEFI 规范版本 2.10，第 13.3.1.1 节），但任何符合规范的供应商都可以选择添加对其他文件系统的支持；例如，某些 Apple 固件中的 HFS+ 或 APFS。 UEFI 实现还支持用于光盘的 ISO 9660。

UEFI 启动 EFI 应用程序，例如 启动引导程序、启动管理器、UEFI shell 等。这些应用程序通常作为文件存储在 EFI 系统分区中。每个供应商都可以将其文件存储在 EFI 系统分区下的 /EFI/vendor_name 目录中。可以通过向 NVRAM 添加引导项或从 UEFI shell 启动应用程序。

UEFI 规范支持使用其 兼容性支持模块 (CSM) 进行传统的 BIOS 启动。 如果在 UEFI 中启用了 CSM，UEFI 将为所有驱动器生成 CSM 引导项。 如果选择从 CSM 引导项启动，UEFI 的 CSM 将尝试从驱动器的 MBR 引导代码启动。

注意： 英特尔正在逐步淘汰对 CSM 的支持，未来依赖此功能可能不可行。[1]

BIOS

BIOS 或基本输入/输出系统在大多数情况下存储在主板本身的闪存中，并且独立于系统存储。最初为 IBM PC 创建，用于处理硬件初始化和启动过程，自 2010 年以来已逐步被 UEFI 取代，UEFI 不受相同的技术限制。

系统初始化

系统开启后，执行 加电自检 (POST)。另请参阅 Hugo Landau 的 现代 CPU 的幕后人员。

UEFI

  1. POST 之后，UEFI 初始化启动所需的硬件（磁盘、键盘控制器等）。
  2. 固件读取 NVRAM 中的引导项，以确定要启动哪个 EFI 应用程序以及从何处启动（例如，从哪个磁盘和分区）。
    • 引导项可以只是一个磁盘。 在这种情况下，固件在该磁盘上查找 EFI 系统分区，并尝试在回退引导路径 \EFI\BOOT\BOOTx64.EFI（具有 IA32 (32 位) UEFI 的系统上的 BOOTIA32.EFI）中查找 EFI 应用程序。 这就是 UEFI 可启动可移动媒体的工作方式。
  3. 固件启动 EFI 应用程序。

如果启用了 安全启动，则引导过程将验证 EFI 二进制文件的签名真实性。

注意： 某些 UEFI 系统只能从回退引导路径启动。

多重启动

由于每个操作系统或供应商都可以在 EFI 系统分区中维护自己的文件，而不会影响其他操作系统或供应商，因此使用 UEFI 进行多重启动只是启动与特定操作系统启动引导程序相对应的不同 EFI 应用程序的问题。 这消除了依赖一个 启动引导程序 的 链式加载机制来加载另一个操作系统的需要。

另请参阅 与 Windows 双启动。

BIOS

  1. POST 之后，BIOS 初始化启动所需的硬件（磁盘、键盘控制器等）。
  2. BIOS 启动 BIOS 磁盘顺序中第一个磁盘的前 440 字节（主引导记录引导代码区域）。
  3. MBR 引导代码中的启动引导程序的第一阶段随后从以下位置启动其第二阶段代码（如果有）：
    • MBR 之后的下一个磁盘扇区，即所谓的 MBR 后间隙（仅在 MBR 分区表上），
    • 分区或无分区磁盘 卷引导记录 (VBR)，
    • 对于 GPT 分区磁盘上的 GRUB — GRUB 特定的 BIOS 启动分区（它用于代替 GPT 中不存在的 MBR 后间隙）。
  4. 实际的 启动引导程序 已启动。
  5. 然后，启动引导程序通过链式加载或直接加载操作系统内核来加载操作系统。

启动引导程序

启动引导程序是由固件（BIOS 或 UEFI）启动的一段软件。 它负责加载内核以及所需的内核参数和任何外部 initramfs 映像。 在 UEFI 的情况下，内核本身可以使用 EFI 启动存根直接由 UEFI 启动。 仍然可以使用单独的启动引导程序或启动管理器，以便在启动前编辑内核参数。 具有 32 位 IA32 UEFI 的系统需要支持混合模式启动的启动引导程序。

警告： 为了成功启动 Arch，启动引导程序需要访问内核和 initramfs 映像，这些映像通常位于 /boot 目录中。 这意味着启动引导程序必须支持从块设备、堆叠块设备（LVM、RAID、dm-crypt、LUKS 等）到内核和 initramfs 映像所在的文件系统的一切。

由于几乎没有启动引导程序支持此类堆叠块设备，并且由于文件系统可能会引入任何启动引导程序可能尚不支持的新功能（例如，archlinux/packaging/packages/grub#7、FS#79857、FS#59047、FS#58137、FS#51879、FS#46856、FS#38750、FS#21733 和 fscrypt 加密目录），因此使用单独的 /boot 分区 和通用支持的文件系统（如 FAT32）通常更可行。

功能比较

注意
  • 由于 GPT 是 UEFI 规范的一部分，因此所有 UEFI 启动引导程序都支持 GPT 磁盘。 BIOS 系统上的 GPT 是可能的，可以使用带有 混合 MBR 的“混合启动”，或者新的 仅 GPT 协议。 但是，此协议可能会导致某些 BIOS 实现出现问题； 有关详细信息，请参阅 rodsbooks。
  • 由于 安全启动 是 UEFI 规范的一部分，因此所有 UEFI 启动引导程序都支持它，尽管有些启动引导程序存在限制。
名称 固件 分区表 多重启动 文件系统 注释
BIOS UEFI MBR GPT
Clover 是 是 否 是 是 可扩展2,5 可以在传统 BIOS 系统上模拟 UEFI。
EFI 启动存根 – 是1 是 是 – 从固件继承2 内核是一个有效的 EFI 可执行文件，可以直接从 UEFI 或其他 UEFI 启动引导程序启动。
GRUB 是 是3 是 是 是 内置 支持 RAID、LUKS（但不包括 Argon2 PBKDF）和 LVM（但不包括精简配置卷）。 有关特定于设置的限制，请参阅 GRUB。
Limine 是 是3 是 是 是 有限
rEFInd 否 是 是 是 是4 可扩展2,5 支持自动检测内核和参数，无需显式配置，并支持快速启动 [2]。
Syslinux 是 部分1 是 是 部分的 有限 不支持某些文件系统特性。
只能访问它安装到的文件系统。
systemd-boot 否 是3 手动的 是 是4 可扩展的2,5 只能从其安装到的 ESP 或同一磁盘上的扩展启动加载器分区 (XBOOTLDR 分区) 启动二进制文件。
自动检测放置在 esp/EFI/Linux/ 中的统一内核镜像。
统一内核镜像 – 是3 是 是 – 从固件继承2 systemd-stub(7)，内核、initramfs 和内核命令行被打包到 EFI 可执行文件中，以便直接从 UEFI 固件或其他引导加载程序加载。
GRUB Legacy 是 否 是 否 是 有限 已停止维护，转而支持 GRUB。
LILO 是 否 是 部分的 是 有限 已停止维护，原因是存在局限性（例如 Btrfs、GPT、RAID、加密）。
  1. 虽然二进制文件可以为 安全启动 签名，但它不进行后续验证，从而破坏了信任链。
  2. 文件系统支持继承自固件。UEFI 规范强制要求支持 FAT12、FAT16 和 FAT32 文件系统[3]，但供应商可以选择添加对其他文件系统的支持；例如，Apple Mac 中的固件支持 HFS+ 文件系统。如果固件提供用于在启动时加载 UEFI 驱动程序 的接口，则可以通过加载（独立获取的）文件系统驱动程序来添加对其他文件系统的支持。
  3. 支持混合模式启动。即，它可以在 32 位 IA32 UEFI 上启动 64 位 x86_64 Linux 内核。
  4. 启动管理器。它只能启动其他 EFI 应用程序，例如，使用 CONFIG_EFI_STUB=y 构建的 Linux 内核镜像和 Windows 启动管理器 (bootmgfw.efi)。
  5. 支持加载 UEFI 文件系统驱动程序。

另请参阅 Wikipedia:启动加载程序比较。

内核

引导加载程序启动包含内核的 vmlinux 镜像。

内核在低级别（内核空间）上运行，在机器硬件和程序之间进行交互。内核最初执行硬件枚举和初始化，然后继续进入用户空间。有关详细说明，请参阅 Wikipedia:内核 (操作系统) 和 Wikipedia:Linux 内核。

initramfs

initramfs（initial RAM file system）镜像是一个 cpio 存档。Initramfs 镜像可以使用 mkinitcpio、dracut 或 booster 生成，并且是 Arch 设置早期用户空间的首选方法。

/ 处的根文件系统最初是一个空的 rootfs，它是 tmpfs 或 ramfs 的一个特殊实例。这是临时根文件系统，initramfs 镜像将解压缩到此处。

initramfs 的目的是为早期用户空间提供必要的文件，以便成功启动后期用户空间。它不需要包含人们可能想要使用的每个内核模块；它应该只包含根设备（如 NVMe、SATA、SAS、eMMC 或 USB（如果从外部驱动器启动））和加密所需的模块。大多数模块将在稍后由 udev 在切换根目录到根文件系统期间，在 init 进程中加载。

  1. 首先，内核将其内置的 initramfs 解压缩到临时根目录。Arch Linux 的官方支持的内核对内置 initramfs 使用空存档，这是构建 Linux 时的默认设置。
  2. 然后，内核按照 引导加载程序 传递的命令行指定的顺序解压缩外部 initramfs 镜像，覆盖来自嵌入式 initramfs 或先前解压缩的任何文件。请注意，多个 initramfs 镜像可以组合在一个文件中，内核将按其在文件中的顺序处理它们。
    1. 如果第一个 initramfs 镜像未压缩，则在解压缩后，内核将分别在 /kernel/x86/microcode/ 和 /kernel/firmware/acpi/ 中查找 CPU 微码 更新和 ACPI 表更新。
    2. 在处理 CPU 微码和 ACPI 表更新后，内核将继续解压缩其余的 initramfs 镜像（如果有）。

此外，Linux 内核 固定了它启动的原始根目录。如果未使用 initramfs，则在关机期间，真实根文件系统可能最终无法干净地卸载。

早期用户空间

早期用户空间阶段，也称为initramfs 阶段，发生在 rootfs 中，rootfs 由 #initramfs 提供的文件组成。早期用户空间通过内核执行 /init 二进制文件作为 PID 1 开始。

早期用户空间的功能是可配置的，但其主要目的是引导系统到它可以访问根文件系统的程度。这包括：

请注意，早期用户空间的功能不仅仅是设置根文件系统。有些任务只能在挂载根文件系统之前执行，例如 fsck 和从休眠恢复。

在早期用户空间的最后阶段，真实根目录被挂载在 /sysroot/（在使用基于 systemd 的 initramfs 的情况下）或 /new_root/（在使用基于 busybox 的 initramfs 的情况下），然后在使用基于 systemd 的 initramfs 时使用 systemctl switch-root 或在使用基于 busybox 的 initramfs 时使用 switch_root(8) 切换到真实根目录。后期用户空间通过执行来自真实根文件系统的 init 程序开始。

后期用户空间

后期用户空间的启动由 init 进程执行。Arch 官方使用基于单元和服务概念构建的 systemd，但此处描述的功能在很大程度上与其他 init 系统重叠。

getty

init 进程为每个虚拟终端（通常为六个）调用一次 getty。getty 初始化每个终端并保护其免受未经授权的访问。当提供用户名和密码时，getty 会根据 /etc/passwd 和 /etc/shadow 检查它们，然后调用 login(1)。

Login

login 程序通过设置环境变量并根据 /etc/passwd 启动用户的 shell 来开始用户的会话。login 程序在成功登录后，在执行登录 shell 之前，显示 /etc/motd (message of the day) 的内容。这是一个显示服务条款以提醒用户本地策略或您希望告知他们的任何内容的好地方。

Shell

一旦用户的 shell 启动，它通常会运行一个运行时配置文件，例如 bashrc，然后在向用户显示提示符之前。如果帐户配置为在登录时启动 X，则运行时配置文件将调用 startx 或 xinit。跳转到 #图形会话 (Xorg) 以了解结尾。

显示管理器

本文节需要扩充。

原因： 本节仅描述了使用 Xorg 的过程，但未解释使用 Wayland 会发生什么。（在Talk:Arch boot process 中讨论）

此外，还可以将 init 配置为在特定的虚拟终端上启动显示管理器而不是 getty。这需要手动启用其 systemd 服务文件。然后，显示管理器启动图形会话。

图形会话 (Xorg)

xinit 运行用户的 xinitrc 运行时配置文件，该文件通常启动窗口管理器或桌面环境。当用户完成并退出时，xinit、startx、shell 和 login 将按该顺序终止，返回到 getty 或显示管理器。

另请参阅

摘自“https://wiki.archlinux.org.cn/index.php?title=Arch_boot_process&oldid=827594#Boot_loader”