BIOS寻找启动项的规则是什么

BIOS（传统 BIOS）和 UEFI 在寻找启动项时的规则有所不同。

传统 BIOS（Legacy BIOS）

• 只支持 MBR（Master Boot Record） 方式启动。
• 依赖 主引导记录（MBR），一般从 第一个可引导磁盘 的 MBR 执行 bootloader（如 GRUB、LILO、Windows Boot Manager）。
• 只会从特定的磁盘（如硬盘、U 盘、CD/DVD）读取引导代码，而不会扫描整个文件系统。

UEFI 启动项查找规则

UEFI 主要通过 EFI System Partition（ESP，EFI 系统分区） 查找 .efi 文件。

具体规则如下：

1. 优先读取 NVRAM（非易失性 RAM）中的 Boot Order

• 通过 efibootmgr（Linux）或 bcdedit（Windows）查看和管理。
• 存在类似 Boot0001、Boot0002 的 UEFI 启动项，每个项指向某个 .efi 文件路径。

2. 按顺序查找 EFI 系统分区（ESP）

• ESP 是一个 FAT32 格式的分区（一般 100MB～500MB），带有 boot 和 esp 标志。
• 典型的挂载路径：
  • Linux: /boot/efi/
  • Windows: EFI 分区（不可见）

3. 查找 EFI/Boot/Bootx64.efi（默认回退路径）

• 如果 NVRAM 里的启动项无效，或者 UEFI 没有明确的启动项，会尝试：
  • ESP:/EFI/Boot/Bootx64.efi（64 位系统）
  • ESP:/EFI/Boot/Bootia32.efi（32 位系统）
• 这也是 U 盘等外部设备 一般用来启动的路径。

4. 按设备顺序查找 EFI 可执行文件

• 某些主板允许自动遍历 EFI 分区中的 .efi 文件，但不是所有主板都支持。
• 一般来说，UEFI 主要依赖 NVRAM 记录 或 EFI/Boot/Bootx64.efi，不会主动扫描所有 EFI/ 目录。

总结

UEFI 不会 直接遍历所有 EFI/ 文件夹寻找 .efi 文件，而是：

1. 先查找 NVRAM 里的启动项路径。
2. 如果找不到，检查 ESP 分区的 EFI/Boot/Bootx64.efi 作为默认回退路径。
3. 只有部分主板可能会自动搜索其他 EFI/ 目录下的 .efi 文件。

一个EFI文件夹如何能被UEFI识别为启动项

要让一个 EFI 文件夹 被 UEFI 识别为启动项，需要满足以下条件：

1. 文件夹位置

EFI 文件夹必须放置在 EFI 分区（ESP, EFI System Partition）中，该分区的要求：

• 文件系统：FAT32
• 分区类型（GPT）：EF00 (EFI System Partition)
• 挂载路径（Linux）：一般挂载在 /boot/efi

2. 目录结构

EFI 分区中的启动项路径应符合 UEFI 规范：

/EFI
 ├── BOOT
 │    ├── BOOTX64.EFI  # 64位系统通用默认引导程序
 │    ├── BOOTIA32.EFI # 32位系统通用默认引导程序
 │
 ├── Microsoft   # Windows
 ├── ubuntu      # Ubuntu
 ├── grub        # GRUB
 └── 自定义文件夹（如 MyOS）
       ├── BOOTX64.EFI
       ├── config.conf

UEFI 只会在 /EFI 目录下查找引导程序（.efi 文件）。

3. 文件命名规则

UEFI 默认会尝试加载：

• /EFI/BOOT/BOOTX64.EFI（对于 64 位系统）
• /EFI/BOOT/BOOTIA32.EFI（对于 32 位系统）

如果你的 EFI 文件夹不是 EFI/BOOT，你需要在 UEFI 里手动添加启动项。

4. 手动添加 UEFI 启动项

如果 UEFI 固件没有自动识别你的 EFI 文件，你可以手动添加：

方法 1：使用 efibootmgr（Linux）

如果你在 Linux 环境：

sudo efibootmgr --create --disk /dev/sdX --part Y --loader "EFIMyOSBOOTX64.EFI" --label "MyOS"

• /dev/sdX：EFI 分区所在磁盘，例如 /dev/nvme0n1
• –part Y：EFI 分区的编号，例如 1
• “EFIMyOSBOOTX64.EFI”：引导文件的路径，Windows 风格的路径格式（ 反斜杠）

运行 sudo efibootmgr -v 可查看当前 UEFI 启动项。

方法 2：BIOS/UEFI 固件设置

重启电脑，进入 BIOS/UEFI，手动添加一个新的 UEFI 启动项，路径指向EFIMyOSBOOTX64.EFI。

方法 3：使用 bcdedit（Windows）

如果你在 Windows，可以使用 bcdedit 添加 EFI 启动项：

bcdedit /set {current} path EFIMyOSBOOTX64.EFI

5. 其他注意事项

• Secure Boot：如果启用了 Secure Boot，EFI 需要经过签名，否则可能无法启动。
• Fast Boot：某些主板的 Fast Boot 可能会跳过 EFI 设备的检测，提议关闭。

这样，你的 EFI 文件夹就可以被 UEFI 识别并用于引导系统。

rEFInd是如何让UEFI找到的

rEFInd（an EFI boot manager）让 UEFI 识别并启动的方式主要有两种：

1. 通过 NVRAM 记录启动项（推荐方式）

安装 rEFInd 时，它会使用 efibootmgr（Linux）或 bcdedit（Windows）向 UEFI NVRAM 添加一个启动项。

• 这个启动项指向 ESP 分区 内的 rEFInd 启动文件：

ESP:/EFI/refind/refind_x64.efi

• 可以通过以下命令查看 UEFI 启动项（Linux）：

efibootmgr -v

• 如果 rEFInd 被正确添加，应该能看到类似的条目：

Boot0001* rEFInd    HD(1,GPT,...)/EFI/refind/refind_x64.efi

• 这时，UEFI 会按照 BootOrder 直接找到 rEFInd 并执行。

✅ 这是一种标准 UEFI 方式，可靠且可控。

2. 作为默认 EFI 启动程序（回退方案）

如果主板 不支持 NVRAM 启动项（或者被清空），rEFInd 也可以安装到 UEFI 默认的 EFI 位置，这样 UEFI 会自动加载它。

• 这个默认位置是：

ESP:/EFI/Boot/Bootx64.efi

• rEFInd 替换 了这个文件（或者你手动复制 refind_x64.efi 到这里，并重命名为 Bootx64.efi）。
• 这种方法一般用于：
  • U 盘或外部存储设备（许多 U 盘 EFI 启动项使用 EFI/Boot/Bootx64.efi）。
  • BIOS 重置后丢失 NVRAM 启动项。

⚠️ 缺点：

• 可能会被操作系统（如 Windows 更新）覆盖，导致 rEFInd 启动失败。
• 双系统 时，Windows 可能会重新安装 EFI/Microsoft/Boot/bootmgfw.efi，影响 rEFInd。

如何手动恢复 rEFInd 启动？

如果 UEFI 启动项丢失，可以：

方法 1：使用 efibootmgr 重新添加

sudo efibootmgr --create --disk /dev/sdX --part Y --loader "EFI
efind
efind_x64.efi" --label "rEFInd"

替换 /dev/sdX 为你的 EFI 磁盘（如 /dev/nvme0n1），Y 为 ESP 分区编号（如 1）。

方法 2：使用 BIOS 引导菜单手动选择 rEFInd

• 进入 BIOS（按 F2 / Del / Esc / F12，视主板而定）。
• 找到 Boot Override 选项，选择 ESP:/EFI/refind/refind_x64.efi 进行引导。
• 进入系统后，重新运行 efibootmgr 添加启动项。

总结

rEFInd 让 UEFI 识别的方式主要有：

1. NVRAM 方式（最佳）：通过 efibootmgr 或 bcdedit 将 rEFInd 添加为 UEFI 启动项。
2. 默认 EFI 位置（备用方案）：将 refind_x64.efi 复制到ESP:/EFI/Boot/Bootx64.efi，作为默认 EFI 启动程序。
3. BIOS 启动菜单：如果 UEFI 没找到 rEFInd，可以手动选择EFI/refind/refind_x64.efi 进行引导。

一般情况下，安装 rEFInd 时它会自动处理这些步骤，如果发现无法引导，可以手动修复。

当我安装完rEFInd后，我原有的Fedora操作系统的引导项在UEFI找不到了

很可能是 rEFInd 覆盖了默认的 EFI 启动程序，导致 Fedora 的 UEFI 启动项在 NVRAM 里消失或者变得不可用。

如何确认 rEFInd 是如何安装的？

1. 检查 rEFInd 是否替换了默认 EFI 启动项

在 Linux 中运行：

efibootmgr -v

如果 Fedora 的启动项 不见了，但 rEFInd 依旧能启动，那说明 rEFInd 可能是以 默认 Bootx64.efi 方式 安装的。

你可能会看到：

BootOrder: 0001, 0002
Boot0001* rEFInd    HD(1,GPT,...)/EFI/Boot/Bootx64.efi

但 Fedora 的 EFIfedorashimx64.efi 可能不在 NVRAM 里了。

2. 检查 ESP 分区的内容

查看 ESP 分区的 /EFI/ 目录：

ls /boot/efi/EFI/

如果 rEFInd 安装在 EFI/Boot/Bootx64.efi，而 Fedora 的 EFI/fedora/ 还在，但 NVRAM 里没有 Fedora，那就说明 rEFInd 可能覆盖了默认的 Bootx64.efi。

一般 Fedora 的 UEFI 启动文件应该在：

/boot/efi/EFI/fedora/shimx64.efi

或：

/boot/efi/EFI/fedora/grubx64.efi

如果这些文件还在，但 efibootmgr 里没有 Fedora，那就说明 NVRAM 里的 Fedora 启动项被删除了。

如何恢复 Fedora 的 UEFI 启动项？

方法 1：用 efibootmgr 重新添加 Fedora

如果 Fedora 的 EFI/fedora/shimx64.efi 还在，只是 UEFI 里找不到启动项，可以用 efibootmgr 手动恢复：

sudo efibootmgr --create --disk /dev/sdX --part Y --loader "EFIfedorashimx64.efi" --label "Fedora" --bootnum 0003

• 替换 /dev/sdX 为你的 EFI 磁盘（如 /dev/nvme0n1）。
• 替换 Y 为 EFI 分区编号（一般是 1）。
• 运行 efibootmgr -v 确保 Fedora 重新出目前 NVRAM 里。

方法 2：使用 BIOS 手动选择 Fedora

• 进入 BIOS 设置（一般按 F2 / F12 / Del）。
• 在 UEFI Boot Menu 里，看看 EFI/fedora/shimx64.efi 是否还能手动引导。
• 如果能手动启动，进 Fedora 后执行 efibootmgr 重新添加启动项。

方法 3：恢复 Fedora 的默认启动方式

如果 rEFInd 覆盖了 EFI/Boot/Bootx64.efi，你可以恢复 Fedora 默认的 shimx64.efi：

sudo cp /boot/efi/EFI/fedora/shimx64.efi /boot/efi/EFI/Boot/Bootx64.efi

然后重启看看 BIOS 是否能找到 Fedora。

为什么 rEFInd 可能导致 Fedora 启动项消失？

rEFInd 的安装方式可能：

1. 替换了 EFI/Boot/Bootx64.efi，导致 UEFI 直接加载 rEFInd，而不再使用 Fedora 的 NVRAM 启动项。
2. 意外清除了 UEFI NVRAM 启动项，导致 Fedora 的 shimx64.efi 还在，但 BIOS 里看不到 Fedora 选项。

如果你希望 rEFInd 作为一个可选的 Boot Manager，而不干扰 Fedora 的启动项，可以：

• 让 rEFInd 直接安装在 EFI/refind/ 目录，并用 efibootmgr 手动管理启动顺序。
• 不要 覆盖 EFI/Boot/Bootx64.efi，让 Fedora 保持默认启动方式。

总结

• 你的 rEFInd 可能替换了 Bootx64.efi，导致 Fedora 的 UEFI 启动项在 NVRAM 里丢失。
• 可以用 efibootmgr 或 BIOS 选择 Fedora 的 shimx64.efi 来恢复。
• 避免问题的最佳方式：让 rEFInd 只安装在 EFI/refind/，不要覆盖EFI/Boot/Bootx64.efi，并用 efibootmgr 添加 NVRAM 记录来管理启动顺序。

NVRAM里的信息我如何能够查看

在 Linux 中，你可以使用 efibootmgr 来查看和管理 NVRAM（非易失性 RAM）中的 UEFI 启动项。

查看 NVRAM 里的 UEFI 启动项

运行以下命令：

efibootmgr -v

示例输出：

BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,0003,0004
Boot0001* rEFInd Boot Manager HD(1,GPT,...)/EFI/refind/refind_x64.efi
Boot0002* Fedora        HD(1,GPT,...)/EFI/fedora/shimx64.efi
Boot0003* Windows Boot Manager HD(2,GPT,...)/EFI/Microsoft/Boot/bootmgfw.efi
Boot0004* UEFI Shell    HD(1,GPT,...)/EFI/Boot/Bootx64.efi

解读信息

• BootCurrent: 当前正在使用的引导项（0001 表明 rEFInd 启动）。
• BootOrder: 引导顺序，按 0001 → 0002 → 0003 → 0004 依次尝试。
• Boot0001（rEFInd）：指向 EFI
  efind
  efind_x64.efi，当前正在使用。
• Boot0002（Fedora）：指向 EFIfedorashimx64.efi，但可能未启用或顺序靠后。
• Boot0003（Windows）：指向 EFIMicrosoftBootootmgfw.efi。
• Boot0004（UEFI Shell）：可能是 EFIBootBootx64.efi，适用于 U 盘或恢复模式。

如何判断 Fedora 启动项是否丢失？

如果 efibootmgr -v 的输出 没有 Fedora（EFI/fedora/shimx64.efi），但 /boot/efi/EFI/fedora/ 还在，说明：

1. Fedora 的 NVRAM 启动项被删除，需要重新添加。
2. UEFI 可能重置了 BootOrder，导致 Fedora 不能自动启动。

修改引导顺序

如果 Fedora 在 efibootmgr 中 存在但未生效（如 BootOrder 里不在前面），你可以手动调整：

sudo efibootmgr --bootorder 0002,0001,0003,0004

• 这里 0002（Fedora）被放在第一位，优先启动 Fedora。

如果我的PC有两块硬盘，那么我是否会拥有两个NVRAM

不会，无论你的 PC 里有 一块还是多块硬盘，NVRAM 只有一个，它是 主板 UEFI 固件的一部分，而不是存储在硬盘上的。

NVRAM 是什么？

NVRAM（非易失性随机存取存储器） 存储在 主板的 UEFI 固件 内，而不是硬盘上。它主要用于：

• 存储 UEFI 启动项（efibootmgr -v 可查看）。
• 存储 macOS/Linux/Windows 相关的引导参数（如 boot-args）。
• 存储一些设备配置（如键盘语言 prev-lang:kbd、SIP 状态 csr-active-config）。

为什么不会有两个 NVRAM？

• NVRAM 由主板管理，而不是硬盘。
• 即使你的 PC 有 两块硬盘，各自安装了 OpenCore / Fedora / Windows，它们共用同一个 NVRAM，由于 NVRAM 存储在 UEFI 固件芯片 里，而不是某块特定的硬盘上。
• 无论你引导哪块硬盘，系统都会使用同一块 NVRAM 里的变量。

多个硬盘如何影响 UEFI 启动项？

虽然 NVRAM 只有一个，但 不同硬盘上的 ESP 分区（EFI System Partition）会影响 UEFI 启动顺序：

• 如果两块硬盘都有 EFI 分区（ESP），每块硬盘上的 EFI/Boot/Bootx64.efi 可能都能引导 OpenCore / Fedora / Windows。
• 但 UEFI 只会存储一个 NVRAM 变量集，所有硬盘的 EFI 启动项都保存在 同一个 UEFI NVRAM 里。

示例：如何查看 NVRAM 里的多个硬盘启动项

运行：

efibootmgr -v

示例输出：

BootOrder: 0001,0002,0003
Boot0001* Fedora        HD(1,GPT,...)/EFI/fedora/shimx64.efi
Boot0002* Windows Boot Manager HD(2,GPT,...)/EFI/Microsoft/Boot/bootmgfw.efi
Boot0003* rEFInd Boot Manager HD(3,GPT,...)/EFI/refind/refind_x64.efi

• Boot0001 是 Fedora，它可能在 第一块硬盘的 ESP 上。
• Boot0002 是 Windows，它可能在 第二块硬盘的 ESP 上。
• Boot0003 是 rEFInd，它可以在 任意一块硬盘，但 UEFI 依旧把它存储在同一个 NVRAM 里。

如果 Reset NVRAM，会发生什么？

如果你在 OpenCore 或 BIOS 里执行 Reset NVRAM：

1. 所有 UEFI 启动项都会被删除。
2. 你需要 手动进入 BIOS，重新选择引导硬盘，或者用 efibootmgr 重新添加启动项。
3. 不会影响硬盘上的 EFI 分区（ESP），只是主板 UEFI 失去了启动项的记录。

总结

• NVRAM 只有一个，不会由于多块硬盘而增加。
• 所有硬盘的 EFI 启动项都存储在同一个 NVRAM（由 UEFI 统一管理）。
• 不同硬盘的 ESP 分区可以有不同的 OpenCore / Windows / Linux 引导器，但它们共享 NVRAM。
• Reset NVRAM 只会清除 UEFI 里的启动项，不会删除硬盘上的 EFI 分区，但可能需要手动恢复引导项。

我可以使用WinPE管理efibootmgr么

不行，WinPE 本身不支持 efibootmgr，但可以用 Windows 自带的 bcdedit 和 bcdboot 管理 UEFI 启动项。

我执行完efibootmgr -v后，有的启动项指向路径是VenHw，是什么缘由

如果 efibootmgr -v 输出的某些启动项指向 VenHw(…)，而不是常见的 HD(…) 或 File(…)，说明这些启动项使用了 Vendor Hardware（VenHw） 设备路径。

1. 什么是 VenHw(…)？

VenHw(…) 代表的是 UEFI 变量存储的供应商特定（Vendor Hardware）路径，一般用于：

• 某些主板的特殊引导方式（如部分 OEM 定制启动项）。
• 固件级别的特殊设备（列如某些 RAID 控制器、NVMe 设备或 PXE 网络启动）。
• 加密启动项（如 Windows BitLocker 保护的 EFI 启动项）。
• UEFI Secure Boot 数据（一些安全相关的 EFI 变量可能存储在 VenHw 路径中）。

示例输出

Boot0005* Windows Boot Manager    VenHw(837D1A51-...-000000000000)

这意味着 Windows Boot Manager 可能被某种 UEFI 固件保护，而不是简单地指向 EFIMicrosoftBootootmgfw.efi。

2. 为什么 VenHw(…) 会出目前 efibootmgr 里？

有几种可能的缘由：

1. 主板厂商的 UEFI 机制

• 部分 OEM（如 Lenovo、HP、Dell）使用 VenHw 来存储 Windows Boot Manager 或特定恢复选项。

2. Secure Boot 或 TPM 相关

• 如果 Secure Boot 启用，某些安全启动项可能以 VenHw 形式存储。

3. 特殊的存储控制器（RAID / NVMe）

• 某些 RAID 模式下的磁盘 EFI 启动项不会直接映射到 HD(…)，而是显示为 VenHw(…)。

4. 损坏的 UEFI 启动项

• 如果 efibootmgr 不能正确解析 EFI 路径，它可能会显示 VenHw(…)。

3. 如何处理 VenHw(…) 启动项？

（1）如果系统能正常引导

✅ 不需要删除，只要 Windows 或 Linux 正常启动，就没必要动它。
✅ VenHw(…) 可能用于主板的 自动引导流程，删除可能导致某些 UEFI 保护失效。

（2）如果 VenHw(…) 影响引导

如果 VenHw(…) 引导项 导致无法进入系统，可以删除并手动创建新的 EFI 启动项。

sudo efibootmgr -b 0005 -B

• 0005 是 VenHw(…) 启动项的编号（根据 efibootmgr -v 的输出调整）。

总结

• VenHw(…) 代表 UEFI 固件级别的特殊设备路径，可能用于 OEM 特定启动项、Secure Boot 或 RAID 设备。
• 如果 系统正常启动，不需要删除 VenHw(…)。
• 如果 影响引导，可以用 efibootmgr -b 000X -B 删除，然后手动 重新创建 UEFI 启动项。
• 部分主板（如 HP/Dell）可能会自动恢复 VenHw(…) 启动项，这时需要检查 BIOS 设置（如 Secure Boot、RAID 配置）。

Boot项中的HD(1,GPT,65e03e16-cbcf-4217-a4e3-b38d14d09984,0x800,0x12c000)代表什么意思

HD(1,GPT,65e03e16-cbcf-4217-a4e3-b38d14d09984,0x800,0x12c000) 是 UEFI efibootmgr -v 输出中的 磁盘分区标识符，用于指示 UEFI 启动项存储在哪个磁盘和分区。我们拆解它的含义：

1. 各部分解释

HD(1,GPT,65e03e16-cbcf-4217-a4e3-b38d14d09984,0x800,0x12c000)

字段	含义
HD	代表这是一个硬盘 (Hard Drive) 设备
(1,…)	1 表明 第 1 个分区（即 EFI 分区）
GPT	说明该磁盘使用 GPT（GUID Partition Table） 分区格式
65e03e16-cbcf-4217-a4e3-b38d14d09984	该分区的 GUID 标识符（每个 GPT 分区都有唯一 GUID）
0x800	该分区在磁盘上的起始扇区（LBA）是 0x800（2048 扇区，一般是 1MB 位置）
0x12c000	该分区的大小是 0x12c000 扇区（转换为字节 = 0x12c000 * 512 = 151 MB，这表明它是一个 EFI 系统分区，一般 100MB-500MB）

2. 如何验证该分区？

如果你想确认这个分区是否是 EFI 分区，可以使用 lsblk 或 blkid：

方法 1：使用 lsblk

lsblk -o NAME,FSTYPE,MOUNTPOINT,SIZE,UUID

示例输出：

NAME   FSTYPE  MOUNTPOINT   SIZE     UUID
nvme0n1                              512G
├─nvme0n1p1 vfat    /boot/efi 300M  65E03E16-CBCF-4217-A4E3-B38D14D09984
├─nvme0n1p2 ext4    /         100G
└─nvme0n1p3 swap    [SWAP]    8G

可以看到：

• nvme0n1p1 是 vfat 格式（EFI 分区必须是 FAT32）
• UUID 是 65E03E16-CBCF-4217-A4E3-B38D14D09984，和 efibootmgr 里的 65e03e16-cbcf-4217-a4e3-b38d14d09984 一致，说明它就是 EFI 分区。

方法 2：使用 blkid

sudo blkid | grep 65e03e16

如果输出：

/dev/nvme0n1p1: UUID="65E03E16-CBCF-4217-A4E3-B38D14D09984" TYPE="vfat"

说明 /dev/nvme0n1p1 是 EFI 启动分区。

3. 这个信息的作用

UEFI 在启动时会读取 BootXXXX 启动项，并根据 HD(1,GPT,UUID,0x800,0x12c000) 定位 EFI 分区，然后加载对应的 .efi 文件（如 bootx64.efi）。

在 efibootmgr -v 输出中，如果某个启动项如下：

Boot0001* Fedora HD(1,GPT,65e03e16-cbcf-4217-a4e3-b38d14d09984,0x800,0x12c000)/EFI/fedora/shimx64.efi

表明：

1. 这个启动项存储在 EFI 分区 /dev/nvme0n1p1。
2. UEFI 会在 EFI/fedora/ 目录下寻找 shimx64.efi 作为引导文件。