Arch 启动过程

出自 ArchWiki
（重定向自 Boot process）

相关文章

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

固件类型

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

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

UEFI

统一可扩展固件接口支持读取分区表和文件系统。UEFI 不会启动任何 来自主引导记录（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 取代，后者没有相同的技术限制。

系统初始化

系统开启后，将执行加电自检 (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，初始 RAM 文件系统）镜像是一个 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 程序通过设置环境变量并根据 /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”