4、启动设备管理：启动顺序配置、UEFI启动项管理、手动添加/删除启动项
启动设备管理，说白了就是告诉固件：「嘿，从哪儿把操作系统拽进来？」
很多人觉得这很简单——进BIOS改个顺序不就完了？嗯，表面上看确实如此。但我在项目中遇到过不少怪事：明明硬盘插得好好的，系统就是起不来；或者启动项列表里突然多了一堆「幽灵」条目。这些问题的根子，都在启动设备管理这块。
4.1 启动顺序的底层逻辑
UEFI的启动顺序，不是简单排个队。它背后有一套优先级规则。
核心原则：UEFI固件会按照 全局变量 中定义的顺序，依次尝试每个启动项。一旦某个启动项返回成功，启动过程就停了。
这个全局变量叫 BootOrder，存在NVRAM里。它是个数组，里面存的是启动项的ID（Boot####）。
举个例子：
BootOrder: 0001, 0003, 0000, 0002
对应的启动项：
Boot0001: "Windows Boot Manager"
Boot0003: "UEFI: SanDisk USB"
Boot0000: "UEFI: ST1000DM003"
Boot0002: "UEFI: PXE IPv4"固件会先试 Boot0001，不行再试 Boot0003，以此类推。一旦某个启动项加载成功，后面的就不管了。
我个人的习惯：排查启动故障时，第一件事就是进UEFI Shell，用 bcfg boot dump 命令把 BootOrder 和所有 Boot#### 变量打出来看一眼。很多问题一眼就能发现。
4.2 启动项的结构
每个启动项（Boot####）其实是一个结构体。我把它拆开给你看：
| 字段 | 偏移 | 说明 |
|---|---|---|
| Attributes | 0x00 | 属性标志（是否隐藏、是否支持启动） |
| FilePathListLength | 0x04 | 设备路径的总长度 |
| Description | 0x06 | 用户看到的名称（如 "Windows Boot Manager"） |
| FilePathList | 可变 | 设备路径列表，指向具体的EFI应用程序 |
| OptionalData | 可变 | 厂商自定义数据（很少用） |
这里最关键的是 FilePathList。它告诉固件：「你要找的启动文件在哪个设备上，路径是什么。」
举个例子，一个典型的Windows启动项，它的设备路径可能是这样的：
VenHw(....)/Sata(0x0,0x0)/HD(1,MBR,0x12345678,0x800,0x10000)/\EFI\Microsoft\Boot\bootmgfw.efi你看，它精确到了分区和文件路径。如果这个路径里的任何一环出了问题——比如分区号变了、文件被删了——启动就会失败。
我曾经踩过的坑：有一次客户反映，系统更新后重启就蓝屏。查了半天，发现是Windows更新把 bootmgfw.efi 替换了，但新版本的签名和固件里的安全策略不匹配。启动项本身没变，但文件内容变了。所以排查时别光看启动项列表，还得检查文件本身是否完好。
4.3 手动添加/删除启动项
什么时候需要手动操作？常见场景有：
- 系统盘换了，启动项指向了旧盘
- 安装了多系统，但某个系统的启动项没自动生成
- 启动项列表被搞乱了，需要清理
- 测试新的EFI启动程序
4.3.1 使用UEFI Shell操作
我个人最推荐的方式。UEFI Shell是排查启动问题的瑞士军刀。
查看当前启动项：
Shell> bcfg boot dump
选项: 启动选项
索引: 0 描述: Windows Boot Manager
索引: 1 描述: UEFI: SanDisk USB
索引: 2 描述: UEFI: ST1000DM003
索引: 3 描述: UEFI: PXE IPv4添加一个启动项：
Shell> bcfg boot add 4 fs0:\EFI\refind\refind_x64.efi "rEFInd Boot Manager"这条命令的意思是：在索引4的位置，添加一个启动项，指向 fs0: 分区上的 \EFI\refind\refind_x64.efi，显示名称为 "rEFInd Boot Manager"。
删除一个启动项：
Shell> bcfg boot rm 2删除索引2的启动项。注意，删除后 BootOrder 会自动更新。
修改启动顺序：
Shell> bcfg boot mv 3 0把索引3的启动项移到索引0的位置，也就是第一位。
小技巧：如果你不确定 fs0: 对应的是哪个分区，可以用 map 命令查看所有可用的文件系统映射。我经常用 map -r 重新扫描一遍，确保看到的是最新的设备列表。
4.3.2 使用操作系统工具
在Windows下，可以用 bcdedit 来管理UEFI启动项。但要注意，它操作的是Windows Boot Manager的配置，不是直接修改NVRAM里的 Boot#### 变量。
查看当前启动项：
bcdedit /enum firmware添加一个UEFI启动项：
bcdedit /set {fwbootmgr} displayorder {现有GUID} add last
bcdedit /create /d "My Custom EFI" /application osloader嗯，说实话，Windows下的操作比较绕。我一般只在UEFI Shell搞不定的时候才用bcdedit。
4.4 启动顺序配置的常见陷阱
这里列几个我实际遇到过的问题：
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 设置了USB启动，但插上U盘没反应 | U盘不是FAT32格式，或者没有EFI分区 | 检查U盘分区表，确保有 EFI 目录和 bootx64.efi |
| 启动项列表是空的 | NVRAM被清空，或者主板电池没电了 | 进Shell用 bcfg boot dump 确认，必要时重新添加 |
| 改了启动顺序，重启后恢复原样 | 固件有写保护，或者NVRAM空间不足 | 检查固件设置里的「写保护」选项，或者清理无用的启动项 |
| 启动项指向了错误的硬盘 | 硬盘更换后，设备路径中的硬件ID变了 | 用 devtree 命令查看当前设备路径，手动修正启动项 |
特别提醒：有些主板厂商会在固件设置里提供「启动顺序」的图形界面，但那只是对 BootOrder 变量的封装。如果你在图形界面里改了顺序但没生效，别急着骂厂商——先检查一下NVRAM是不是满了。我遇到过一台机器，NVRAM只剩不到100字节，任何写入操作都静默失败。
4.5 知识体系总览
下面这张图，把启动设备管理的核心逻辑串起来了：
你看，整个流程其实很清晰：BootOrder 决定「先试谁」，Boot#### 决定「试什么」。排查的时候，沿着这条链往下查，基本不会漏。
4.6 实战：修复一个「消失」的启动项
最后分享一个我处理过的真实案例。
一台笔记本，用户说「昨天还能正常开机，今天开机直接进了UEFI Shell」。我进Shell一看，bcfg boot dump 输出是空的——所有启动项都没了。
排查步骤：
- 检查硬盘是否被识别：
map命令看到fs0:存在，说明硬盘没问题。 - 检查EFI分区内容：
ls fs0:\EFI\Microsoft\Boot\看到bootmgfw.efi还在，文件没丢。 - 手动添加启动项：
bcfg boot add 0 fs0:\EFI\Microsoft\Boot\bootmgfw.efi "Windows Boot Manager" - 设置启动顺序：
bcfg boot order 0把刚添加的项设为第一启动。 - 重启验证： 系统正常启动了。
事后分析，很可能是NVRAM被意外清空了。这种情况在老旧主板上偶尔会发生，尤其是CMOS电池电量不足的时候。
我的建议：手边常备一个UEFI Shell启动盘。遇到启动项丢失的情况，插上U盘，进Shell，几分钟就能修好。比拆机抠电池快多了。