1.1 引导加载器的交付物#

当 GRUB2 或 systemd-boot 等引导加载器完成工作后，它向内核交付了以下”遗产”：

• 将 bzImage（大内核映像）加载到物理内存的合适位置（通常在 1MB 以上）
• 进入 64 位保护模式，启用分页
• 将内核命令行参数（BOOT_CMDLINE）放置在约定的内存位置
• 在 boot_params 结构（arch/x86/include/uapi/asm/bootparam.h）中填入硬件信息：E820 内存映射、VBE 显示模式、ACPI RSDP 地址等

1.2 startup_64：内核的第一条指令#

内核映像的入口点是 startup_64，定义在 arch/x86/kernel/head_64.S。此时 CPU 处于一个”半初始化”状态：64 位模式已启用，但内核自身的运行环境尚未建立。startup_64 的核心任务是：

1. 验证自身加载地址：检查是否被加载到正确的物理地址（CONFIG_PHYSICAL_START），若不是则需重定位
2. 建立临时页表：使用编译时生成的 init_top_pgt，建立内核映像的恒等映射（Identity Mapping）和内核文本映射
3. 启用 5 级分页（若硬件支持且内核配置了 CONFIG_X86_5LEVEL）：将页表从 4 级（PML4）切换到 5 级（PML5）
4. 跳转到 C 代码：设置好栈指针后，跳转到 extract_kernel 进行内核解压

1
// arch/x86/boot/compressed/head_64.S（简化）
2
SYM_CODE_START(startup_64)
3
    // 1. 检查是否需要重定位
4
    call    1f
5
1:  popq    %rbp
6
    subq    $1b, %rbp       // 计算实际加载偏移
7

8
    // 2. 设置栈
9
    leaq    boot_stack_end(%rbp), %rsp
10

11
    // 3. 调用内核解压
12
    call    extract_kernel
13
SYM_CODE_END(startup_64)

1.3 extract_kernel：解压与重定位#

extract_kernel 定义在 arch/x86/boot/compressed/misc.c，它负责：

1. 选择解压算法：根据编译时配置选择解压方法——GZIP、LZ4、LZMA、XZ 或 ZSTD
2. 计算安全的目标地址：在物理内存中找到一块足够大且不与当前映像重叠的区域
3. 执行解压：将压缩的内核数据解压到目标地址
4. 处理重定位：遍历内核映像中的 .reloc 段，修正所有绝对地址引用——因为内核实际加载地址可能与编译时假定的地址不同
5. 跳转到解压后的内核入口：即 startup_64 的”第二次执行”——这次在正确的地址上运行

2.1 关键初始化阶段详解#

以下是 start_kernel() 中最关键的几个初始化调用，按照它们在源码中的出现顺序排列：

阶段一：架构与内存（让内核”站稳脚跟”）

setup_arch() 是架构相关的初始化入口，在 x86 上它做了大量工作：解析 ACPI 表、建立 E820 内存映射、初始化 struct page 数组（memmap）、设置内核的 .text / .data / .bss 段映射。这些工作为后续所有子系统提供了内存分配和地址转换的基础——参见第 6 章：物理内存管理和第 7 章：虚拟内存与 VMA。

阶段二：调度与并发（让内核”能做事”）

sched_init() 标志着内核从”单线程执行”向”可调度”状态转变。在此之前，内核代码以同步方式顺序执行；在此之后，内核具备了创建和管理多个执行上下文的能力。但此时只有 init_task（PID 0）一个任务在运行——参见第 4 章：进程调度。

阶段三：文件系统与设备（让内核”能访问资源”）

vfs_caches_init() 创建了 VFS 的核心缓存结构——dentry 和 inode 的 slab 缓存。没有这些缓存，后续的文件系统挂载将无法进行。driver_init() 则建立了设备驱动模型的基础设施，包括 sysfs 的根目录、设备类的注册机制等——参见第 9 章：VFS 与文件系统和第 11 章：设备驱动模型。

2.2 do_initcalls：内核模块的延迟初始化#

do_initcalls() 是 start_kernel() 中最”重量级”的调用之一。它按优先级顺序执行所有通过 module_init()、fs_initcall()、device_initcall() 等宏注册的初始化函数。内核定义了 8 个 initcall 级别：

1
#define pure_initcall(fn)       __define_initcall(fn, 0)   // 最先执行
2
#define core_initcall(fn)       __define_initcall(fn, 1)   // 核心子系统
3
#define postcore_initcall(fn)   __define_initcall(fn, 2)   // 核心后
4
#define arch_initcall(fn)       __define_initcall(fn, 3)   // 架构相关
5
#define subsys_initcall(fn)     __define_initcall(fn, 4)   // 子系统
6
#define fs_initcall(fn)         __define_initcall(fn, 5)   // 文件系统
7
#define device_initcall(fn)     __define_initcall(fn, 6)   // 设备驱动
8
#define late_initcall(fn)       __define_initcall(fn, 7)   // 最晚执行

链接器将同一级别的 initcall 函数指针收集到 .init.data 段的特定区域，do_initcalls() 依次遍历这些区域并调用每个函数。这就是为什么大多数内核驱动只需声明 module_init(my_init) 就能自动在启动时被调用。

3.1 init 进程（PID 1）#

kernel_init 是 init 进程的入口函数，它完成以下工作：

1. 等待 kthreadd 就绪：wait_for_completion(&kthreadd_done)——确保内核线程管理器已启动
2. 执行 async_init 探测：async_synchronize_full() 等待所有异步探测完成
3. 尝试挂载根文件系统：调用 kernel_init_freeable()，其中包含 initramfs 的处理和真实根文件系统的挂载
4. 执行 /sbin/init：如果根文件系统挂载成功，则通过 run_init_process() 执行 /sbin/init（或内核命令行指定的 init= 参数）

1
static int __ref kernel_init(void *unused)
2
{
3
    wait_for_completion(&kthreadd_done);
4
    kernel_init_freeable();
5
    // 尝试执行 init 程序，按优先级依次尝试
6
    if (ramdisk_execute_command) {
7
        if (run_init_process(ramdisk_execute_command))
8
            pr_err("Failed to execute %s\n", ramdisk_execute_command);
9
    }
10
    if (execute_command) {
11
        if (run_init_process(execute_command))
12
            pr_err("Failed to execute %s\n", execute_command);
13
    }
14
    // 默认路径
15
    if (!run_init_process("/sbin/init") ||
16
        !run_init_process("/etc/init")  ||
17
        !run_init_process("/bin/init")  ||
18
        !run_init_process("/bin/sh"))
19
        return 0;
20
    panic("No working init found.");
21
}

3.2 kthreadd 进程（PID 2）#

kthreadd 是所有内核线程的”父进程”。它的职责很简单：在一个循环中等待请求，然后创建新的内核线程。

1
// kernel/kthread.c（简化）
2
int kthreadd(void *unused)
3
{
4
    for (;;) {
5
        // 等待创建内核线程的请求
6
        while (list_empty(&kthread_create_list))
7
            schedule();
8
        // 从请求列表中取出任务并创建内核线程
9
        create_kthread(create);
10
    }
11
}

当内核其他部分需要创建内核线程时，它们通过 kthread_create() 将请求挂入 kthread_create_list，然后唤醒 kthreadd。这种设计确保所有内核线程都有一个统一的父进程，便于管理和追踪——你可以在 ps 输出中看到所有内核线程的 PPID 都是 2。

3.3 idle 进程（PID 0）#

rest_init() 的调用者——init_task——在创建完 init 和 kthreadd 后，自身变为 idle 进程。它进入 cpu_startup_entry() → do_idle()，在一个无限循环中等待中断唤醒。当 CPU 没有可运行的任务时，调度器就会切换到 idle 进程——它是每个 CPU 上优先级最低、永远存在的”兜底”进程。

4.1 为什么需要 initramfs？#

内核启动后面临的”鸡生蛋”问题：要挂载根文件系统，需要文件系统驱动和存储驱动；但这些驱动存储在根文件系统上的 /lib/modules/ 中。initramfs 就是解决这个”先有鸡还是先有蛋”问题的方案——它是一个打包在内核映像中（或由引导加载器单独加载）的微型根文件系统，包含了挂载真实根文件系统所需的驱动和工具。

具体来说，initramfs 在以下场景中不可或缺：

• 根文件系统在特殊设备上：LVM、软件 RAID、NVMe、USB 存储等需要先加载驱动
• 根文件系统是加密的：需要先运行 cryptsetup 解密
• 根文件系统是网络挂载的：NFS/iSCSI 需要先配置网络
• 使用 overlayfs 的 Live CD：需要先组装叠加层

4.2 initramfs 的 cpio 格式#

initramfs 使用 cpio 归档格式（newc 变体），这是一种比 tar 更简单、更适合内核解析的格式。cpio 归档由一系列”条目”组成，每个条目包含一个文件头和文件数据：

1
┌─────────────────────────────┐
2
│ cpio header (110 bytes)     │  ← 魔数 "070701"、文件名、权限、大小等
3
├─────────────────────────────┤
4
│ filename (NUL terminated)   │
5
├─────────────────────────────┤
6
│ file data                   │
7
├─────────────────────────────┤
8
│ padding (align to 4 bytes)  │
9
├─────────────────────────────┤
10
│ next entry...               │
11
└─────────────────────────────┘

内核通过 unpack_to_rootfs()（init/initramfs.c）在启动时将 cpio 归档解压到 rootfs（一个基于 tmpfs 的内存文件系统）中。这个过程发生在 start_kernel() → vfs_caches_init() → populate_rootfs() 调用链中。

4.3 /init：initramfs 的入口#

initramfs 解压完成后，内核会尝试执行 /init 程序。这个程序通常是 shell 脚本或 ELF 二进制，负责：

1. 加载必要的内核模块：通过 modprobe 加载存储控制器驱动、文件系统驱动等
2. 创建设备节点：在 /dev 下创建必要的设备文件（或依赖 devtmpfs 自动创建）
3. 挂载临时文件系统：/proc、/sys、/dev 等
4. 定位并挂载真实根文件系统：这是最关键的一步
5. 切换到真实根文件系统：通过 pivot_root 或 switch_root
6. 执行真实根文件系统上的 init：exec /sbin/init

典型的 /init 脚本结构如下：

1
#!/bin/sh
2
# /init - initramfs 入口脚本（简化版）
3

4
# 1. 挂载虚拟文件系统
5
mount -t proc proc /proc
6
mount -t sysfs sysfs /sys
7
mount -t devtmpfs devtmpfs /dev
8

9
# 2. 加载必要的驱动模块
10
modprobe ahci          # SATA 控制器
11
modprobe ext4          # ext4 文件系统
12
modprobe dm-crypt      # 磁盘加密（如需要）
13

14
# 3. 挂载真实根文件系统
15
mount -t ext4 /dev/sda2 /mnt/root
16

17
# 4. 切换根文件系统并执行 init
18
exec switch_root /mnt/root /sbin/init

5.1 pivot_root 系统调用#

pivot_root 是 Linux 提供的系统调用，用于将当前进程的根文件系统切换到新的位置。它的原型为：

1
int pivot_root(const char *new_root, const char *put_old);

工作原理：

1. 将当前根文件系统挂载到 put_old 目录下
2. 将 new_root 设为新的根文件系统
3. 进程的根目录切换到 new_root

pivot_root 的关键约束是：调用进程不能与其他进程共享根文件系统（即不能在共享 mount namespace 中使用），这确保了切换操作的安全性。

5.2 switch_root 工具#

switch_root 是 util-linux 提供的用户态工具，专为 initramfs 场景设计。与 pivot_root 不同，它：

• 删除 initramfs 中的所有内容：释放 initramfs 占用的内存
• 不需要 put_old 参数：因为它直接删除旧根，而非保留
• 只能由 PID 1 执行：确保切换操作的安全性

源码层面，switch_root 的核心逻辑在 init/do_mounts.c 的 prepare_namespace() 和 mount_root() 中有对应实现。内核自身的 init 进程在挂载真实根文件系统后，通过 run_init_process() 执行新根上的 init 程序，这实际上完成了 exec + 根切换的组合操作。

5.3 内核中的根文件系统挂载流程#

内核挂载根文件系统的完整流程如下：

内核命令行参数 root= 指定真实根文件系统的设备，rootfstype= 指定文件系统类型，rootflags= 指定挂载选项。如果使用了 initramfs，这些参数通常由 /init 脚本读取并处理。

6.1 systemd 的架构#

当 /sbin/init（通常是 /lib/systemd/systemd 的符号链接）以 PID 1 身份启动后，它承担了两个核心角色：

1. 系统初始化：按照依赖关系启动所有系统服务
2. 服务管理：监控运行中的服务，按需重启、处理崩溃

systemd 的核心设计理念是基于依赖的服务启动——每个服务声明自己需要什么前置条件，systemd 根据这些声明构建一个有向无环图（DAG），然后尽可能并行地启动服务。

6.2 systemd Unit 类型#

systemd 使用”Unit”作为配置和管理的统一抽象。以下是核心的 Unit 类型：

Service Unit 是最常用的类型，其配置文件结构如下：

1
[Unit]
2
Description=OpenSSH Daemon
3
After=network.target       # 在网络就绪后启动
4
Wants=sshdgenkeys.service  # 弱依赖：密钥生成
5

6
[Service]
7
Type=notify                # 服务通过 sd_notify() 通知就绪
8
ExecStart=/usr/bin/sshd -D # 启动命令
9
ExecReload=/bin/kill -HUP $MAINPID  # 重载命令
10
Restart=on-failure         # 失败时自动重启
11

12
[Install]
13
WantedBy=multi-user.target # 启用时的目标

6.3 依赖关系：Wants vs Requires#

systemd 定义了多种依赖关系，理解它们的区别至关重要：

• Requires：强依赖。如果被依赖的 Unit 失败，当前 Unit 也会失败
• Wants：弱依赖。如果被依赖的 Unit 失败，当前 Unit 不受影响
• Requisite：前置依赖。如果被依赖的 Unit 尚未启动，当前 Unit 立即失败（不等待）
• Conflicts：互斥。不能与指定 Unit 同时运行
• Before/After：顺序依赖。仅控制启动顺序，不产生依赖关系

6.4 systemd 的启动阶段#

systemd 将启动过程划分为明确的阶段，每个阶段对应一个 Target：

1. sysinit.target：系统初始化——挂载文件系统、启动日志、设置主机名
2. basic.target：基本系统就绪——内核模块加载、设备节点创建完成
3. multi-user.target：多用户模式——网络、SSH、cron 等服务启动
4. graphical.target：图形界面——显示管理器（GDM/SDDM）启动

你可以通过 systemd-analyze blame 查看每个服务的启动耗时，通过 systemd-analyze critical-chain 查看关键路径。

7.1 根文件系统参数#

7.2 初始化参数#

7.3 调试参数#

7.4 内存与性能参数#

实践一：使用 dmesg 追踪内核启动过程#

1
# 查看完整的内核启动日志
2
dmesg
3

4
# 带时间戳查看（精确到微秒）
5
dmesg -T
6

7
# 只看启动阶段的初始化信息
8
dmesg | grep -E "initcall|Freeing|Mounted|systemd"
9

10
# 查看内核命令行参数
11
cat /proc/cmdline
12

13
# 统计各 initcall 级别的耗时（需启用 initcall_debug）
14
dmesg | grep "initcall" | awk '{print $NF}' | sort -n | tail -20

实践二：探索 initramfs 内容#

1
# 查看 initramfs 中包含的文件（需安装 lsinitramfs）
2
lsinitramfs /boot/initrd.img-$(uname -r)
3

4
# 手动解压 initramfs 查看内容
5
mkdir /tmp/initramfs && cd /tmp/initramfs
6
zcat /boot/initrd.img-$(uname -r) | cpio -idmv
7

8
# 查看 /init 入口脚本
9
cat /tmp/initramfs/init
10

11
# 查看包含的内核模块
12
find /tmp/initramfs -name "*.ko*" | head -20

实践三：分析 systemd 启动耗时#

1
# 查看总体启动耗时
2
systemd-analyze
3

4
# 查看各服务启动耗时（按时间降序）
5
systemd-analyze blame
6

7
# 查看关键路径（启动链上的瓶颈）
8
systemd-analyze critical-chain
9

10
# 生成启动耗时 SVG 图
11
systemd-analyze plot > boot_analysis.svg
12

13
# 查看当前启动到哪个 target
14
systemctl get-default

实践四：查看和修改内核命令行参数#

1
# 查看当前内核命令行
2
cat /proc/cmdline
3

4
# 临时修改（下次启动生效，GRUB2）
5
# 在 GRUB 启动菜单按 'e' 编辑，在 linux 行末尾添加参数
6
# 例如添加: init=/bin/bash quiet loglevel=3
7

8
# 永久修改（GRUB2）
9
sudo vim /etc/default/grub
10
# 修改 GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
11
sudo update-grub    # Debian/Ubuntu
12
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/Fedora

实践五：观察 PID 0/1/2#

1
# 查看 init 进程（PID 1）
2
ps -p 1 -o pid,comm,cmd
3

4
# 查看所有内核线程（它们的 PPID 都是 2）
5
ps -eo pid,ppid,comm | awk '$2 == 2 {print}'
6

7
# 查看 idle 进程（PID 0，通常显示为 [swaper/...]
8
# 注意：idle 进程在 ps 中通常不可见，但可以通过 /proc 查看
9
ls /proc/*/comm 2>/dev/null | head
10

11
# 查看 kthreadd（PID 2）
12
ps -p 2 -o pid,comm,cmd

内核源码#

权威文档与书籍#

• Linux 内核官方文档：Boot Process — x86 启动协议规范
• Linux 内核官方文档：initramfs buffer format — cpio 格式规范
• systemd 官方文档：Bootup — systemd 启动流程规范
• 《Linux 内核设计与实现》（Robert Love）— 第 5 章系统调用、第 7 章中断、附录内核启动
• 《深入理解 Linux 内核》（Bovet & Cesati）— 附录 A 系统启动
• 《Understanding the Linux Kernel》 — 对启动流程的详细源码级分析

在线资源#

• Bootlin Elixir Cross Referencer — 在线阅读 start_kernel() 源码
• kernel.org x86 boot protocol — 引导加载器与内核的接口规范
• systemd.io — systemd 项目官方站点
• ArchWiki: Arch boot process — 对启动流程的优秀实践文档