Linux：在使用UEFI固件的计算机上内核是如何被启动的

前言

启动计算机通常不是一件难事：按下电源键，稍等片刻，你就能看到一个登录界面，再输入正确的密码，就可以开启一天的网上冲浪之旅了。

但偶尔这件事没那么顺利，有时候迎接你的不是熟悉的登录界面，而是一个令人生畏的命令提示符界面，一闪一闪的提示符告诉你：“你碰到麻烦了”。于是你对着错误提示查找解决方法，按照网页上的步骤，你对着提示符输入并执行了几条你完全不理解的命令，计算机又能正常启动了，但同时你发现你那存有大学舍友糗照的硬盘分区被清空了。

为了防止这样的悲剧发生，了解一下计算机的启动流程是非常有必要的，这能帮助你下次再碰到计算机启动问题时不至于手忙脚乱，而误把硬盘分区格式化掉。

下面开始正题，我会以一个Linux使用者（而不是专业的UEFI开发工程师）的视角来叙述一下UEFI固件计算机的启动流程。虽然BIOS看起来已经成为历史，但它实际上还运行在许多存量设备上——我数年前供职的第一家公司其生产的基于Linux的设备就仍在使用BIOS固件，因此也会对其进行介绍。

BIOS+MBR

在BIOS+MBR时代，对于固件来说，并没有文件的概念，甚至没有分区的概念，它只认识扇区。在把对CPU的控制权交给存储于硬盘MBR中的bootloader代码后，固件就完成了它在启动过程中的大部分工作，后续的流程由bootloader来负责。

标准MBR结构¹：

MBR分区表项格式²：

而MBR空间非常有限，最多只有446个字节，这并不足以容纳全部的启动流程，因此通常bootloader会把启动流程划分为多个阶段，每个阶段的逻辑存储在不同的地方。

以曾经广泛使用的GRUB Legacy为例，它的启动流程分为三个阶段：stage1、stage1.5和stage2，其中stage1.5是可选的。stage1只是一个用来加载stage1.5或者stage2的入口；stage1.5提供了文件系统驱动，如果存在stage1.5，后面的stage2的代码就可以通过文件路径来加载，否则还是要通过扇区列表来加载；stage2才是最终启动内核的地方，根据配置，它可以加载指定路径下的内核镜像，也可以加载安装在其他分区PBR中的bootloader，由另外的bootloader完成系统的启动。³

UEFI+GPT

UEFI和BIOS很不一样，根据标准，UEFI固件需实现对FAT文件系统的支持⁴，而有了对文件系统的支持以后，许多事情都变得豁然开朗了：bootloader再也不用争抢MBR这块弹丸之地，也不需要切割逻辑，把代码见缝插针地安置在磁盘分区之间的空隙中，bootloader现在完全可以作为文件系统中的合法公民，不再是游离在外的幽灵。

GPT

UEFI虽然也可以以CSM模式从MBR硬盘中启动，但如今大多数情况都是配合GPT硬盘使用的，因此了解一下GPT分区表是很有必要的。本文后续也都基于UEFI+GPT的组合，并且不考虑U盘和光盘等移动存储设备。

GPT分区表的结构⁵：

出于兼容性的考虑，在GPT硬盘的第0个LBA仍然保存有一份MBR格式的分区表，但这个分区表将硬盘余下的所有区域标记为一个受保护的分区⁶：

GPT硬盘的第1个LBA才是真正的GPT分区表头，其格式如下⁵：

GPT分区表头后面跟随着分区表项，每个分区表项大小为128字节，其格式如下⁵：

需要注意的是，这里的“分区类型GUID”里面的“分区类型”并不是根据FAT32、NTFS和ext4等具体格式划分的，而是根据用途划分的。下面是gnome-disk-utility在编辑分区时支持的部分分区类型GUID：

既然GPT分区表项中并没有表示分区格式的字段，那么磁盘管理工具是如何获取分区格式的呢？以libblkid为例，它实现了一系列的probe_*函数，通过读取分区头部的superblock中的数据来探测分区格式：

probe_vfat
probe_ext4
probe_ext3
probe_ext2
probe_ntfs

需要