Linux 启动与系统初始化：从开机到用户空间

你按下电源键，几十秒后看到登录提示符。这中间发生的事，对大多数人是个黑盒——机器"就这么启动了"。但作为后端或运维，迟早会遇到这些场景：服务器重启后某个服务没起来、容器一启动就退出、机器卡在某个启动阶段进不了系统、改了内核参数后开不了机。这些问题的排查，全都要求你知道开机到底分了哪几个阶段、每个阶段谁在干活、在哪一步交的棒。

这一篇我们就把这条链路一段段拆开。核心是讲清一个接力交棒的过程：固件 → 引导程序 → 内核 → 第一个用户空间进程，每一棒做什么、为什么需要这一棒、棒是怎么交到下一个手里的。看清这条链路，你对整台机器"怎么活起来"就有了完整的图景。

我们顺着通电那一刻往下走。

一、为什么开机需要"接力"，而不是一步到位

先回答一个根本问题：为什么不能上电就直接运行操作系统？因为这里有个先有鸡还是先有蛋的死结：

  • 操作系统内核存在磁盘上，要运行它得先把它从磁盘读进内存；
  • 但"从磁盘读数据"这件事本身，需要驱动、需要文件系统、需要一个正在运行的程序来执行——而这些恰恰是操作系统才提供的。

怎么破这个循环？答案是分阶段接力，每一棒只做"能把下一棒拉起来"的最小工作，能力逐级增强：

启动的本质，是一个**自举（bootstrap）**过程——用一段极小、极简、写死在固件里的代码，去加载一个稍大一点、能力稍强的程序，后者再去加载更完整的内核，内核最后拉起整个用户空间。每一棒都比前一棒更强大，像火箭逐级点火。

理解了这个"自举"和"逐级增强"的思想，下面四个阶段就不再是死记硬背的流程，而是一条有内在逻辑的链条。

二、第一棒：固件（BIOS / UEFI）——上电自检与找到引导程序

通电后第一个运行的不是任何磁盘上的软件，而是固化在主板芯片里的固件。老式的叫 BIOS，现代的叫 UEFI。它干两件事：

  1. POST（上电自检）：检查 CPU、内存、关键硬件是否正常。这就是你偶尔听到的"滴"一声或屏幕上一闪而过的硬件信息。如果内存坏了，往往卡在这一步、连引导都到不了；
  2. 找到并加载引导程序：固件按预设的启动顺序（硬盘、U 盘、网络等）去找一个可引导设备，把它上面的引导程序读进内存并交出控制权。

这里 BIOS 和 UEFI 的机制有重要区别：

  • 传统 BIOS：读取磁盘第一个扇区（512 字节）的 MBR（主引导记录），里面有一小段引导代码和分区表。512 字节装不下完整引导程序，所以它只是"引导程序的引导程序"，再去加载真正的引导程序；
  • UEFI：更现代，能识别文件系统（FAT 格式的 ESP，EFI 系统分区），直接读取里面的 .efi 引导文件，不再受 512 字节限制，还支持安全启动（Secure Boot）等特性。

固件这一棒的关键约束是"它什么都不太懂"——不懂你的文件系统、不懂你的操作系统，它只会做硬件自检，并按规则去固定位置加载下一棒。所以它的代码必须极简、写死在芯片里。

三、第二棒：引导程序（Bootloader，如 GRUB）——把内核装进内存

固件加载的引导程序，在 Linux 世界里最常见的是 GRUB。它的核心任务是：把内核映像从磁盘加载进内存，准备好参数，然后跳进内核。 具体做几件事：

  1. 提供启动菜单：你看到的"选择内核版本/操作系统"的界面就是 GRUB。多系统、多内核版本的选择在这里发生；
  2. 加载内核映像：从磁盘（通常是 /boot 目录）把内核文件（vmlinuz）读进内存。GRUB 比固件强，它认识文件系统，能按路径找到内核文件；
  3. 加载 initramfs：同时把一个临时的初始内存文件系统（initramfs / initrd）也加载进内存——这个东西后面单独讲，它解决了又一个"鸡生蛋"问题；
  4. 传递内核参数：把命令行参数（如 root= 指定根文件系统在哪、ro 只读挂载等）交给内核；
  5. 跳转执行内核：交棒，控制权移交给内核。

引导程序是"固件"和"内核"之间的桥梁：固件太弱（不认文件系统），内核太大（没法被固件直接定位加载），所以需要一个中间棒——它认识文件系统、能找到并加载内核、还能让用户选择启动项。

如果 GRUB 配置错了（比如 root= 指向了错误的设备），机器就会卡在引导阶段进不去系统——这是运维改分区、换磁盘后常见的翻车点。

四、第三棒：内核初始化——把"运行环境"搭起来

内核拿到控制权后，要把自己从一个静态的磁盘映像，变成一个真正在管理硬件的运行中系统。它做的事大致是：

  1. 解压自身：vmlinuz 是压缩的，内核先把自己解压到内存；
  2. 建立核心子系统：初始化内存管理（建立页表、管理物理内存）、中断系统（设置中断向量表，这正是上一篇讲的）、调度器、检测并初始化 CPU；
  3. 挂载 initramfs 作为临时根文件系统：内核先用 GRUB 加载进来的 initramfs 当作一个临时的根，在里面运行一些初始化脚本和驱动；
  4. 加载真正根文件系统所需的驱动：从 initramfs 里加载磁盘控制器、文件系统等驱动；
  5. 挂载真正的根文件系统：用 root= 参数指定的真实磁盘分区，挂载为根 /；
  6. 启动第一个用户空间进程：内核创建 PID 1 进程（传统是 init，现代是 systemd），然后内核退居幕后，从此只通过系统调用为用户空间服务。

这里要单独解释 initramfs 为什么必须存在，它是个精巧的设计：

内核要挂载真正的根文件系统，得先有能读那个磁盘/那种文件系统的驱动。但驱动种类太多（各种磁盘控制器、各种文件系统、加密盘、LVM、网络盘……），全编进内核会让内核臃肿不堪；可不编进去，又没法读盘加载驱动——又一个鸡生蛋。initramfs 就是答案：它是一个被 GRUB 直接塞进内存的临时小文件系统，里面备齐了"挂载真正根分区所需的驱动和脚本"，内核先用它把环境凑齐，再切换到真正的根。

五、第四棒：systemd（PID 1）——拉起整个用户空间

内核启动的第一个用户空间进程是 PID 1，现代 Linux 几乎都是 systemd。它是所有其他进程的祖先，负责把整个用户空间的服务体系拉起来。传统的 init（SysV）是串行按编号脚本一个个启动服务，而 systemd 的核心改进是：

  • 并行启动：通过分析服务之间的依赖关系，把没有依赖关系的服务并行拉起，大幅缩短启动时间；
  • 按需 / 依赖驱动：用 unit（服务单元）描述每个服务，用 target（如 multi-user.target、graphical.target）描述系统要达到的状态，systemd 负责把依赖满足、按需启动；
  • socket 激活：服务可以等到真正有请求来了才启动，进一步省资源；
  • 统一管理：服务的启动、停止、日志（journald）、监控、自动重启都归 systemd 管。

整条链路用一张图收束：

flowchart TD A["通电"] --> B["固件 BIOS/UEFI<br/>POST自检 + 找引导程序"] B --> C["引导程序 GRUB<br/>加载内核 + initramfs<br/>传参数"] C --> D["内核初始化<br/>内存/中断/调度/驱动<br/>挂载根文件系统"] D --> E["PID 1 = systemd<br/>并行拉起用户空间服务"] E --> F["登录提示符<br/>系统可用"]

这张图就是开机的完整骨架：每一个方框是一棒，箭头是交棒。 能力从"只会硬件自检"逐级增强到"管理整个系统服务体系"。当你定位启动问题时，第一件事就是判断"卡在哪一棒"——是固件级（硬件/自检）、引导级（GRUB/root 参数）、内核级（驱动/根文件系统挂载），还是用户空间级（某个 systemd 服务起不来）。

六、为什么要这样设计：分阶段是为了破解"自举"难题并控制复杂度

机制讲透，回答"为什么"。为什么非要分这么多阶段、搞得这么复杂？

  • 破解自举死结：如前所述，"运行系统需要先加载系统"是个循环。分阶段、能力逐级增强，是打破这个循环的唯一办法——用最简单的固件拉起稍复杂的引导程序，再拉起完整内核；
  • 关注点分离 + 灵活性：每一棒只负责一段，职责清晰。固件不需要懂操作系统、GRUB 不需要懂业务服务，所以同一套固件能引导 Linux/Windows，同一个 GRUB 能管理多个内核版本，同一个内核能配不同的 initramfs 适配不同硬件；
  • 控制内核体积：initramfs 的设计让内核不必把所有驱动都编进去，保持精简，又能适配千变万化的硬件环境；
  • 可靠与可恢复：分阶段让故障可定位、可恢复——进不了系统时还能进 GRUB 救援、还能用 initramfs 里的紧急 shell 修复。

一句话：启动流程的复杂，是为了用"逐级接力、关注点分离"的方式，优雅地解决"系统如何把自己拉起来"这个根本性的鸡生蛋问题。

七、和后端 / SRE 实践的联系

这条链路是运维和后端排障的硬功夫：

  • 定位"开不了机"卡在哪一步：黑屏没反应多半固件/硬件级；卡在 GRUB 或报 kernel panic - not syncing: VFS: Unable to mount root fs 是根文件系统挂载失败（root= 错、缺驱动、initramfs 损坏）；进了系统但服务没起，是 systemd 级；
  • systemctl 与 journalctl 是日常工具：systemctl status xxx 看服务为什么没起、systemctl list-dependencies 看依赖、journalctl -b 看本次启动日志、systemd-analyze blame 看哪个服务拖慢了启动；
  • 服务依赖与开机自启：写 systemd unit 时配 After=/Requires= 声明依赖，正是利用 systemd 的依赖驱动机制保证服务按正确顺序拉起。很多"部署后服务没起"其实是依赖链（如数据库还没好应用就启动了）没配对；
  • 容器启动是这条链路的极简版：容器没有固件、没有 GRUB、共享宿主内核，它直接从"PID 1"开始——容器里的 ENTRYPOINT 进程就是容器的 PID 1。理解了 PID 1 的特殊地位（要负责回收僵尸进程、处理信号），你就明白为什么容器里 PID 1 进程退出容器就停、为什么有时需要 tini 这种 init 帮手；
  • 冷启动优化：无论是物理机还是云主机/容器，"分阶段初始化、把能并行的并行、把不必要的依赖去掉"都是缩短启动时间的通用思路。

八、动手做一个小实验：把你的启动过程可视化

不用重启，就能观察自己系统的启动结构：

1
2
3
4
5
6
7
8
9
10
11
# 看本次开机各阶段耗时（固件、引导、内核、用户空间）
systemd-analyze

# 看是哪些服务最拖慢启动
systemd-analyze blame | head -10

# 生成一张启动时序图（SVG），直观看到服务并行情况
systemd-analyze plot > boot.svg

# 看本次启动的完整内核+服务日志
journalctl -b | head -50

systemd-analyze 会明确把时间分成 firmware（固件）、loader（引导）、kernel（内核）、userspace（用户空间）几段——这正好对应本文的四棒。把这几个数字和上面那张流程图对上，启动流程就从抽象概念变成了你能量化、能观察的东西。再用 blame 看哪个服务慢，你会立刻理解 systemd "并行启动 + 依赖管理"的价值。

学习这一部分最容易踩的坑

1. 以为启动是"一个程序"完成的

启动是固件、引导程序、内核、用户空间四棒接力，每棒能力逐级增强。把它当成单一程序，就无法理解为什么故障会表现成完全不同的样子。

2. 搞不清 initramfs 为什么存在

initramfs 解决的是"挂载真正根文件系统需要驱动，但驱动又在根文件系统里"的鸡生蛋问题。它是被预装进内存的临时小根，专门用来把环境凑齐。

3. 以为看到登录界面 = 系统完全就绪

登录界面只代表用户空间起到了一定程度，后台可能还有服务在拉起或已经失败。systemctl is-system-running、systemctl --failed 才能看真实状态。

4. 忽视容器 PID 1 的特殊性

容器直接从 PID 1 起步，PID 1 要负责收僵尸进程、转发信号。用普通业务进程直接当 PID 1，可能导致僵尸进程堆积或信号处理异常，这是容器化常见坑。

总结

Linux 启动是一个"逐级接力、能力增强"的自举过程，核心要点：

  • 启动要破解"运行系统需先加载系统"的鸡生蛋死结，办法是分阶段接力，每棒只做拉起下一棒的最小工作；
  • 四棒依次是：固件（自检 + 找引导）→ 引导程序 GRUB（加载内核和 initramfs）→ 内核（建内存/中断/调度、挂根文件系统）→ systemd PID 1（并行拉起用户空间）；
  • initramfs 是预装进内存的临时根，破解"挂根文件系统需要驱动、驱动却在根里"的循环，同时让内核保持精简；
  • systemd 用依赖关系实现并行启动，远快于传统串行 init，并统一管理服务、日志、重启；
  • 容器是这条链路的极简版——无固件无引导、共享内核、直接从 PID 1 起步，所以 PID 1 的职责要特别注意；
  • 排障时第一步永远是判断"卡在哪一棒"，systemd-analyze、journalctl -b、systemctl --failed 是定位利器。

把这四棒和那张流程图刻进脑子，下次遇到开不了机或服务没起，你就能快速定位是哪一级出了问题，而不是对着黑屏干瞪眼。

参考资源：