Arch boot process (简体中文)

From ArchWiki
Jump to navigation Jump to search
翻译状态: 本文是英文页面 Arch boot process翻译,最后翻译时间:2017-09-01,点击这里可以查看翻译后英文页面的改动。

为了启动 Arch Linux,一个与 Linux 兼容的 启动引导器,比如 GRUB 或者 Syslinux 必须事先被安装到主引导记录或者 GUID 分区表。启动引导程序负责在初始化启动进程之前,加载好内核和 initial ramdisk。具体过程因 BIOSUEFI 系统而异,细节在正文中给出。

固件种类

BIOS

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: 需要增加关于 CSM的内容。 (Discuss in Talk:Arch boot process (简体中文)#)

所谓 BIOS 或 Basic Input-Output System, 就是开机时第一个被执行的程序,又名固件。一般来说它储存在主板上的一块闪存中,与硬盘彼此独立。

BIOS 被启动后,会按启动顺序加载磁盘的前 512 字节,即主引导记录,前 440 字节包含某个启动引导器,像 GRUBSyslinuxLILO 之类的第一启动阶段代码。因为空间太小了,后续的启动代码保存在磁盘上,最后启动引导器又通过「链式引导」,或是直接加载内核,以加载一个操作系统。

UEFI

UEFI 不仅能读取分区表,还能自动支持文件系统。所以它不像 BIOS,已经没有仅仅 440 字节可执行代码即 MBR 的限制了,它完全用不到 MBR。

UEFI 主流都支持 MBR 和 GPT 分区表。Apple-Intel Macs 上的 EFI 还支持 Apple 专用分区表。绝大部分 UEFI 固件支持软盘上的 FAT12,硬盘上的 FAT16、FAT32 文件系统,以及 CD/DVDs 的 IS09660 和 UDF。Intel Macs 的 EFI 还额外支持 HFS/HFS+ 文件系统。

不管第一块上有没有 MBR,UEFI 都不会执行它。相反,它依赖分区表上的一个特殊分区,叫 EFI 系统分区,里面有 UEFI 所要用到的一些文件。计算机供应商可以在 <EFI 系统分区>/EFI/<VENDOR NAME>/ 文件夹里放官方指定的文件,还能用固件或它的 shell,即 UEFI shell,来启动引导程序。EFI 系统分区一般被格式化成 FAT32,或比较非主流的 FAT16。

系统初始化

BIOS

  1. 开机时加电自检
  2. 加电自检后,BIOS 初始化一些必要的硬件以准备引导,比如硬盘和键盘等。
  3. BIOS 执行在「BIOS 硬盘顺序」中的第一块硬盘上的前 440 字节代码,即主引导记录
  4. MBR 接管后,执行它之后的第二阶段代码,如果后者存在的话,它一般就是启动引导器
  5. 第二阶段代码会读取它的支持文件和配置文件。

UEFI

  1. 系统开机 - 上电自检(Power On Self Test 或 POST)。
  2. UEFI 固件被加载,并由它初始化启动要用的硬件。
  3. 固件读取其引导管理器以确定从何处(比如,从哪个硬盘及分区)加载哪个 UEFI 应用。
  4. 固件按照引导管理器中的启动项目,加载UEFI 应用。
  5. 已启动的 UEFI 应用还可以启动其他应用(对应于 UEFI shell 或 rEFInd 之类的引导管理器的情况)或者启动内核及initramfs(对应于GRUB之类引导器的情况),这取决于 UEFI 应用的配置。
Note: 在有些 UEFI 系统中,唯一可行的启动时(如果应用没有在 UEFI 启动菜单定制条目的话)加载 UEFI 应用的方法是把它放在此固定位置:<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi (对于 64 位的 x86 系统)

UEFI 的多重引导

因为每个操作系统或者提供者都可以维护自己的 EFI 系统分区中的文件,同时不影响其他系统,所以 UEFI 的多重启动只是简单的运行不同的UEFI 程序,对应于特定操作系统的引导程序。这避免了依赖 chainloading 机制(通过一个启动引导程序加载另一个引导程序,来切换操作系统)。

参阅 Dual boot with Windows.

启动加载器

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: 需要补充解释启动加载器和启动管理器之间的区别 (Discuss in Talk:Arch boot process#Boot loader vs boot manager)

启动加载器是 BIOSUEFI 启动的第一个程序。它负责使用正确的内核参数加载内核, 并根据配置文件加载初始化 RAM disk


Note: 加载 Microcode 补丁要求对启动加载器的配置进行调整。[1]

功能比较

Note:
  • 只需要启动加载器兼容内核和initramfs所处的位置(/boot)的文件系统兼容即可。
  • 因为GPT是UEFI规范的一部分,所以所有的UEFI启动加载器都支持GPT磁盘。在BIOS上使用GPT磁盘是可行的,要么根据Hybrid MBR使用 "hybrid booting",要么使用新的 GPT-only 协议。但是这个协议可能在某些BIOS实现上出问题,参考 rodsbooks
  • 在文件系统支持中提到的“加密”是filesystem级别加密,和block级别加密没有任何关系。
Name Firmware Partition table Multi-boot File systems Notes
BIOS UEFI MBR GPT Btrfs ext4 ReiserFS VFAT XFS
EFISTUB Yes Yes Yes ESP only 内核会变成一个 EFI executable 来被 UEFI 固件或者其他启动加载器加载。
Clover 模拟 UEFI Yes Yes Yes Yes No 不支持加密 No Yes No 修改版的 rEFIt,用来运行黑苹果
GRUB Yes Yes Yes Yes Yes 不支持 zstd 压缩 Yes Yes Yes Yes 在 BIOS/GPT 配置下需要一个 BIOS启动分区
支持RAID, LUKS1 和 LVM (但是不支持thin provisioned volumes)。
rEFInd No Yes Yes Yes Yes 不支持加密和 zstd 压缩 不支持加密 不支持 tail-packing 功能 Yes No 支持自动寻找内核和确定内核参数而不需要手动配置。
Syslinux Yes 有限支持 Yes Yes 有限支持 不支持: 跨设备卷、压缩、加密 不支持加密 No Yes 仅限MBR;不支持 sparse inodes 不支持某些 文件系统 功能 [2]
启动加载器只能够访问它所处的文件系统。[3]
systemd-boot No Yes 仅限手动安装 Yes Yes No No No ESP only No ESP以外的分区上的binaries它都启动不了.
GRUB Legacy Yes No Yes No Yes No No Yes Yes v4 only 停止开发 in favor of GRUB.
LILO Yes No Yes No Yes No 不支持加密 Yes Yes Yes 停止开发 因为某些局限性 (e.g. with Btrfs, GPT, RAID).

See also Wikipedia:Comparison of boot loaders.

内核

内核是操作系统的核心。它运行于一个叫「内核空间」的底层上,负责机器硬件和应用程序之间的交流。为了尽可能充分地压榨 CPU 性能,内核使用调度器,通过一定的优先级算法将 CPU 按照时间动态的分配给各个程序。让我们感觉就像所有程序都在同时使用 CPU 一样。

initramfs

内核被加载后,它就会解压 mkinitcpio (简体中文), 又名 initial RAM filesystem, 后者会伪装成一个已初始化的根文件系统。内核接着会执行 /init 作为第一条进程。传说中的「用户空间」就这么被启动了。

initramfs 之所以存在,是为了帮系统访问真正的根文件系统(参见 Arch filesystem hierarchy (简体中文))。也就是说,那些硬件 IDE, SCSI, SATA, USB/FW 所要求的内核模块,如果并没有内置在内核里,就会被 initramfs 负责加载。一旦通过 udev (简体中文) 之类的程序或脚本加载好模块,启动流程才会继续下去。所以,initramfs 只要有能够让系统访问真实根文件系统的模块就可以了,不用尽可能地包含一切模块。当然,其它真正有用的模块之后会在 init 流程中被 udev 加载好。

Init 流程

在「早期用户空间」的最终环节里,真正的根文件系统被挂载好后,就会替换掉原来的根文件系统。接着 /sbin/init 被执行,同样也替换掉原来的 /init 进程。Arch 御用的 init 就是 systemd (简体中文).

Getty

init 为每一个 虚拟终端 调用 getty,前者一般有六个,每个虚拟终端都会初始化 tty 并请求输入用户名和密码。当在某虚拟终端输入用户名和密码后,其 getty 会通过 /etc/passwd 检查是否正确,如果正确,就接着调用 login, 此外 getty 也可能会改启动一个显示管理器。

显示管理器

显示管理器, 可以配置为代替原来的 getty 登录命令行提示符。

Login

所谓的 login 程序会为用户启动一个设置了环境变量的「会话」,接着根据 /etc/passwd 配置以启动用户专用 shell.

每日信息

login 程序会在成功登录后显示 /etc/motd (message of the day) 的内容,可以显示服务协议或希望告诉用户的信息。

Shell

一旦用户专用的 shell 启动了,它会在显示命令行提示符前,执行一个「有可执行性的配置文件」,比如 .bashrc. 如果用户有设定了 Start X at login, 原来那个「有可执行性的配置文件」会调用 startx or xinit.

xinit

xinit 也会调用用户的 .xinitrc这个「有可执行性的配置文件」,后者一般用来启动一个 窗口管理器。如果用户退出了窗口管理器,xinit, startx, shell login 就会先后中断,返回到 getty.

参见