Arch 启动过程

出自 ArchWiki
(重定向自 Initramfs)

相关条目

为了启动 Arch Linux，必须设置一个支持 Linux 的启动引导器。启动引导器负责加载内核和初始 ramdisk，然后启动引导过程。对于 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 的 Modern CPUs have a backstage cast。

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 加密目录），因此使用具有通用支持文件系统（如 FAT32）的单独 /boot 分区通常更可行。

功能比较

注意
  • 由于 GPT 是 UEFI 规范的一部分，因此所有 UEFI 启动引导器都支持 GPT 磁盘。BIOS 系统上的 GPT 是可能的，可以使用带有 Hybrid 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（如果从外部驱动器启动）和加密。大多数模块将在 init 进程期间，在切换根目录到根文件系统后由 udev 稍后加载。

  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#initramfs”