UEFI+GPT 引导过程分析

---

1 UEFI 简介

  UEFI（Unified Extensible Firmware Interface，统一可扩展固件接口） 是一种现代固件标准，用于替代传统的 BIOS（Basic Input/Output System），负责计算机启动时的硬件初始化、操作系统加载及系统设置。以下是其核心特点与功能：

1.1 主要特点

• 模块化设计：采用分阶段执行的驱动模型（如PEI、DXE、BDS等），支持动态加载驱动程序，灵活性更高。
• 图形化界面：支持鼠标操作和多语言，提供更直观的配置界面（如UEFI Setup）。
• 快速启动：并行初始化硬件，显著缩短启动时间（相比传统BIOS的串行操作）。
• 大容量存储支持：使用 GPT（GUID分区表），突破MBR的2TB限制，支持超过4个主分区。
• 安全启动（Secure Boot）：验证操作系统引导加载程序（如Windows Boot Manager）的数字签名，防止恶意软件篡改。

1.2 关键组件

• UEFI固件：存储在主板的SPI闪存中，包含硬件初始化代码和基本服务。
• EFI系统分区（ESP）：FAT32格式的分区，存放引导加载程序（如bootmgfw.efi）和驱动程序。
• UEFI Shell：提供命令行环境，用于调试或手动加载EFI应用程序。
• ACPI（高级配置与电源管理）：与操作系统协同管理电源状态和硬件配置。

1.3 与传统BIOS的区别

特性	UEFI	传统BIOS
启动模式	支持UEFI和Legacy（CSM兼容模式）	仅Legacy（16位实模式）
磁盘分区	GPT（支持>2TB磁盘）	MBR（最大2TB）
图形界面	支持高分辨率和鼠标	仅文本/简单图形（无鼠标）
驱动程序	可扩展的EFI驱动（.efi文件）	固化在ROM中，不可扩展
多系统引导	通过bootx64.efi灵活管理	依赖MBR和引导扇区

1.4 应用场景

• 操作系统支持：Windows（Vista后64位版本需UEFI）、Linux（如GRUB2）、macOS（基于UEFI的Apple Boot Camp）。
• 云计算与虚拟化：支持PXE网络启动和虚拟固件（如OVMF用于QEMU/KVM）。
• 安全场景：Secure Boot可防止Rootkit攻击，TPM 2.0集成增强可信计算。

1.5 局限性

• 硬件依赖：需要64位CPU（x86-64/ARM64）及UEFI兼容硬件。
• 兼容性问题：旧设备或某些Linux发行版可能需要关闭Secure Boot。

  UEFI通过现代化设计解决了BIOS的诸多限制，成为当前计算机、服务器和移动设备的标配固件。其扩展性、安全性和性能优势推动了快速启动、大容量存储支持等技术的发展。

参考：一文让你搞懂 UEFI

2 GPT 简介

  GPT（GUID Partition Table，全局唯一标识分区表）是一种现代磁盘分区方案，用于替代传统的MBR（主引导记录）分区方案。

2.1 GPT分区的主要特点

• 支持更大磁盘：GPT可以管理最大8ZB（zettabytes）的磁盘，而MBR只能支持最大2TB
• 更多分区：GPT支持最多128个主分区（Windows实现），MBR只有4个主分区
• 冗余设计：GPT在磁盘开头和结尾都存储分区表信息，提供更好的数据恢复能力
• 唯一标识符：每个分区都有全局唯一标识符（GUID）
• CRC校验：分区表信息包含校验和，可以检测数据损坏

2.2 全球唯一标识符GUID

  GUID全球唯一标识符（Globally Unique Identifier）是一种由算法生成的二进制的数字标识符。在理想情况下，任何计算机和计算机集群都不会生成两个相同的GUID。总之，你将其理解为关于某个东西的唯一数字标签就可以了。

GUID的结构
标准GUID的格式为：{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}，（可以不加花括号）。

• 第一部分：32位(4字节，8个十六进制字符)
• 第二部分：16位(2字节，4个十六进制字符)
• 第三部分：16位(2字节，4个十六进制字符)
• 第四部分：16位(2字节，4个十六进制字符)
• 第五部分：48位(6字节，12个十六进制字符)

  这一概念的起源可以追溯到计算机科学和分布式系统发展的关键时期，其核心思想和技术标准经历了多阶段的演进。以下是GUID概念的技术溯源和发展历程：

• 理论雏形：分布式系统需求（1980年代）。随着计算机网络和分布式系统的兴起，需要一种跨平台、去中心化的唯一标识方法，避免集中式分配带来的瓶颈。
   UUID（Universally Unique Identifier）：由阿波罗计算机公司的工程师（如Paul J. Leach和Rich Salz）在1980年代末提出，用于分布式计算环境（DCE）中的远程过程调用（RPC）和文件系统标识。
   RFC 4122的前身：UUID的生成算法（如基于时间戳、MAC地址或随机数）为GUID提供了理论基础。
• 微软的GUID标准化：（1990年代初）。在开发COM（Component Object Model）和OLE（Object Linking and Embedding）技术时，微软需要一种唯一标识组件接口的方法，于1993年左右正式采用GUID作为标准。微软的GUID本质上是UUID的一个实现，但术语"GUID"成为微软生态中的专有名称。
   微软的GUID遵循与UUID相同的128位格式（16字节），例如：{3F2504E0-4F89-11D3-9A0C-0305E82C3301}。
   生成方式包括基于MAC地址（版本1）和随机数（版本4）。
• 开放标准的整合：RFC 4122（2005年）。互联网工程任务组（IETF）在2005年发布RFC 4122，将UUID（包括GUID）的生成算法、格式和应用场景标准化。该文档统一了微软GUID和其他实现，明确划分了5个版本：基于时间戳和MAC地址；基于DCE安全；基于MD5哈希和命名空间；基于随机数；基于SHA-1哈希和命名空间。
   GUID与UUID的关系：GUID是微软对UUID标准的实现，两者在技术上完全兼容，仅术语不同。
• 在GPT分区表中的应用（21世纪初）。英特尔在开发EFI（Extensible Firmware Interface）时，采用GUID作为分区表和分区的唯一标识符，后成为UEFI标准的一部分。
   GPT（GUID Partition Table）利用GUID的全球唯一性解决MBR分区表的限制（如磁盘容量和分区数量）。
   分区类型GUID（如EBD0A0A2-B9E5-4433-87C0-68B6B72699C7）标准化了不同操作系统的分区用途。
   磁盘和分区的唯一GUID避免了硬件变动导致的标识冲突。
• 其他领域的扩展应用
  数据库：用作主键（如SQL Server的UNIQUEIDENTIFIER类型）。
  网络协议：如活动目录（Active Directory）中的对象标识。
  软件开发：IDE（如Visual Studio）使用GUID标识项目文件。
• 关键人物与组织
  Paul J. Leach & Rich Salz：UUID早期设计者。
  微软COM团队：推动GUID在Windows生态的普及。
  IETF：通过RFC 4122实现跨平台标准化。

  GUID的概念最初源于分布式系统对唯一标识的需求，由UUID理论发展而来，经微软在COM/OLE中商业化命名为"GUID"，最终通过RFC 4122成为开放标准。其在GPT分区表中的应用体现了GUID在硬件抽象层的核心价值：去中心化生成、全局唯一性和跨平台兼容性。

  我理解：比如你将一块GPT分区的硬盘加到一台运行良好的计算机上，由于这块硬盘的GUID标识和计算机上的不同因此能正确识别而不会产生冲突。这就为硬件的可扩展性提供了条件，这也是这串数字存在的价值。

3 GPT分区表中的GUID详解

  GUID分区表(GPT)是现代计算机系统中用于组织磁盘分区的一种标准，它使用全局唯一标识符(GUID)作为其核心组成部分。下面我将详细介绍GPT分区表中的各种GUID及其作用。

3.1 磁盘GUID (Disk GUID)

• 位置：位于GPT头中(偏移量56-71)
• 作用：唯一标识整个磁盘
• 格式：标准的128位GUID格式(例如: {5D5A8A3D-2D4B-4C7E-8A1F-3A9C8B9D0E1F})
• 特点：
  • 在创建GPT分区表时生成
  • 操作系统和引导加载程序可以使用它来识别特定磁盘
  • 在磁盘克隆时通常会被更改

3.2 分区类型GUID (Partition Type GUID)

• 作用：标识分区的内容类型和用途
• 位置：每个分区条目中的前16字节
• 常见示例：
  • C12A7328-F81F-11D2-BA4B-00A0C93EC93B - EFI系统分区
  • EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 - 基本数据分区(Windows)
  • 0FC63DAF-8483-4772-8E79-3D69D8477DE4 - Linux文件系统数据
  • 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F - Linux交换分区

3.3 分区唯一GUID (Partition Unique GUID)

• 作用：唯一标识特定分区
• 位置：每个分区条目中的16-32字节
• 特点：
  • 在创建分区时生成
  • 用于跟踪分区，即使分区位置或大小发生变化
  • 某些操作系统(如Windows)使用它来挂载分区

3.4 分区条目数组GUID (Partition Entry Array CRC32)

• 注意：这不是GUID，而是CRC32校验值，用于验证分区条目数组的完整性

3.5 GUID的生成原理

GUID的生成通常遵循RFC 4122标准，使用以下方法之一：

1. 基于时间戳和MAC地址(版本1)
2. 基于名字和命名空间的MD5哈希(版本3)
3. 随机生成(版本4)
4. 基于名字和命名空间的SHA-1哈希(版本5)

在GPT分区表中，GUID通常使用版本4(随机生成)的方法创建。

3.6 GUID的重要特性

1. 唯一性：极低的重复概率($2^{128}$种可能组合)
2. 平台独立性：不依赖于特定硬件或操作系统
3. 持久标识：即使分区位置或大小改变，GUID保持不变
4. 兼容性：支持多种操作系统和文件系统

3.7 实际操作中的GUID

• 在Linux中可以使用blkid或lsblk -o +PARTUUID查看分区GUID
• 在Windows中可以使用diskpart的list partition命令查看
• 在macOS中可以使用diskutil list查看

  GUID分区表通过这些GUID实现了比传统MBR更强大、更灵活的分区管理能力，支持更大的磁盘容量和更多的分区数量，是现代计算机系统的重要组成部分。

4 磁盘和分区信息解读

在linux中用各种磁盘工具能查出很多磁盘和分区的信息，下面就针对lsblk -f和blkid -p查出的信息进行解读。

4.1 lsblk -f 查询信息解读

通过该命令可以查询出8个字段，其含义如下

NAME	FSTYPE	FSVER	LABEL	UUID	FSAVAIL	FSUSE%	MOUNTPOINTS
设备或分区名称	文件系统类型	文件系统版本	分区标签	文件系统唯一ID	可用空间	已用空间百分比	挂载点路径
sda1	ext4、ntfs、vfat	1.0、FAT32	windows、Lenovo	FBF5-DB79	77.3G	16%	/、/efi

4.2 blkid -p 查询信息解读

按功能分类

• 文件系统相关字段

  • UUID

    • 含义：文件系统的唯一标识符（通用唯一识别码）。
    • 作用：系统通过UUID而非设备名挂载分区，避免磁盘顺序变化导致错误。
    • 示例：FBF5-DB79（FAT32短UUID）、ec2487bc-...（ext4长UUID）。

  • TYPE

    • 含义：文件系统类型。
    • 常见值： vfat（FAT32）、ntfs、ext4、swap。
    • 空白表示无文件系统（如未格式化或特殊分区）。

  • VERSION

    • 含义：文件系统版本。
    • 示例：FAT32、1.0（ext4版本）。

  • LABEL

    • 含义：分区的用户自定义标签（卷标）。
    • 注意：中文字符可能因编码问题显示为乱码（如 M-fM-3M-^UM-hM-'M-^D 实际为中文标签）。

  • USAGE

    • 含义：分区用途。
    • 常见值： filesystem（普通文件系统）、other（如交换分区）。

  • FSBLOCKSIZE

    • 含义：文件系统的逻辑块大小（字节）。
    • 示例：512（FAT32）、4096（ext4/NTFS）。

  • BLOCK_SIZE

    • 含义：物理块大小（通常与 FSBLOCKSIZE 相同）。
    • 示例：512、4096。

  • FSSIZE

    • 含义：文件系统的总大小（字节）。
    • 示例：272627712（约260MB）、107374182400（约100GB）。

  • FSLASTBLOCK

    • 含义：文件系统的最后一个块编号（仅部分文件系统显示）。
    • 示例：26214400（ext4分区）。

  • ENDIANNESS

    • 含义：字节序（仅交换分区显示）。
    • 值：LITTLE（小端序，常见于x86架构）。

• 分区表相关字段（GPT格式）

  • PART_ENTRY_SCHEME

    • 含义：分区表类型。
    • 值：gpt（现代标准）、dos（传统MBR）。

  • PART_ENTRY_UUID

    • 含义：分区本身的唯一标识符（GUID）。
    • 示例：76d7fe89-94dc-4d85-a97f-951e7c50dd73。

  • PART_ENTRY_TYPE

    • 含义：分区类型的GUID代码。
    • 常见值：
      • c12a7328-f81f-11d2-ba4b-00a0c93ec93b：EFI系统分区。
      • ebd0a0a2-b9e5-4433-87c0-68b6b72699c7：Windows基本数据分区（NTFS）。
      • 0fc63daf-8483-4772-8e79-3d69d8477de4：Linux原生分区（ext4）。
      • 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f：Linux交换分区。

  • PART_ENTRY_NAME

    • 含义：分区的描述性名称。
    • 示例：Microsoft reserved partition、Basic data partition。

  • PART_ENTRY_NUMBER

    • 含义：分区编号（从1开始）。
    • 示例：1（第一个分区）。

  • PART_ENTRY_OFFSET

    • 含义：分区起始扇区（相对于磁盘开头）。
    • 示例：2048（EFI分区通常从此开始）。

  • PART_ENTRY_SIZE

    • 含义：分区占用的扇区数量。
    • 计算大小：PART_ENTRY_SIZE × 512字节。
    • 示例：532480 扇区 ≈ 260MB。

  • PART_ENTRY_FLAGS

    • 含义：分区的特殊标志（十六进制）。
    • 示例：
      • 0x8000000000000000：Microsoft保留分区的隐藏标志。
      • 0x8000000000000001：Windows恢复分区的受保护标志。

  • PART_ENTRY_DISK

    • 含义：磁盘的设备号（主设备号:次设备号）。
    • 示例：8:0 表示主设备号8（SCSI/SATA磁盘），次设备号0。

• 特殊字段说明

  • WinRE_DRV

    • 含义：Windows恢复环境分区（WinRE），用于系统修复。
    • 标识：PART_ENTRY_TYPE=de94bba4-06d1-4d40-a16a-bfd50179d6ac。

  • 乱码标签问题

    • 原因：NTFS的中文标签在Linux终端中未正确解析为UTF-8。
    • 修复命令： sudo ntfslabel /dev/sda5 "正确标签" # 重新设置标签

  • 交换分区（swap）

    • 字段：TYPE=swap、USAGE=other，无挂载点，通过UUID激活。

字段分类	关键字段	示例值/说明
文件系统	UUID, TYPE, LABEL	FBF5-DB79, ext4, Windows
分区布局	PART_ENTRY_OFFSET/SIZE	起始扇区 2048，大小 532480 扇区
分区类型	PART_ENTRY_TYPE	c12a7328...（EFI）、0fc63daf...（Linux）
特殊标志	PART_ENTRY_FLAGS	0x8000000000000001（受保护分区）

5 UEFI + GPT 引导过程

此处所说的引导过程是相对宏观的，当然也涉及到一些底层介绍。

5.1 计算机启动宏观流程

阶段	关键任务
1. 通电	电源供电 → CPU复位 → 执行第一条指令（UEFI固件）。
2. UEFI/BIOS	POST自检 → 硬件初始化 → 加载UEFI驱动 → 读取NVRAM启动项。
3. Bootloader	加载bootmgfw.efi（Windows）或grubx64.efi（Linux） → 准备内核环境。
4. OS内核	内核初始化（内存管理、进程调度） → 启动系统服务（systemd/smss.exe）。
5. 用户登录	图形界面（GUI）加载 → 用户登录 → 进入桌面。

5.2 UEFI + GPT 引导的微观过程

前提：UEFI驱动已加载（这些是主板硬件的事情，用户无需操心），UEFI驱动加载后，就已经可以识别FAT32文件格式的磁盘（其他格式的文件系统不能识别）。

后续过程：

1. 读取 NVRAM 启动项
   NVRAM：非易失性存储器（Non-Volatile Random Access Memory），是UEFI中用于存储持久化配置数据的区域。其物理实现为传统上依赖主板上的CMOS电池供电的RAM（兼容BIOS时代的设计），现代UEFI可能使用SPI闪存的特定分区或嵌入式控制器（如Intel PCH）的专用存储区域。

  可用bcdedit（windows工具）efibootmgr（linux工具）可以查看其中的内容。里面记录了从什么地方去寻找Bootloader（即 .efi文件）。如果其为空，那么从ESP分区的读取 \EFI\BOOT\bootx64.efi（这是个固定位置）。如果找不到就会报错。

2. 执行 .efi 文件
   Windows：bootmgfw.efi 会加载 \EFI\Microsoft\Boot\BCD（引导配置数据库），进而启动 Windows 内核（winload.efi）。
   Linux：grubx64.efi 会加载 /boot/grub/grub.cfg，显示引导菜单并启动内核（vmlinuz）和 initramfs。
   安全启动（Secure Boot）：如果启用，UEFI 会验证 .efi 文件的数字签名（如 Microsoft 或 Canonical 的证书），防止恶意代码执行。

注意：各系统的引导器，已经可以识别自己的的文件系统。

3. 移交控制权给操作系统
   .efi 文件完成引导后，会加载操作系统内核（如 ntoskrnl.exe 或 vmlinuz），最终启动用户空间（如 Windows 桌面或 Linux shell）。

5.3 实际遇到过的一个特殊情况分享

  我的计算机的主板是2014年的微星主板，原来有sata硬盘。后来我加装了一块NMVE硬盘，不论是Windows系统还是Linux系统都可以识别。但是主板的UEFI驱动不能直接识别NMVE为硬盘，只能识别sata硬盘。
  我用Linux引导盘，安装Linux系统在NMVE硬盘上，grub的基本引导程序安装在EFI分区上。安装过程没有问题，但是启动时引导程序说不能进一步加载。
  分析原因，是grub基本引导程序加载后，识别不到NVME硬盘，因为此时主板没有将NVME设备识别为硬盘。
  后来，我将 /boot（这个里面装的Linux内核）中的内容移动到sata硬盘上，并将其挂载在 /boot，从而解决了问题。因为Linux内核加载后，可以识别NVME硬盘，从而完成整个Linux操作系统的加载。

后记

  计算机的启动过程还是值得好好研究的，比如分区表的物理存储，特殊标识；机械或固态硬盘的扇区、寻址和更进一步的逻辑封装；UEFI如何寻找Bootloader；Bootloader如何进一步加载，其物理过程如何。都是一件很有趣的事情。
  利用DeepSeek和网络，能解决大部分问题。希望通过人工智能能够实现知识平权。