Arch boot process (简体中文)

From ArchWiki
Jump to: navigation, search
翻译状态: 本文是英文页面 Arch_Boot_Process翻译,最后翻译时间:2014-10-25,点击这里可以查看翻译后英文页面的改动。

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

固件种类

BIOS

所谓 BIOS 或 Basic Input-Output System, 就是开机时第一个被执行的程序,又名固件。一般来说它储存在主板上的一块闪存中,与硬盘彼此独立。BIOS 被启动后,它接着会执行第一个硬盘上的前 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。

UEFI 下每一个程序,无论它是某个 OS 引导器还是某个内存测试或数据恢复的工具,都要兼容于 EFI 固件位数或体系结构。目前主流的 UEFI 固件,包括近期的 Apple Macs,都采用了 x86_64 EFI 固件。目前还在用 IA32 即 32 位的 EFI 的已知设备只有于 2008 年前生产的 Apple Macs,一些 Intel Cloverfield 超级本和采用 EFI 1.10 固件的 Intel 服务器主板。

不像 x86_64 Linux 和 Windows 操作系统,x86_64 EFI 不能兼容 32 位 EFI 程序。所以 UEFI 应用程序必须依固件处理器位数/体系结构编译而成。

引导过程

BIOS

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

UEFI

参见 UEFI 引导过程

内核

内核是操作系统的核心。它运行于一个叫「内核空间」的底层上,负责机器硬件和应用程序之间的交流。为了尽可能充分地压榨 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, 即为用户启动一个「会话」,接着根据 /etc/passwd 文件启动用户专用 shell。此外,getty 也可能会改启动一个显示管理器。

显示管理器

如果事先装了某个 显示管理器, 它会代替原来的 getty 登录命令行提示符而启动。如果没有显示管理器,getty 只会显示向用户请求用户名和密码以登录的若干命令行,以准备调用 login.

Login

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

Shell

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

xinit

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


参见