主页 / computer / 问题 / 1753412
Accepted
Jimm Chen
Asked: 2022-11-18 20:51:19 +0800 CST

Windows bcdedit 将配置参数存储在 NVRAM 中？这是什么意思？

  • 772

在 Win10bcdedit /?中，帮助文本说它将在非易失性 RAM (NVRAM) 条目中存储引导配置参数。

bcdedit /?

这很荒谬吗？据我所知，bcdedit 将配置存储在磁盘文件中。

要具体...

※ 如果典型的 x64 PC 的 BIOS 确定它应该以 Legacy BIOS 模式启动 PC，

  1. 它将第一个磁盘扇区（MBR 扇区）加载到 RAM 中并执行。
  2. 此 MBR 代码依次将活动分区的第一个扇区（OS 引导扇区）加载到 RAM 中并执行。
  3. 操作系统引导扇区依次将\bootmgr文件（无文件扩展名）加载到 RAM 中并执行。
  4. bootmgr代码找到\Boot\BCD（再次没有文件扩展名）以获取 [我们之前通过运行设置的引导配置] bcdedit。

※ 如果典型的 x64 PC 的 BIOS 确定它应该以 UEFI 模式启动 PC，

  1. 它找到一个 EFI 系统分区并加载\EFI\Boot\bootx64.efi到 RAM 中并执行。
  2. bootx64.efi 然后读取\EFI\Microsoft\Boot\BCD启动配置参数。

似乎与 NVRAM 无关。它是否意味着某些东西（在 bcdedit 上下文中）不存在于硬盘上，而是存在于某些 PC 主板芯片上（让我称之为 BIOS 区域）？

如果bcdedit真能在BIOS区存储/改变一些数据，请举个例子。我的意思是，什么样的bcdedit参数会导致 BIOS 区域数据被更改？

bios

1 个回答

  1. Best Answer

    您为 UEFI 模式跳过了很多步骤。你是对的，“它找到一个 EFI 系统分区并加载 \EFI\Boot\bootx64.efi” 是其中之一，但它是回退行为（正式地，它是“可移动磁盘”行为） - 有一个步骤在达到这一点之前涉及主板的 NVRAM 的一两个。

    首先，如UEFI 规范( PDF ) 中所述，固件提供广泛的“引导”和“运行时”服务（原则上类似于 BIOS 中断），其中包括允许操作系统保存的“变量服务”（第 8.2 节）系统 NVRAM 中的各种键值对。（通常它是固件用于其自身设置的同一个闪存，又名“CMOS”，许多系统实际上将所有固件设置存储为 EFI 变量。）

    通常操作系统会以某种方式将变量服务 API 暴露给用户空间程序，例如 Windows 提供SetFirmwareEnvironmentVariable()而 Linux 在/sys/firmware/efi/efivars.

    此外，如第 2.1 节和第 3 节所述，固件有自己的引导管理器，它“将尝试按照全局 NVRAM 变量定义的顺序加载 UEFI 驱动程序和 UEFI 应用程序（包括 UEFI OS 引导加载程序）”。固件启动管理器基本上与您可能使用过的 F8 或 F10“启动菜单”相同，但除了列出整个磁盘之外，现在它还列出操作系统的各个 .efi 文件。

    （这个功能实际上早于 UEFI很多——你引述中的“以前”指的是Alpha AXP和/或 Itanium IA64 EFI，它们都运行 Windows；两者都与 Boot.ini 同时存在（即在 BCD 之前）；并且两者都有固件引导管理器。不过，我没有任何规范的链接。）

    EFI“引导管理器”主要使用NVRAM 变量命名Boot####（4 位数字），BootOrder并BootNext列出已安装的操作系统。每当 Windows 安装自己的 BOOTMGR（可以使用 手动完成bcdboot.exe）时，它还会使用 EFI 变量服务（通过 Windows 提供的 API）创建一个指向 的 Boot0000 入口\EFI\Microsoft\Boot\Bootmgfw.efi，名为“Windows 启动管理器”。

    事实上，您可以通过 看到这些条目bcdedit /enum firmware，尽管它们会被大量翻译成类似 Windows BCD 的格式（因为同一工具处理EFI和 BCD 条目），或者通过efibootmgr [-v]在 Linux 或 FreeBSD 中运行：

    BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0005,2003,0002,2001,2002
Boot0000* UEFI Onboard LAN IPv4     PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(3417eb7eda76,0)/IPv4(0.0.0.00.0.0.0,0,0)RC
Boot0001* UEFI Onboard LAN IPv6     PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(3417eb7eda76,0)/IPv6([::]:<->[::]:,0,0)RC
Boot0002* HDD1-1 (Samsung SSD 860)  PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)/HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x100000)RC
Boot0003* Linux Boot Manager        HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x80000)/File(\EFI\systemd\systemd-bootx64.efi)
Boot0004* Arch Linux LTS            HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x100000)/File(\EFI\Linux\vmlinuz-linux-lts.efi)
Boot0005* EFI Shell                 HD(1,GPT,b7245b9a-d13f-4d97-8bff-901255bfd7ad,0x1000,0x80000)/File(\shellx64.efi)

    因此 UEFI 固件的实际步骤（再次在第 3 节中描述）是：

    1. 它从 BootNext 或 BootOrder 指示的变量中读取 EFI 文件系统路径Boot####，然后尝试按指定顺序将每个文件作为 .efi 可执行文件加载和运行。（未在 BootOrder 中列出的引导项处于非活动状态。）

    2. 如果没有任何活动的 Boot#### 变量可以执行，它通常会回退到“可移动磁盘”行为，即扫描所有磁盘以查找包含\EFI\Boot\Boot[cpuarch].efi并执行它的 EFI 系统分区。如果您从固件的启动菜单中手动选择整个磁盘，也会发生这种情况。

      （实际上，我见过的所有系统也都将此应用于固定的内部磁盘。这允许在磁盘移动到另一个主板或 NVRAM 数据因任何原因丢失时启动已安装的操作系统，以及为 EFI 安装操作系统即使安装介质由于某种原因无法在 EFI 模式下启动，因此变量服务不可用。）

    3. （作为最后的手段，一些固件（主要是那些构建在 EDK2 上的固件）将运行 EFI Shell 的嵌入式副本，这是一个有点类似于 MS-DOS 的交互式 CLI，允许您手动运行 .efi 文件。一些其他固件代替将打开一个文件浏览器 GUI，您可以在其中选择要运行的 .efi 文件。其他人只需拖放到固件设置屏幕。）

    这个 EFI 启动过程很大程度上受到了Alpha 中的启发（它是 x86 之前的主要 WinNT 平台）。Windows NT/2000/XP中的NTLDR和Boot.ini在某种程度上模仿了Alpha AXP基于固件的引导项，甚至包括系统盘使用ARC路径。

    同样，Windows XP 也可用于 Itanium IA64 上的 EFI，它完全依赖于 EFI 引导管理器（据我所知，它没有自己的引导菜单），所以“这些参数以前在......”最有可能是指 XP 使用本机 EFI 启动管理器功能以及使用 Boot.ini 的 x86 版本。

    （所以我怀疑当前的 Windows 启动管理器及其 BCD 是因为 Microsoft 不断发现 AXP 和 EFI 提供的接口不足而创建的，但它仍然在某种程度上模仿 EFI 样式的启动，例如，即使 BIOS 安装现在也有一个专用的“系统分区”，不再将 BOOTMGR 直接放在 C:\ 上。）

    也许是因为后者，该bcdedit工具通过统一的界面管理两种引导条目——EFI 固件和 Windows BCD。例如，默认情况下bcdedit会列出 BOOTMGR 使用的 Windows BCD 条目，但如果您指定该/enum firmware选项，那么它将列出固件启动菜单使用的 EFI NVRAM 条目（尽管格式与真实的东西有很大不同）。

    • 3

相关问题