Linux究竟是如何启动的：从固件到登录界面

在任何运行了 systemd 的机器上打开终端，然后运行以下命令：

systemd-analyze

在我正在使用的这台笔记本电脑上，运行该命令后得到的结果是：

启动过程耗时：5.855秒（固件加载时间）+ 8.469秒（引导加载程序加载时间）+ 3.106秒（内核加载时间）+ 12.181秒（用户空间处理时间），总计29.613秒。在进入用户空间后，系统又用了12.175秒才完成启动过程。

将这四个数字相加，得到的结果应该是29.611秒，而不是最后一行显示的29.613秒。这个差异是真实存在的，并非计算错误：`systemd-analyze`在显示结果时会对每个阶段的耗时进行四舍五入处理，因此其中几毫秒的差异会在最终结果中被忽略掉。虽然这个差距很小，但它能帮助你避免浪费时间去寻找其实并不存在的问题。

这四个数字代表了Linux系统启动过程中的四个主要阶段：内核加载耗时3秒，引导加载程序加载耗时8.5秒，固件加载耗时近6秒，在这些步骤完成之前，系统的另外14秒钟实际上是在进行一些初始化工作。而大多数人往往只关注其中的一个或两个阶段。

本文详细介绍了Linux系统的完整启动过程，从固件将控制权交给引导加载程序，到最终出现登录界面这一整个流程。这里提到的所有操作你都可以亲自尝试进行，而且几乎不需要使用root权限。

目录

• 所需准备事项

• Linux系统的启动过程实际上包含四个阶段

• 固件：Linux系统根本看不到它的存在

• 引导加载程序：你真正参与其中的5秒钟

• 内核阶段：将系统变为可用的短短3秒钟

• initramfs的作用：它解决了“先有鸡还是先有蛋”的问题

• PID 1：另外12秒钟去哪儿了

• 为什么systemd-analyze显示的启动时间会误导你

• 理解系统启动过程中的关键环节

• 为什么你的Linux系统启动时间会有所不同

• 登录界面：系统将控制权交给你

• 结论

• 后记

您所需要的准备

任何运行systemd的Linux系统都符合要求，这包括Ubuntu、Debian、Fedora、Arch以及2026年人们通常会安装的其他操作系统。另外还需要一个终端窗口，就这样。

我用来进行测试的系统是Ubuntu 22.04.5 LTS，它运行的是5.15.0-190-generic版本的内核，通过UEFI模式从一块NVMe硬盘启动，该硬盘使用ext4文件系统作为根文件系统，而systemd的进程ID为1。您的系统配置可能会有所不同，有时差异会很大，我会指出这些差异可能出现在哪些方面。

有一个命令需要以root权限执行，而在许多系统中，还有一个文件的访问权限是受限的。当我们讨论到这些内容时，我会特别指出来。

Linux启动过程实际上包含四个阶段

“启动”这个词让人以为整个过程只有一个步骤。但实际上它分为四个阶段，而且这些阶段之间几乎没有任何交互。

首先运行的是固件，它位于主板上的一块芯片上，其任务是找到可启动的部分并启动它。

之后固件会将控制权交给引导加载程序，然后自己停止工作。引导加载程序的任务是找到内核文件，将其连同初始文件系统一起加载到内存中，然后立即开始执行内核代码，之后它也会停止运行。

内核会初始化硬件设备，挂载根文件系统，并启动一个用户空间进程。之后内核就不再直接参与系统的运行了，但它会一直为这个进程提供支持服务。

那个第一个被启动的进程，其进程ID为1，它负责启动系统中的其他所有进程。

每一个阶段的控制权交接都是单向的。固件并不会在Linux系统运行过程中处于待命状态以提供帮助；引导加载程序在完成任务后也会从内存中消失。记住这一点，因为这可以解释为什么在systemd-analyze报告中出现的四个数值是由不同的因素计算得出的，因此它们的含义也各不相同。

固件，以及Linux系统无法直接访问的部分

在报告的5.855秒这个时间值中，只有固件的运行时间不是由Linux系统自己测量的。您可以通过以下命令查看这一数值的具体来源：

cat /sys/firmware/acpi/fpdt/boot/bootloader_launch_ns

输出结果为：5855973785秒。

这就是5.855973785秒，也就是systemd-analyze报告中显示的5.855秒这个数值——实际上这个数字是被截取后呈现给用户的。固件会在将控制权交接之前，将这一数值写入一个名为“Firmware Performance Data Table”的ACPI表格中，而内核则会从该目录中读取这些数据。另外还有一些其他组件也会参与完成这个统计过程：

cat /sys/firmware/acpi/fpdt/boot/exitbootservice_end_ns

在我测试的这台系统上，最终测量得到的时间为14325507185秒，也就是14.325秒。这个数值实际上包含了固件和引导加载程序运行所花费的总时间，与将这两个阶段的时间相加得到的结果是一致的。

这里就是容易让人犯错的地方。实际上，关键并不在于系统是否支持UEFI，而在于你的固件是否真的会发布FPDT信息。很多支持UEFI的系统其实并不会发布这类信息，尤其是虚拟机；在那些系统中，使用systemd-analyze工具检查时，会发现既没有“固件阶段”，也没有“加载程序阶段”的记录，系统的启动过程直接从内核开始计算。因此，你应该查看的是相关表格，而不是是否支持UEFI：

ls /sys/firmware/acpi/fpdt/boot/ 2>&/dev/null || echo "没有FPDT信息，所以无法获取固件相关的启动时间数据"

如果这个命令没有任何输出，那就说明你的固件并没有发布这类信息，而从Linux系统内部也无法恢复这些数据。

近六秒的启动时间确实相当长，而从Linux系统内部来说，我们几乎无能为力。这部分时间主要被用于内存初始化、设备检测，以及硬件厂商在系统交付之前预先执行的某些操作。对于那些拥有快速存储设备的笔记本电脑来说，这个阶段往往就是整个启动过程中耗时最长的环节，这一点会让那些把优化工作重点放在服务程序上的用户感到十分惊讶。

引导加载程序，以及你选择的那五秒钟

这个数值会直接影响你对整个启动过程的理解。在上面的例子中，加载程序阶段耗时8.469秒，这一时间几乎是内核启动时间的三倍。但实际上，其中几乎没有任何时间真正用于实际的操作。

grep ^GRUB_TIMEOUT /etc/default/grub

在这台机器上，相关的配置如下：

GRUB_TIMEOUT="5"

在这8.469秒的时间里，有5秒钟其实是GRUB在倒计时，等待用户按下按键，但实际上这个按键永远不会被按下。这是由安装程序一次性设置的配置选项，之后就再也不会被修改了。如果你曾经疑惑为什么自己的机器虽然硬件配置很好，但启动速度却很慢，那么这就是你需要首先检查的地方，而且这也是本文中提到的最简单的解决方法。

当GRUB在等待的时候，它已经知道接下来要执行哪些操作了。你可以查看它传递给内核的指令：

cat /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic root=UUID=b4d0343e-9df4-40a7-be97-dcd51bdbf553 ro splash intel_iommu=on vt_handoff=7

这一行代码实际上就包含了引导加载程序与内核之间所有的交互信息。BOOT_IMAGE指明了要加载的内核版本；root=UUID=...指定了要挂载的文件系统，通过UUID来识别文件系统，这样即使硬盘编号发生变化，这个配置也不会受到影响；ro表示初始时要以只读模式挂载文件系统；splash表示使用图形化启动界面而不是文本界面；intel_iommu=on表示启用IOMMU功能；vt_handoff=7则确保了虚拟终端能够无缝地切换到图形化界面。

GRUB会将两个文件加载到内存中：内核程序和初始文件系统镜像。之后，它就会立即执行内核程序，自己也就不再存在了。

内核阶段：三秒钟让机器进入正常工作状态

请观看这一过程的发生，这些时间戳是从内核开始运行的那一刻起开始计量的：

journalctl -k -b -o short-monotonic | head

[    0.000000] devils-dell kernel: 微代码已更新至0x100版本
[    0.000000] devils-dell kernel: Linux版本为5.15.0-190-generic
[    0.000000] devils-dell kernel: 命令行参数：BOOT_IMAGE=/boot/vmlinuz-5.15.0-190-generic
[    0.000000] devils-dell kernel: 支持的CPU型号：

“0”这个时间点表示内核开始执行，而不是你按下电源按钮的时刻。在这一点之前的所有内容——包括那14秒钟内的固件和引导加载程序——都完全不在这个计时范围内。这就是关于内核启动时间戳需要了解的第一件事，也是为什么使用dmesg查看输出时，某些设备的运行速度会显得比实际快很多的原因。

你可能尝试过使用dmesg来查看这些信息，但会遇到如下错误：

dmesg: 读取内核缓冲区失败：操作不被允许

这是有意设置这样的限制的，你可以通过以下命令来验证这一点：

sysctl kernel.dmesgrestrict

Ubuntu系统将kernel.dmesgrestrict的值设置为1，这样就会限制只有root用户才能读取内核缓冲区中的信息，因为这些信息可能被攻击者利用。因此，建议使用journalctl -k来查看相关日志，因为这个命令是通过系统日志来读取信息的，而且任何普通用户都可以使用它。

/proc/cmdline文件中还包含另一个值得注意的细节。从该文件可以看出，内核被设置为以只读模式挂载根文件系统，但你现在使用的系统显然能够对磁盘进行写入操作。让我们来看看当前的设置情况：

findmnt -n -o SOURCE,FSTYPE,OPTIONS /

/dev/nvme0n1p2 ext4 rw,relatime,errors=remount-ro

现在根文件系统被设置为可读写模式，这说明肯定有某种设置发生了变化。通常情况下，根文件系统会先以只读模式挂载，这样就可以安全地对其进行检查了；因为如果在进程正在对文件系统进行写入操作时进行检查，很可能会导致问题变得更加严重。

当检查完成后，用户空间会再次将同一文件系统设置为可读写模式。而errors=remount-ro这个选项其实起到了相反的作用：如果内核在后续使用过程中遇到了文件系统错误，它会自动恢复到只读模式，而不会继续尝试对不再可信的文件系统进行写入操作。

现在让我们找出内核开始不再单独执行操作的那一确切时刻：

journalctl -b -o short-monotonic | grep -m1 'systemd[1]'

[    3.152109] devils-dell systemd[1]: 模块“autofs4”已被加载

在开始运行3.15秒后，PID为1的进程记录了第一条日志信息。这个时间点与systemd-analyze工具所显示的3.106秒的时间相符，也就是说从这一刻起，内核就不再单独执行任何操作了。此后，内核只会响应系统调用，而关于接下来应该执行什么操作的决策都是由用户空间来做出的。

什么是initramfs，以及它所解决的“先有鸡还是先有蛋”的问题

在Linux启动过程中，有一个隐藏在3秒钟内的步骤，这个步骤正是最让人们感到困惑的部分。

内核需要挂载你的根文件系统。为此，它需要你的存储控制器的驱动程序以及文件系统的驱动程序，可能还需要一些用于组建RAID阵列、打开加密磁盘或激活LVM的代码。这些驱动程序都以模块的形式存在，而这些模块则位于根文件系统中——不过目前内核还无法挂载这个根文件系统。

为了解决这个问题，人们使用了这样一个方案：创建一个小型文件系统，由引导加载程序与内核一起加载到内存中，这个文件系统本身是完备的。让我们来看一下具体的内容：

ls -l /boot/initrd.img-$(uname -r)
lsinitramfs /boot/initrd.img-$(uname -r) | wc -l
lsinitramfs /boot/initrd.img-$(uname -r) | grep -c '\.ko'

上述路径和工具是Debian与Ubuntu的标准配置。在Fedora系统中，这个文件系统的路径是/boot/initramfs-$(uname -r).img，使用的工具是lsinitrd；而在Arch系统中，通常使用的是/boot/initramfs-linux.img，对应的工具是lsinitcpio。

在这台机器上，这个文件系统的大小为79,945,887字节，大约相当于76MB，其中包含了2,318个文件，其中1,386个是内核模块。这是一个真正可以正常运行的、虽然功能极为简化的Linux系统，它的存在唯一的目的就是帮助内核找到并挂载真正的根文件系统。

一旦完成了这个任务，这个小型文件系统就会继续执行后续的操作。它不会退出系统，而是会替换掉真正的根文件系统，让自己“退居幕后”，然后执行真正的/sbin/init命令，而整个过程中并不会创建新的进程树。进程ID为1的进程会在执行过程中改变自身的身份，但仍然保持原来的进程ID。

如果你使用的是Arch或经过精简配置的Fedora系统，那么你的initramfs文件系统的大小可能会只有这个大小的十分之一。因为Ubuntu会构建一个包含各种通用驱动程序的initramfs文件系统，这样同一个文件系统就可以在任何机器上正常启动。这种做法实际上是牺牲了文件系统的体积来换取更好的兼容性，而lsinitramfs命令可以帮助你了解自己系统中实际包含了哪些内容。

systemctl get-default
systemctl list-unit-files --no-legend | wc -l
systemctl list-units --type=service --state=running --no-legend | wc -l

graphical.target
472
44

systemd-analyze blame | head -5

3分钟48.947秒：fstrim.service
     44.548秒：plocate-updatedb.service
     13.953秒：apt-daily.service
      4.875秒：docker.service
      4.106秒：NetworkManager-wait-online.service

systemctl show fstrim.service -p TriggeredBy -p WantedBy
systemctl list-timers fstrim.timer

TriggeredBy=fstrim_timer
WantedBy=
NEXT                        LEFT        LAST                        PASSED
周一 2026-09-14 00:59:36 IST 4天后
周一 2026-09-07 00:33:35 IST 2天前

systemd-analyze critical-chain

graphical.target @12.175s
└─multi-user.target @12.175s
  └─docker.service @7.297s +4.875s
    └─network-online.target @7.295s
      └─NetworkManager-wait-online.service @3.188s +4.106s
        └─NetworkManager.service @3.151s +35ms
          └─network-pre.target @3.150s
            └─netfilter-persistent.service @1.377s +1.772s
              └─local-fs.target @1.374s

systemctl status display-manager --no-pager | head -1
loginctl show-session $(loginctl | awk 'NR==2{print $1}') -p Type -p Class