Libreboot 26.10 "Ominous Olive" 发布，默认采用 EDK2 并新增 Chromebook 支持

返回索引

文章发布者：Leah Rowe

发布日期：2026 年 10 月 15 日

• <<
• < 上一篇
• 下一篇 >
• >>

你可以在 https://rsync.libreboot.org/stable/26.10/ 找到今天的发布版本，或者使用其中某个 镜像。

Libreboot 是自由、开源的启动固件，用来替代受支持的 Intel/AMD 以及 ARM64 硬件上的专有 BIOS/UEFI 固件。它会初始化计算机内部的硬件，例如 CPU 或内存控制器，以特定方式配置机器，从而在使用 Linux 或 BSD 等操作系统时能够正常启动——而现在 Microsoft Windows 也可以兼容了，因为 Libreboot 通过 MrChromebox EDK2 有效载荷增加了完整的 UEFI 支持。与专有固件相比，Libreboot 提供了更高的安全性和可定制性；它的目标很明确，就是消除世界上的专有软件，为此我们致力于提供一种即使非技术用户也能轻松理解的固件。

今天的发布更新日志是相对于上一个 Libreboot 26.01 版本而言的。

这是一个非常特殊的版本，无论硬件如何变化，都进行了多项重大设计变更，因此用户应该非常仔细地阅读此更新日志——并且读两遍。

首先说最重要的事。（是的，你没有看错上一段）

一条强烈反对 AI 的策略被添加到 lbmk 中的一个新文件：AGENTS.md。这是本次发布中最重要的更改。其他内容如下：

警告：本次发布进行了重大设计变更，可能会影响许多现有配置。我们现在默认使用 EDK2 作为有效载荷，同时将 GRUB/SeaBIOS 以 EFI 形式提供并写入闪存中以保持向后兼容性。一切都可以正常工作，但有一些注意事项，因此请非常仔细地阅读本次发布更新日志。

第一个重大变更是：

完整的板子列表相当长，因此会在本文末尾列出。总共 233 款！

MrChromebox 支持几乎所有的 Chromebook，本次发布从该项目导入了所有板子。这些涵盖了截至目前最新的 Intel 和 AMD 硬件。

从 MrChromebox coreboot 发行版导入了全部 233 款当前支持的 Chromebook。Baytrail（Kip）已测试——其他型号还需要测试。本次发布仅提供源代码（必须从源代码构建，不提供二进制文件）。

这是通过我在 util/mrimport/ 编写的一个工具完成的，该工具能为 lbmk 生成配置，包括修订版本和子模块。我手动做了进一步调整；后续上游更新可以通过对 mrimport 在不同修订版本之间的输出再次进行 diff，同步到 Libreboot 中，无论 Libreboot 后者的修改如何繁多——这些将在下面介绍。

Libreboot 在其版本中对 MrChromebox coreboot 进行了如下修改：

• 对 coreboot 使用 MrChromebox 提供的 EDK2 UEFI 有效载荷；我们将背景色设置为 Libreboot 紫色，并使用 Libreboot 彩虹 logo 替代 coreboot logo。除了接下来的更改之外，我们的 EDK2 构建目前与上游完全相同：
• 在构建时默认设置 HAP 位以禁用 Intel ME。在 MrChromebox coreboot 中默认并不能可靠地禁用它，因为大多数使用它的人都通过基于软件的刷写脚本来实现，正如 MrChromebox 文档中所展示的配合禁用 Google 安全机制的方式。我们在此直接禁用。注意：我们还支持许多 AMD Chromebook，这与此处讨论的内容无关。
• 通过 ifdtool 解锁 IFD 区域（妥善处理各种特殊情况），在构建时将它们设置为可读写。这样做是为了避免修改 MrChromebox 提供的每一个 Intel Flash Descriptor，这些描述符有数百个。
• 在 EDK2 内添加了 CSMWrap（封装在 EFI 中的 SeaBIOS CSM），用于向后兼容旧版 Libreboot 发布版中的裸机 SeaBIOS。
• 同时在 EDK2 内提供 GRUB EFI 构建版本，以实现向后兼容 — 从用户的角度来看，其行为与 coreboot payload 版本的 GRUB 完全一致，且同样以相同方式从 CBFS 读取配置。
• 在 EDK2 内添加了 MemTest86+。
• Haswell Chromebook：使用原生 raminit，取代上游的 MRC。
• 截至 Kabylake 的所有 Intel Chromebook：使用 libgfxinit 代替 GOP；上游此后在新一代上也都采用了此做法，这将在发布后集成。

如上所述，额外的 payload 可在启动时通过按 ESC 键在启动菜单中使用。iPXE 在特定主板上同样按上游的做法默认启用。EFI GRUB 和 CSM SeaBIOS 已经取代了这些的 coreboot payload 版本；裸机 SeaBIOS/GRUB 现已弃用，并可能在未来的 Libreboot 发布版中移除，不过愿意从源代码构建 Libreboot 的人可以重新启用它们。

这并非 MrChromebox 的分支，后者应被视为 Libreboot 在 Intel/AMD Chromebook 上的上游。与常规 coreboot 一样，我们将始终尽力与它保持同步。我曾与 MrChromebox 广泛合作，甚至向他的项目提交过一些小修复；他还应我的请求实现了基于 CBFS 的 VBT 和 GOP 处理，我将在发布后集成这些内容。

不管怎样，配合 Libreboot 镜像，MrChromebox 自有的安装脚本应该也可以工作，所以请查阅 MrChromebox 的文档了解安装事宜。尽管有所更改，Libreboot 的设置在行为上仍与 MrChromebox 兼容，因此 MrChromebox 的工具仍可配合相应文档一起使用。

这之所以成为可能，得益于 Libreboot 构建系统中的一项新特性：每个项目支持任意数量的上游。我们在非 Chromebook 主板上仍然提供常规的 coreboot。

是的，233 个。我数过了。全部自动化完成。我的脚本以及严谨细致的态度确保了我在 lbmk 中导入和配置的内容与上游高度匹配，而且我在 Libreboot 中非常谨慎地保持自己对它的差异。

是的，Libreboot 现在可以在 Chromebook 上运行了！

例如 KGPE-D16。我们在 AMD Fam15h 主板上现在使用来自 15h.org 的 coreboot 分支。该分支使用 AMD AGESA 源代码代替 Timothy 的自定义初始化代码。其 raminit 和 CPU 初始化更加可靠；支持的内存也更多。许多 bug 已修复。IOMMU 可正常工作，我还看到他们提到 TPM 在其版本中已修复，我们的版本现在同样如此。

提供带有 SeaBIOS 和 GRUB payload 的常规二进制文件 — 同时我们也提供实验性的基于 EDK2 的镜像，目前仅提供源代码（没有可用的二进制文件）。EDK2 需要设置 framebuffer，而集成的 AST2050 芯片在原生初始化下仅能以文本模式启动；厂商 VGA ROM 可以设置 VESA，但我们将不使用 VGA ROM。在这些主板上，基于 EDK2 的镜像仅为源代码版本，配合显卡使用。

基本上，这些主板首次真正能够正常工作了。

EDK2 是 Intel 对 UEFI 规范的参考实现，用于启动。它通常被供应商在 Intel BSD 许可代码的专有分支中使用，但 Intel 的参考代码是自由软件。我们使用他们的参考代码，完整的源代码包含在此次 Libreboot 发布中。EDK 是 EFI Development Kit（EFI 开发套件）的缩写。

更具体地说：

我们使用 MrChromebox 提供的 EDK2 分支，该分支专门将 EDK2 作为通用的 coreboot 有效负载提供。这是一个完整的、符合行业标准的 UEFI 实现，能够启动任何符合规范的操作系统。

全部。现在几乎所有主板都在 Libreboot 中使用它，甚至包括旧型号，例如 ThinkPad X200。已在所有平台上测试。仅支持 32 位的旧主板仍使用上一版本的设置，而几乎所有兼容 64 位的硬件现在都使用 EDK2。GRUB 和 SeaBIOS 的 EFI 构建以 flash 形式提供，可从 EDK2 设置菜单（启动时出现提示时按 ESC）访问，以与 Libreboot 中现有的 Linux/BSD 安装保持向后兼容。

EDK2 支持最初作为 Chromebook 的前置条件被集成，但后来被扩展到 Libreboot 中所有此前已支持的主板。它甚至可以在很旧的机器上良好运行，例如 ThinkPad T500。

在可行的情况下，所有 Libreboot 主板现在默认使用开源 UEFI 实现。全部都是，默认也是 —— 裸机 GRUB 和 SeaBIOS coreboot 有效负载已被移除，取而代之的是向后兼容的 EFI 版本。

此前我们根本不提供 UEFI，除了一些精选主板上的 U-Boot 之外。现在，我们在 Libreboot 支持的几乎所有主板上都提供完整的 UEFI，并完整保留所有四项自由。

以下所有操作系统已在使用 EDK2 的各种 Libreboot 机器上经过测试并确认可正常工作：

• Windows 10 和 11
• 9front（Plan 9 的分支）
• 各种其他符合 UEFI 规范的操作系统
• Linux UKI 引导程序、systemd-boot 等。UKI 现在可以完美工作，从 EDK2 启动。现代 Linux 发行版设置现在可以工作（不需要 GRUB）。
• 使用 EFI 引导程序和 GPT 分区的 OpenBSD（旧版 SeaBIOS txtmode 在 Libreboot 中只能使用 MBR 分区）
• UEFI 模式下的 FreeBSD —— 不再需要 txtmode！
• 不幸的是，ReactOS 无法工作（不支持 UEFI）
• RedoxOS 可能也能工作。

现代计算机和操作系统都采用 UEFI，这套新设置基本上可以可靠地启动所有这些系统。还需要更多测试，但这是经过实战检验的代码，多年来已被 coreboot 的许多用户广泛使用。Libreboot 现在终于也拥有了它。

仅这一变化就是更广泛的 Libreboot 现代化工作的一部分，而我也才刚刚开始。未来的 Libreboot 版本将大量基于此，因为 EDK2 现在基本上是许多现代 coreboot 设置中所期望的有效负载。集成 EDK2 消除了 Libreboot 的所有限制，使我们能够支持更新的硬件，并基本上使 Libreboot 更易于使用；因此，我预计 Libreboot 将会随着时间的推移变得更加流行和有用。

本发布页面末尾提供了一些注意事项和额外说明，用于迁移目的。例如，尽管我们声称所有主板都支持，但仅支持 32 位的旧硬件仍使用裸 GRUB/SeaBIOS。不过，几乎所有主板都使用 EDK2！

最后，提供了一些关于显卡的说明，这些说明可能会引起要求更高的用户的兴趣。

EDK2 配合 PCI-E 可重定位 BAR（rebar）意味着你现在可以使用需要 4GB 以上分配的现代显卡。Rabar 默认情况下 未启用，但你可以在 menuconfig（coreboot）中启用它。启用它会导致 Intel GPU 在 libgfxinit 测试中的视频输出损坏，尚未找到修复方法，因此 rebar 默认禁用。

PCI-E Option ROM 在 EDK2 构建中根据需要默认启用。这意味着你可以在带有显卡的台式机上使用它。已在多台台式机上测试过（Dell OptiPlex 9020 SFF 和 5050 SFF）。

在仅有外置 GPU 的主板上，rebar 可以保持默认启用。在集成显卡正常工作的系统上，如果意外启用了 rebar，可以通过插入显卡来解决；当 payload 中的视频输出确实损坏时，Linux i915 视频驱动程序仍能在 KMS/DRM 中正确初始化视频帧缓冲区。

这将被添加到一般文档中，等待上游修复。请注意，即使存在此问题，Linux 视频输出仍能正常工作。这将在未来的 Libreboot 版本中得到修正，并在默认情况下启用 rebar。

几乎所有主要上游版本都已更新：

• Flashprog：已更新至 2026 年 9 月 24 日的版本
• EDK2：导入版本 26.09.2
• GRUB：已更新至版本 2.16
• Coreboot（默认树）：已更新至 2026 年 9 月 18 日的提交 ID 8ce4c91c41da3f042979f92095149a85bc93227d
• Coreboot（mrchromebox）：已导入 MrChromebox coreboot 的提交 ID e5997cf9384b29082a1bf3101813d8ac3dadda42，供 Chromebook 使用。
• Coreboot（fam15h）：已移除（4.11_branch 树）并替换为：
• Coreboot（fam15h_15h）：提交 ID 57e26bdcd959808c0171164f3c6197d4a347c3b2，时间为 2026 年 5 月 27 日。这是来自版本 4.11_branch 的 coreboot 的大幅改进分支，旨在提升 AMD FAM15H 硬件上的初始化可靠性，例如 ASUS KGPE-D16。
• SeaBIOS（非 CSM）：已更新至 2026 年 7 月 28 日的提交 ID 81ec9ec0bcf45df11fb7f98339ec9036b546fca0

coreboot 的 4.11_branch 树已被移除，因为我们现在在 AMD Fam15h 硬件上使用 15h.org 的 coreboot 分支。它有大幅改进，采用基于 AGESA 的正确初始化，可更可靠地初始化 CPU 和内存控制器。支持更多 RAM，并修复了几项功能，例如 IOMMU 和 TPM。

多个 coreboot 上游的使用通过 lbmk 中的一项设计改进得以实现，该改进使所有项目都成为多树结构，只是某些项目使用时仅有一个树。现在每个项目可以有 N 个上游，从而可以使用分支版本。

coreboot 更新在 crossgcc 中引入了 GCC 15.2、MPC 1.4.1、Nasm 3.02、acpica 20251212 和 binutils 2.46.1。

目前由 MrChromebox 支持的全部 233 台 Chromebook 都已导入并适配以供在 Libreboot 中使用。它们全部都能编译。是所有的。我再说一遍：

• 已从 MrChromebox 导入 233 台 Chromebook。现在，每一个由 MrChromebox 项目支持的 Chromebook 都可以通过 lbmk 的更改在 lbmk 中构建。感谢 Matt DeVillier 带来如此出色的项目！

除 Chromebook 外还新增了更多硬件支持：

• Dell OptiPlex 5050 SFF 支持，由 Ron Nazarov 提供。
• Supermicro X11SSH-F 主板支持 —— 由 Ron Nazarov 所做的改进，例如 通过 deguard 使用常规 Intel ME（已被阉割）—— 没有 bootguard，但 deguard 也可通用，以为每块主板提供预先配置好的 ME。该主板在其他方面使用 SPS。使用常规 ME 时，所需的 ME 区域要比使用精简 SPS 时更大。使用常规 ME 意味着 MRC 缓存可以正常工作，因此在重启时 raminit 训练速度大幅加快（不必在每次启动时都重新训练）。
• ThinkPad X280 支持由 AlguienSasaki 提供
• ThinkPad X270 支持由 Kat Inskip 提供
• Dell OptiPlex 3040 Micro 支持由 Todd Baker 提供
• 在 ThinkPad X301 目标上移除了 release="n"。它实际上可以正常启动，虽然速度相当慢。EDK2 甚至也能工作。

我们在 EDK2 内添加了 SeaBIOS CSM 和 GRUB EFI 构建版本，以与 Libreboot 较早的 GRUB/SeaBIOS payload 配置保持一致。EFI payload 的工作方式基本相同。

使用 EDK2 使得支持更新的机器更加容易，这也将是今后的工作重点。EDK2 首先被引入，作为整体现代化工作的一部分；更新的 Intel 和 AMD 硬件将逐步加入，默认情况下将独占使用 EDK2 payload。

这无疑是一个功能版本。功能变更非常多！

• 所有至少有 4MB 闪存的 Intel/AMD 板型均支持 EDK2 payload。这里使用了 MrChromebox 版本的 EDK2，Libreboot 对其进行了大量修改，例如 向其中添加 GRUB EFI 和 SeaBIOS CSM（CSMwrap）构建版本；这些是为了向后兼容较早的单一 SeaBIOS/GRUB payload 配置而提供的，并且应该仍然能够启动现有的 Linux/BSD 安装。
• 通过 EDK2 payload（ESC 菜单）添加 iPXE 启动方式 —— 仅限 EDK2（在旧款主板的单一 SeaBIOS payload 中不可用）。
• 新增命令 ./mk import_uboot，用于自动导入可在 lbmk 中构建的 U-Boot 配置。尚未使用，但将在未来版本中用于添加经过测试的 U-Boot 板型（U-Boot 自身提供初始化支持）。Libreboot 已经能够从任意配置构建 U-Boot 镜像，无需修改代码，仅需更改配置，但还需要在实际硬件上进行测试。
• 新增位于 util/mrimport 的工具，用于从 MrChromebox coreboot 自动导入/更新新配置。该工具也用于从 MrChromebox 初始导入 233 台 chromebook，将它们连同我们自己的修改一同导入到 Libreboot 构建系统中。
• 在 EFI 版本的 GRUB menuentry 中添加了 fwsetup 命令，可引导返回到 edk2 设置菜单。
• 修改 Kabylake 板型的 IFD，以支持 pin mod。这使得使用六核和八核 Intel CPU 成为可能。
• 在构建时随机化 MAC 地址，仅当 XBMK_RELEASE 未设置时生效。你可以通过环境变量 XBMK_MAC 导出 MAC 地址以进行任意设置。这样在直接处理 .rom 文件（而非已具备此能力的发布 tarball）时，无需在构建后提取 NVM 再重新插入，后者已可通过 ./mk inject 实现。
• GRUB at_keyboard 驱动：始终强制使用扫描码集 2 并进行转换。此前已经这样做，但仅在 coreboot 目标上；现在在 EFI 目标上也同样如此，只需将其普遍应用于所有目标即可。这是因为在 EDK2 上可以将其与 PS/2 键盘一同使用。它可以缓解某些有缺陷的 PS/2 控制器即使在设置后也可能无法正确报告模式的问题，例如 Dell Latitude E6400 上的情况。
• 我把 Memtest86+（在 EDK2 构建上）做成了紫色。Libreboot 紫。红色值 0x28，绿色值 0x0b，蓝色值 0x22。这就是 Libreboot 紫。
• 我也把 EDK2 做成了紫色，并为其添加了 Libreboot 的彩虹徽标。
• 在 GRUB 有效负载（EDK2 和 coreboot 目标）上，通过通配符扫描给定分区中的每个 ESP 目录。这意味着如果使用 GRUB 或 Syslinux 配置，它将启动更多非 UKI 的 Linux 发行版安装。
• 在所有使用 EDK2 的目标上，在可用时启用 TPM。
• 新增了 ./mk cbtest 命令，用于对照 lbmk 和 coreboot defconfig 测试主板名称，以防上游发生更改。否则，如果默认主板随后由 Kconfig 规则选定，我们可能会在不知不觉中更改针对给定目标实际构建的主板。目前还没有办法在构建时以简洁的方式自动检测到这一点，因此在更新 coreboot 版本时应使用此命令。
• 新增了 ./mk test 命令，该命令会激进地构建所有内容，甚至比 ./mk release 还要多 - 它有意禁用缓存使用，以便也对下载进行激进测试。与配置相关的命令也会被测试。这是一个用于查找构建错误的残酷压力测试命令。
• Flashprog：在命令循环期间始终保持 flash IC 处于热状态，而不是以切换方式进行。--workaround-mx 选项被保留，但其行为始终被应用，因此该选项不再起任何作用。这提高了整体可靠性，因为许多用户无论如何都不知道此选项。现在更多人可以可靠地刷新他们主板了。
• 新增的 mkhelper 类型：preconfig。这允许你在使用配置文件的给定项目上进行配置之前运行自定义逻辑。它也适用于 noconfig 项目。例如在 coreboot 上使用它来构建 utils。
• 在整个构建系统中移除了 ccache 的使用，因为它在多个压力测试场景中导致了细微的构建错误（可能还有代码缺陷）。我们宁愿多等一会儿以获得可靠的构建。CCache 实际上只用于开发，而不是用于生产。
• 在 lbmk 中移除了 -c 和 x（clean 和 xgcc-clean）标志，因为它们在很大程度上是多余的；lbmk 无论如何都会在构建之前自动清理所有内容，以删除所有构建工件，并根据配置元数据积极地缓存树外构建，根据需要从本地缓存中删除并重新获取源。这些选项毫无用处。
• 如果 makefile 检查失败，则正确跳过构建；这允许单树项目进行构建，方法是防止在没有文件时容易出错地使用 copy_elf。
• mk：移除了 GCC/GNAT 版本配对，因为上游（coreboot）现在在其 its buildgcc 脚本中执行此操作。它在 lbmk 中是多余的。coreboot 版本更好，因为它只是出错并退出，而不是尝试继续；后者是我们所做的，在某些情况下实际上可能导致更多错误。与其破坏构建，不如果断失败。
• 为 GRUB 添加了丹麦语键盘映射。

进行了大量重大设计更改！

• GRUB 启动配置已简化；现在启动只有一个 menuentry，它会启动所有内容，优先尝试 USB。它会选择它找到的第一个配置，但你可以按 ESC 在循环中切换到下一个。用于双启动多个 Linux 发行版时很有用。
• 现在在 coreboot 上使用短 defconfig，而不是完整配置。这便于维护，并且 lbmk 已修改以适应它们。inject 脚本仍然在运行时自动解析完整配置，这是在构建时扫描路径所需要的。使用 defconfig 减少了更新期间配置错误更改的可能性，并使得可以使用 olddefconfig 来代替可靠性较低的 oldconfig 命令。
• 新增安全检查：在逻辑中使用路径前缀时，请验证路径前缀是否已设置。否则，lbmk 中可能会出现目录转义漏洞。整个构建系统都会严格检查此项。
• 不再导出 XBMK_CACHE，因为现在它已在配置中硬编码。新的处理方式更为严格，在未来修订中不太可能出现倒退。这样做是为了降低 lbmk 中出现目录转义漏洞的可能性。
• 不再按 GRUB 树使用固定的 GRUB 模块列表。改为按目标添加所有模块，但应用按树配置的黑名单。
• GRUB Syslinux 与 GRUB 扫描现在在 GRUB 配置中合并为一个函数。对 GRUB 配置进行了整体简化。
• GRUB 现在是单一源码树，多个目标全部复用同一棵树，使用不同的配置。
• 修改了 MrChromebox coreboot，使其仅在 coreboot defconfig 中未选择视频模式时才添加 EDK2 GOP 二进制文件。这样可以避免不必要的添加，从而在使用 FSP init 或 libgfxinit 时节省闪存空间。
• 在 include/env/get.sh 上始终使用 --mirror git 克隆。这使得所有项目上的修订克隆更为可靠，尤其是在我们使用主分支之外分支中的修订的项目上。
• 在所有基于 Intel IFD 的系统上构建时自动解锁 IFD 区域；通过设置 HAP 位自动禁用 ME。这正是我们在 Chromebook 上所做的处理，但现已应用于所有开发板；这降低了将来我们可能意外忘记在特定目标上中和 ME 的可能性。
• 在构建 EDK2 时，我们使用 coreboot 的构建系统，但采用这种方式时，custom_ 前缀不会用于镜像文件名中。使用的是正确的 edk2 前缀。这使得 Chromebook 可正常工作，Chromebook 在本版本中按开发板构建 edk2；Chromebook 不处理通用 EDK2 构建。在非 Chromebook 上，我们构建一个使用 EDK2 和 SMMSTORE 的虚拟 ThinkPad T440p 构建，然后通过 include/fw/rom.sh 中的 shim 逻辑以更通用的方式提取它以插入到其他开发板中。
• 移除了 coreboot 中用于 Topton X2E N150 的 fspcc36ae2b5775fa7400cb3282680afc0f6cb37a3c 子模块。我们现在使用最新的 FSP，但这意味着在进行供应商注入时会破坏旧版本的构建。这是不可避免的。
• 添加了一个 noconfig 变量，可由构建树/目标设置，前提是它们为多树但不使用任何配置。编译时，它会显示在一个名为 noconfig 的伪名称下，例如 elf/grub/default/efi/noconfig/grub.elf。
• get.sh：在 find 命令中使用 -L，因为某些项目现在使用来自其他项目的元数据的符号链接以确保重新构建。例如，edk2 coreboot 目标（虚拟目标）依赖 grub 和 seabios efi 构建。当这些构建必须更改时，我们需要确保 edk2 coreboot 构建重新进行。这里指的是在构建系统设置中检查给定项目是否已更改时，用于查找要哈希的文件的 find 命令。
• 按目录名正确排序子模块，以便可以在项目中处理递归子模块。这是在 get.sh 上的子模块处理中进行的。
• get.sh：支持任意子模块配置路径，适用于使用子模块多个版本的项目。例如，EDK2 使用 brotli 的多个版本。
• 已移除 SeaGRUB；对于仍使用 coreboot-payload 版 SeaBIOS 和 GRUB 的主板，我们现在只生成以 GRUB 或 SeaBIOS 作为主 payload 的镜像。SeaBIOS 的 payload 加载并不总是可靠，而 GRUB 的内存分配器自多年前以来已有显著改进。我们现在在大多数主板上还采用了 EDK2，因此对仍专门使用 GRUB 的少数主板进行测试要容易得多。鉴于独立的 SeaBIOS/GRUB 已过时，这一简化将永久生效；EDK2 现在是首选 payload，其中 SeaBIOS 和 GRUB 的 EFI 版本被拼接到 EDK 菜单中，以便向后兼容较旧的 Libreboot 设置。
• 在构建项目前加强对 make distclean 的使用，这在 lbmk 中基于元数据检查的激进树外项目构建缓存使其可行。
• 允许在项目上使用 noconfig=n，即使在不需要构建配置的情况下，也允许项目成为多树并在不同的目标上使用同一棵树；在某些情况下，配置仅在 mkhelper 设置中完成。这是 Libreboot 决定将所有项目设为多树的一部分，同时允许每个项目使用 N 个上游，而不仅仅是一个上游。
• 简化 lbmk 中 release=n 的处理；不执行 mkhelper。如果 release=n 则跳过源代码获取，这样就不会下载相应的源。排除 MrChromebox 源以及发布版本中的构建是必要的，因为它们尚未准备好在 Libreboot 中稳定发布。
• init.sh：可移植的 date 用法；现在使用 git 自身的日期处理。我们不再依赖 date 命令的 GNU 特定扩展，以用于发布版本构建中的 git 仓库初始化。
• 允许从主工作目录之外运行 mk。构建系统现在会相应地更改工作目录。
• 在 get.sh 中运行 git am 时启用三方合并——这使得项目修订的更新更加容易。

• 大多数主板仍使用 CBFS 或 NVRAM 选项表（静态选项表，或修改 CBFS）。少数主板（如 HP EliteBook 820 G2 和 Topton X2E N150）使用基于 SMMSTORE 的选项配置，但该配置尚未在 lbmk 中设置。
• 在 coreboot（默认树）中默认将 me_state 设置为 Disabled，全树生效。我们反正已经在 IFD 中设置了 HAP 位，但这又是一层禁用措施，以确保 Intel ME 死得更彻底。
• 优化了 GRUB 模块；现在包含所有 FS 模块，启动时 GRUB shell 中显示的错误更少。模块通常经过优化，以确保与默认上游设置相比，仍不会占用大量闪存空间。
• 在依赖项中添加了 xxd，CSMWrap 在构建 SeaBIOS EFI 时需要它，因为它在 SeaBIOS CSM 构建上运行 xxd -i 以创建头文件，然后将其封装在 CSMWrapper 的 shim 代码中。
• 修正了 Dell OptiPlex 5050 DMI 字符串代码，使其显示 5050 SFF，而不是 3050 Micro。
• 不要在厂商注入脚本中将 dell.com 作为主要下载镜像。这可减少用户在使用 deguard 注入镜像时的下载错误次数。
• 在所有设备上扫描所有 GRUB 配置，不在 GRUB 中使用固定设备列表，而是使用通配符。还会检查更多的 BTRFS 子卷，这也通过使用通配符来实现。
• 对 GRUB 配置进行常规清理。冗余功能已移除，例如 对 gfxterm 的操作。默认设置运行良好。GRUB 本来在串行输出上就从未可靠地工作过，而且大多数现代计算机不支持 GRUB 在此上下文中支持的任何接口。
• 在依赖项中添加了 ImageMagick（EDK2 启动徽标所需）。
• SMMSTORE 默认启用，适用于所有将 EDK2 作为 payload 的目标。这意味着 Libreboot 用户现在可以在启动时进入标准的设置菜单，以持久的方式配置他们的机器（例如 启动顺序），且无需重新构建固件。
• 为 KCMA-D8 和 KGPE-D16 主板添加了 4MB 和 8MB 目标。这与在这些主板上使用 15h.org 的 coreboot 分支相结合，可改进 raminit 并修复各种错误。它使用 AMD AGESA 源代码，而非 Raptor Engineering 编写的自定义源代码。修改后的 AGESA 代码具有更好的 CPU 和内存初始化，支持更多硬件组合，并支持更大容量的内存。

• 合并了来自 Alguien 的补丁，修复了 ThinkPad X280 上的 IFD 区域（设置为可读写）并清空 OEM 部分。同时也禁用了超线程（HyperThreading）。
• 预防性构建修复：在所有项目中尽可能移除 -Werror 的使用。
• 修复了 ThinkPad X230 目标上由一项优化引起的挂起错误——该优化优化了 coreboot 中的 CAR 设置，现已回退以应用此修复。此修复回退了 coreboot 修订版本 97dbfd3098ae12ef3f51e5f95cd6d66c25214205。该回退由 HustlerOne 在其新的 Snowboot 项目中完成，并从 Snowboot 复制到 Libreboot 项目中。
• 为多个项目添加了伪 menuconfig Make 选项，以便相关的 mk 选项不会导致构建错误（现在只会发生无害的空操作）。
• mk：仅在运行配置命令且 defconfigs 实际存在时才将其复制回去。这修复了 ./mk -s seabios，它从未保存过 defconfig 文件。
• 将多项构建修复回移植到我们 2025 年初的 U-Boot 修订版本中，以便它能在现代发行版上构建，例如 最新的 Arch Linux 更新。（这是 GRU Kevin/Bob chromebook 能够继续构建所必需的。）
• 由于所使用版本的许可证不明确，已移除 src/gpio-scripts。（其更改未附带许可证；从 coreboot 分叉为独立项目时回退到了 coreboot 的 COPYING 文件，但分叉仓库中完全没有许可证信息——因此所做的更改也不清楚。）
• 修复了从 MrChromebox 导入的 Intel/AMD chromebook 主板上的多个损坏的 vendor 文件路径。这些修复也已提交并合并到上游的 MrChromebox 项目中。
• vendor.sh：捕获 coreboot defconfigs 中的所有 make 变量，运行 make-olddefconfig 并将它们全部解析为适当的值（涉及路径的情况）。它们以对 sh 友好的方式进行转换，并以避免意外运行错误子 shell 的方式进行处理。
• 更安全地处理 defconfigs；更严格的错误检查，包括针对 noconfig 项目的检查。
• 修复了 mk 中缺失的无限循环检测功能，当在项目中解析 trees/revisions 时。引用其他 trees 而形成无限引用的 trees 现在可以被检测出来。
• 修复了在 GCC 16 上 pico-serprog 的构建错误（在最新的 Arch Linux 上测试）。
• 在 coreboot/default 上使用 std=gnu2x 而非 std=gnu23；gnu2x 在较新的 GCC 版本上与 gnu23 代码兼容，但在旧版本（例如 2024 Linux Mint 发布版）上否则将无法构建。这修复了旧发行版的问题，在新发行版上行为没有变化。
• 不在 src/biosutilities 中构建 bios_extract——没有构建问题，但我们在 Libreboot 中根本不使用 bios_extract。我们使用该仓库中的一些脚本，这些脚本不需要编译。
• 更新了 Dell OptiPlex 3040 Micro ME_bin_hash，使自动下载功能正常工作，因为在最初导入时该功能是损坏的。
• vendor.sh：在 me_cleaner 命令上使用 -w 而非 --whitelist，因为后者在某些情况下会由于某种原因失败。使用 -w 是可靠的。
• 仅当主 mk 脚本中设置了 if_skip_build 时才跳过 make，以便在所有项目上更彻底地执行 mkhelper。
• 在使用干构建（dry build）模式时，更严格地防止 GRUB 中的构建例程运行；在某些情况下，它可能曾尝试将一个不存在的 GRUB 有效载荷添加到一个从未被编译过的、不存在的 ROM 中。此类检查已在 lbmk 中得到加强并在各处推广。
• 在设置 lbmk 时，在少数几处使用 command -v 的地方补充了缺失的错误处理。
• 预防性修复：在 mk 中调用 x_，以包装 xbmk_init。后者从不返回非零状态，因此此修复纯属预防性质，以防该函数将来某时被重新设计为返回非零状态。
• mk：修复多树命令参数中的 globbing 问题。此前我们用字符串填充参数，但现在我们使用 dollar-ampersand，并通过 shift 循环遍历参数，从而可以正确处理双引号。
• 在发布构建中重新初始化 lbmk 时，完全导出 git 作者/提交日期。这在每个相关的 git 命令上都会执行，以保证确定性运行。
• Fam15h coreboot：将未使用的 __unused 变量替换掉，并将其强制转换为 (void)，以防止在 GCC 16 中出现构建错误。
• 已将 Gentoo Linux 依赖项设置添加到 lbmk。
• 修复离线 GRUB 构建。构建系统会缓存源码和仓库，但 GRUB 中有一段自定义逻辑，用于从 translationproject.org 下载无版本号的 PO 文件——所以在我做 FOSDEM 演讲时，我的演示因网络中断而失败，而我错误地以为所有内容都已缓存。GRUB 已被修改为不再下载这些文件，改由 lbmk 对其进行缓存。它们现在还会通过校验和进行版本检查；上游实际上并未提供版本号，但其内容已经过核对，后续更新将检查它们之间的差异。基本上，translationproject.org 上的内容对应 GRUB 中的当前 HEAD。这没问题，因为 gettext 的工作机制是：如果某个字面字符串未定义，它会回退到原始语言。在这种情况下，使用错误的 PO 文件只会导致部分句子无法被翻译。不过，文件处理方式中的一个 bug 可能会在 GRUB 下载的、未校验哈希的无版本号文件上引发……缓冲区溢出。是的。Libreboot 通过分叉包含这些文件的仓库并将其保持静态，修复了这一可重现性问题。下次我做演讲时，我的演示不会再失败。我是在演讲结束几小时后修复这个问题的。

对 util/nvmutil/ 进行了大量更改，以至于它值得拥有自己的一份发布日志：

• 宏的使用通常更安全（使用括号）。
• 移除了基于 errno 的错误处理。仅根据逻辑错误返回零或一，但不要依赖 errno 的状态来进行错误退出。在 libc 函数中，只按 POSIX 的要求使用返回值。不过，在从 libc 函数返回后，errno 的重置得到了更可靠的处理；POSIX 不要求这样做，但也未予以禁止。- dell-flash-unlock 的 errno 处理也以同样的方式得到修复。此前我们严重依赖 errno 进行退出，这种方式不可移植。并非所有 libc 都会正确重置 errno，并且即使给定函数逻辑上返回成功，它也可能随机设置 errno。任何数量的操作都可能设置 errno，因此它并不是用于通用错误处理的可靠机制。
• 不要使用 -pedantic 标志——同时也在 spkmodem-recv 上将其移除。这可以减少因警告而引发的吹毛求疵式的构建错误。
• 通用正确性修复；边界检查、对齐字的正确处理、转换指针时使用 uintptr 等。由于广泛的审计，代码在内存管理方面通常更加安全。
• 各种函数的 EINTR 安全包装；在错误发生时循环直到 EINTR 清除，否则在非 EINTR 错误时出错退出。如果 close() 函数返回错误，则正确忽略 EINTR（POSIX 中 close 上的 EINTR 不是错误条件，在这种情况下应忽略描述符）。
• 对 OpenBSD 进行了更多测试和修复，尤其是在内存管理方面（OpenBSD 中的 libc 更为严格）。
• 通用化 libc 函数（如 read、write,predandpwrite`）的 I/O 函数 —— EINTR 安全，并对不完整写入等情况进行比 libc 更严格的检查。

注意：这适用于 nvmutil 的独立版本。曾尝试将其重写为一个更大的实用程序，在本版本中关于已取消更改的下一节中提到（请参阅下面关于 libreboot-utils 的说明）。

构建系统中大约清理了一千行死代码，但由于新功能的更改，又添加了几百行。尽管 lbmk 在本版本中有诸多进步，但其代码总量已减少。

具体清理包括：

• config/ 下的项目更好地集中，例如 config/module/coreboot/ 而不是 config/coreboot。目录 config/ifd/ 已移至 config/data/coreboot/ifd/，因为它仅从 coreboot 使用。
• config/ 目录现在的组织通常更好，每个项目的文件放置更加统一。
• 将所有供应商文件移入 vendorfiles/，例如 vendorfiles/mrc/，以减少主工作目录的杂乱。
• 删除了 cbfstoolref 配置；现在它是硬编码的，因为我们始终为该版本的 cbfstool 使用相同的 coreboot 4.11 树（在 broadwell 主板上进行 refcode 提取）。
• 系统地删除了构建系统中未使用的变量。
• mk：新的 forx 函数允许类似宏的循环简写，大大简化了大量代码。
• 删除了构建系统中的几项冗余检查，并总体上加强了所有错误处理。
• 各种随机和小规模的代码清理；构建系统中少量死代码的删除。
• 通用化了 lbmk 中几个宏化的 mkhelper 检查，重构并降低了整体代码复杂度。
• lib.sh：将 build_sbase 函数改为宏，以便可以在一个地方进行更改。它实际上只是一个命令（make -C util/sbase）。
• 简化了 add_uboot 逻辑，因为它现在仅在 ARM64 上需要。x86 的条件逻辑已被删除，因为我们完全不再在 x86 上使用 U-Boot；EDK2 现在是 x86 上的首选 payload，用于 UEFI。
• 由于可靠性的原因，已从依赖项中删除 ccache，因为我们不再使用 ccache。
• inject.sh：删除了确认成功插入的结束消息，并总体上简化了所有变量初始化。
• release.sh：删除了 -m 选项，因为它无用。在任何情况下我们都不会想在不构建二进制文件的情况下生成源存档。做半个发布有什么意义？这是死代码。旋钮是给笨蛋准备的。
• vendorsh` 中的清理。
• 在 lbmk 中展开了多个循环，将它们通用化为类似宏的函数。这既显著减少了代码大小，又提高了代码的可读性。只要正确操作，类似宏的编程在 sh 中是完全可行的。
• 在构建系统的某些部分大量使用 awk，以进一步展开一些循环，尤其是在 err 函数中。
• 移除了 mk 中针对 u-boot 的特定 make-clean 处理逻辑；反正 mk 现在已经更加通用。U-Boot 原本只针对 lbmk 的 Git 仓库（而非发布版本）使用 git-clean；那这么做有什么意义呢？我们希望在这两种情况下的行为尽可能保持一致，而做不必要的工作，说到底，就是不必要的。
• 大幅简化了 mk 中的 findpath 函数。现在只需一行代码，使用 forx。（readlink -f 和 realpath 的包装函数。
• 为 mk 中 xbmkpwd 的初始化新增了错误检查（更严格的检查）。
• 移除了 mk 中的 xprintf；现在直接用 printf 输出 & 给 awk 即可。很简单。
• 简化了 mk 中 xbmkpwd 的初始化；现在先找到 mk 的路径并切换到其所在的基础目录，后者即为 xbmkpwd。
• mk：在主脚本中运行 xbmk_init，而非在 init.sh 中运行。这样在首次阅读时就能更清晰地看出 xbmk 的初始化是从哪里调用的——就在 include init.sh 的下方完成。
• 将 tree.sh 合并进了 mk。一切都集中到 mk，附带自定义函数现已通过 shim 方式引入。
• 现在所有 include 都集中处理，所有调用都从主脚本发起。我们之前是有条件地 include tree.sh（后已合并入 mk）。现在所有状态全部全局化，这使得进一步的代码简化和变量清理成为可能。
• mk 中的 get.sh 已得到大幅简化。大量逻辑，尤其是子模块处理部分，进行了激进的通用化处理。

部分改动虽已开始着手，但未纳入本次发布。它们涉及两个主要项目：

这是 nvmutil 的一个扩展项目，后来演变为一套通用工具集，并附带一个用于处理诸如原子写入、以及针对各类 TOCTOU 攻击的用户态缓解措施的库。对 nvmutil 本身而言并非关键，但……

曾尝试实现一个名为 mkhtemp 的加固版 mktemp。它在用户态实现了若干针对 TOCTOU 攻击的缓解措施，例如目录替换攻击和符号链接攻击。

查看 lbmk 的 git 日志中的 util/libreboot-utils 即可了解更多（也可能是 util/libreboot_utils）。

Mkhtemp 是在为 nvmutil 实现原子写入时着手编写的，但后来我自然而然地开始使用 tmpfiles 来完成这件事，这促使我去审计每一个 mktemp 的实现。我的结论是：我可以做得更好——而我也确实做到了。

mkhtemp 的创新之处举例如下：

• 在请求时仍提供类 libc 的行为，但：
• 针对使用全局可写但未设粘滞位的目录，实行更严格的检查。
• 普遍更严格的错误退出处理。
• 对运行/检查期间发生的文件变更、inode 变更等情况进行不间断的检查。验证文件未被其他程序操作——基本上是尝试在用户态实现 openat2 般的安全性，同时在 Linux 上也将 openat2 作为一种快速手段加以启用。
• 自行实现了 rand，封装了 Linux 的 getrandom 与 BSD 的 arc4random。它提供了多种 rand 相关函数，其中一个函数（libreboot-utils 中的 rset 函数）的语义与 arc4random_buf 保持一致。
• 总体上对文件和目录采用无描述符（descriptorless）操作方式。
• 在可行的情况下采用无路径（pathless）操作方式——包括用户态的目录遍历与沙箱化。
• 在用户态实现类似 unveil 的限制（以及 OpenBSD 中的 pledge/unveil 用法）。
• 默认禁用符号链接的使用。

……它是一个过度设计的糟糕东西，并且存在数个与栈内存使用相关的内存问题，在 BSD 上频频出错。代码本可整理并完成，但我最终得出了一个结论：

分发版永远不会接受它。Mkhtemp 在 Linux 上运行良好，但它的操作要严格得多，会让大多数使用它的构建系统出现问题。我曾在 lbmk 中尝试用它替换 mkhtemp，在 PATH 中创建符号链接，但例如 GRUB 对 mktemp 几乎没有错误检查。大多数错误地使用 mktemp 的程序都错误地假设它永远不会失败，所以它不会失败；各实现会试图缓解错误并继续运行，这些方式极其复杂。Mkhtemp 是一次旨在更严格地使用 TMPDIR 的干净尝试。

因为我认定那是浪费时间，所以我不打算在本更新日志中再多写了。如果感兴趣可以查看 lbmk 的 git 日志。

util/spkmodem-recv 的一个大幅扩展版本，实现了更强的噪声防护，尝试进行自动音调检测和频率选择，等等。我做得有些过头了，最后认定这是一个过度设计的工程。它不会再被恢复。你可以在 lbmk 的 git 日志中找到它。（可能曾是 util/spkmodem_decode）。

毫无意义的努力。Spkmodem 该协议在大多数环境中无论如何都无法使用。

史上最毫无意义的努力，比如：

• 边缘检测与幅度检测，使在噪声信号上的运行更加可靠
• 定期根据信号重新校准时间，针对音调进行调整。这个想法是允许音调分离器随时间漂移，让我们的代码适应细微变化以减少噪声量。目前，spkmodem 在较弱的信号上显示出大量噪声。
• 一堆同样无用的改动。

完全毫无意义。简洁的代码运行得很好，所以这项工作被放弃了，因此 spkmodem-recv 仍然存在；这是几年前从 GNU GRUB 继承下来的代码的清理版本。

只有两项被取消的工作：

• 将 ARM64 Chromebook 上的 U-Boot 更新到 2026 年末的版本，但 bootflow 菜单现在很难看，几乎无法工作。上游完全把它搞坏了。因此，我们仍然使用 Libreboot 26.01（2026 年 1 月）发布版本中就已经存在的 2025 年初版本的 U-Boot。
• 通过在 EDK2 启动时解析 CBFS 中的 keymap.gkb 来支持 GRUB 键位映射。这项工作已被取消，因为将在发布之后实现一种更好的方法：在 EDK2 中使用 HiiDatabase 和图形化配置菜单来更改键盘布局和区域设置。这将被写入 SMMSTORE 并被各有效载荷使用。例如，GRUB EFI 有效载荷可以从 SMMSTORE 读取以获知区域设置，然后利用其现有的 gettext 集成相应地更改语言（GRUB 已经支持国际化）。

隐藏的第三项取消工作，因为总是有这么一项：

Linuxboot。借助 EFI 支持，我们现在可以轻松地把任意数量的 UKI 加入闪存（如果需要的话）——我们也会在未来的发布中这样做。Linuxboot 一词指的是任何可从闪存启动并能通过 Kexec 启动其他 Linux 内核的基于闪存的 Linux 发行版——我个人偏好 ZFSBootMenu，或者至少是受它启发的东西，因为 ZFSBootMenu 的构建系统与 Libreboot 的严格设计原则完全不相容。

（这是客气地说我对 podman/docker 深恶痛绝的一种说法）

用于启动的 Linux UKI 现在已经很常见，Libreboot EDK2 可以轻松地集成它。

ARM64 有效载荷仍然存在，但 EDK2 已经在 x86 上取代了 U-Boot。

这值得在本发布中单独成节来介绍，因为它是一项重大的设计变更。EDK2 不仅仅是作为一个选项被加入；它已经在 x86 上取代了 U-Boot。我完全可以为它单独写一篇文章。它值得拥有这样一篇文章。它值得我公开表达我的判断——现在我将毫不犹豫地阐明：

U-Boot 曾用于 Intel/AMD 主板上轻量级 UEFI 的实现，但负责 x86 coreboot payload 的主要负责人已大体上将 U-Boot 分叉为一个新近 vibe-coded（凭感觉编码）的项目；Libreboot 根据新政策强烈反对使用 AI。AI 毫无益处，且上游 x86 U-Boot 支持已基本荒废，尽管合并了一些有趣的补丁。

因此 U-Boot 在 x86 上是个累赘。EDK2 已更为完整，因此改用它。以为 AI 能让你成为超级黑客？再想想：

• https://arxiv.org/abs/2507.09089

U-Boot 在 x86 上本来就一直有 bug。它真的完全没有准备好。它更适合用于 RISC-V 和 ARM64（我们在这两个平台上继续使用它）。

至少在本次发布时，U-Boot 上游本身坚决反对 AI，关于上述问题的许多讨论曾在他们的邮件列表上进行。在这个发布页面上重新争论这些不会有成效，但可以说 Libreboot 项目认为 U-Boot 在 x86 上已名存实亡。基于 ARM 的开发在上游仍大力进行，我们将继续在 ARM64 上使用 U-Boot 提供 UEFI（例如 chromebook）。

我不会说出他的名字，也不会说出他分叉项目的名字，因为我不希望宣传他本人或其 U-Boot 分叉。如果你知道他的名字或他的项目，你也不应该说或宣传它。AI 很糟糕，非常糟糕，原因如下：

• https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

该 U-Boot 分叉大量使用了 AI vibe-coding，因此对 Libreboot 来说毫无用处。这并非凭空猜测；在上述 U-Boot 邮件列表讨论中，该作者如此声称。我们绝不会以任何方式鼓励或便利 AI 的使用。已明确指出，Libreboot 使用的几个项目也有一些 AI 辅助的提交；GCC、GRUB 等。这并非我们的过错，但我的打算是，我和其他人未来将对这些项目进行审查，去除 AI 拙劣代码，甚至可能因此将它们完全分叉。该分叉的作者基本上已对此走火入魔，他向上游 U-Boot 提议让其工作成为"托管者"，并慢慢合并到上游 U-Boot 树中。他基本上是在逼迫他们违背意愿接受 AI 代码。我作为 Libreboot 项目的负责人声明：U-Boot 绝不应允许 AI 玷污其项目。当你接受 AI 时，你就会失去技能，并侵蚀你与用户之间存在的信任。你消除了维护者与用户之间的人际联系，你的项目将开始依赖——没错——专有技术，而这些技术是用鲜血换取的。AI 是全球最大的电力和水资源消耗者之一，导致世界各地资源短缺，并且它对人们在新闻中所见信息的日益控制甚至是对全球民主的威胁。这甚至还没谈到模糊的许可、版权侵权等问题。已决定 Libreboot 将加入反对一切人工智能的圣战。主要负责 AI 训练和基础设施的国家是美国（由几家目前正在攻击全球民主的公司领导）和中华人民共和国；即使 AI 的所有其他问题都不存在，让这些国家对我们的计算拥有更多控制权也将是一个非常糟糕的主意。

不。Libreboot 对 AI 说不了。因此，我们将继续使用上游的 U-Boot，因为他们也同样说不了，而且我们不会使用任何 vibe-coded 的分支版本。即使这会让我不得不花上数周时间整合一个全新的系统来替换它。我恰恰、完全、毫无疑问地愿意走到这一步来证明我的观点。

这就是为什么我不遗余力地整合 EDK2。我没有用另一个不完整的 UEFI 实现来替换 U-Boot，而是直接加入了 EDK2——它本身就已经功能完备，因为它是 UEFI 规范的参考级、工业标准实现。

CrabEFI 是我最初考虑用来替换 U-Boot 的方案。这是由 Arthur Heymans 编写的全新 payload，项目本身很出色，但 rustc/cargo 从根本上来说并不可靠，原因有以下几点：

• 工具链配置不可预测。大多数人会使用例如 rustup，并设置各种各样的自定义环境。这比发行版中提供的例如 LLVM/GCC 要难预测得多。库等组件由 Cargo 提供而非由发行版提供，用户又常常让一切都保持过期状态，从而导致各种破坏性问题。
• Rust 没有标准化；其规范是由实现定义的，今天编写的代码在未来规范变化时仍可能编译通过，但代码行为自然会因后者而发生改变。
• 鉴于上述原因，我们必须自己引导编译 rustc/cargo，而且必须从源码开始（从一个像 GCC 这样已经拥有源引导编译能力的编译器开始——这要感谢 Guix 项目及其他项目的工作）。

Rust 很棒，但在我看来它尚未达到生产就绪。再给它十年时间吧。EDK2 复杂得多，但代码规模并不是问题，因为它整体上很稳定，并且使用 C 编写（其中有少量是用 C++ 编写的）。它受到的关注最多，并定期接受安全审计。它是互联网上经受最多实战检验的代码库之一，且运行良好。

CrabEFI 可能会在未来的某个时候被合并进 Libreboot——等到 Rust 工具链在各发行版（包括 BSD）中稳定下来之后。它的设计要好得多，尽管它尚未功能完备，而且使用 Rust 意味着它会有更少的内存缺陷。目前，Libreboot 使用 EDK2 来替换 U-Boot，并且已在所有主板上默认启用。

关于内存安全，我们反过来可以说 EDK2 至少是稳定的；bug 也是稳定的。这正是关键所在。我们有稳定的 C/C++ 编译器，按照形式化标准经过了充分测试（其实并非完全如此，因为 GCC 和 LLVM 也做了各种古怪的事情，但它们也在行为上试图彼此兼容）。你希望你的代码在编译时行为完全一致，包括 bug 本身。这在用 C 和 C++ 编写的项目中得到了更强的保证（尤其是纯 C 项目，而 EDK2 的大部分实际上就是纯 C）。

原本计划让 U-Boot 成为 Libreboot 在 x86 上的主 payload，但唉，事与愿违。我咽下了 Intel 风格的苦果，最终选择了 EDK2。

对 AI 说不了。AI 让你变笨。AI 就是我们无法拥有好东西的原因。

目前还无法更改键盘布局——之后可以在 EDK2 中添加一个图形菜单选项来实现此功能，并保存到 SMMSTORE。GRUB 的 EFI 构建仅使用 terminal_input console，因此输入由 EDK2 输入驱动程序处理（USB 大容量存储设备及其他存储设备同理）；例如，GRUB 的 nativedisk 驱动被移除，其原生的 NVMe/xHCI 驱动也不再需要——就像之前版本的 Libreboot 那样。

EDK2 输入驱动程序在 Libreboot 中可同时用于 USB 和 PS/2 键盘。GRUB 被设置为使用 console 输入而非 at_keyboard，因为它在 EFI 构建中缺少 USB 键盘支持。因此，键盘布局必须由 EDK2 处理。EDK2 中有相关代码，但目前既未被 Libreboot 也未被 MrChromebox 处理，因此本版本中全部默认为 UK QWERTY。上游（MrChromebox）默认使用 US QWERTY，但 Libreboot 是一个英国项目，因此对 EDK2 进行了相应补丁。此项工作将在发布后进行。

不再提供键映射镜像。现在每块主板的每个配置只有一个 ROM 镜像。这简化了构建流程，用户可以根据需要通过 config/data/grub/keymap/ 将 keymap.gkb 文件插入 CBFS 中；如果向 grub.cfg 添加 terminal_input 设置为 at_keyboard 再刷入，那么在使用 GRUB EFI payload 时，配备 PS/2 键盘的设备也可以正常工作（还需要在 grub.cfg 中添加加载 keymap 的命令，具体为 keymap (cbfsdisk)/keymap.gkb）。

EDK2 已在从 GM45（例如 ThinkPad X200/T400）到 Libreboot 支持的 Intel Kabylake 硬件（例如 ThinkPad T480、X280、Dell Optiplex 3050/5050）的所有 Intel 硬件上进行了广泛的测试。

EDK2 中的新兼容性模块对于大多数用户来说应该绰绰有余，他们可能仍希望使用 GRUB/SeaBIOS 来启动现有的 Linux 和 BSD 配置。建议将这些转换为 EFI 或重新安装 —— 从现在起强烈鼓励默认使用 UEFI，但 Libreboot 必须（将）继续支持较旧的配置。

使用 SeaBIOS 文本模式启动的 FreeBSD 用户可能会对此感兴趣，因为 BIOS 模式的 FreeBSD 引导程序无法通过其他方式启动。不过，基于 UEFI 的 FreeBSD 安装在 EDK2 中可以正常工作，因此推荐新的 FreeBSD 安装通过 EDK2 进行（不要使用 GRUB/SeaBIOS 的兼容性模块）。

某些用户可能需要它。以下是一些简要说明。它们不会被添加到主要文档中，因为它们涉及 Libreboot 现在视为过时的配置，但某些用户在短期内仍可能会觉得有用：

仅支持 32 位或闪存空间有限的旧主板仍使用不带 EDK2 的独立 GRUB/SeaBIOS payload；一些具有特殊图形设置的新主板也仍使用单独的 SeaBIOS/GRUB，例如 HP EliteBook 8560w。

要重新启用独立 GRUB/SeaBIOS（不带 edk2）的使用，请根据您的主板按如下方式修改 target.cfg：删除 build_depend、payload_edk2 和 grubtree 变量。然后添加以下行：

payload_grub="y"
payload_seabios="y"
payload_memtest="y"

这在 Libreboot 中现已过时，甚至可能在未来的版本中被移除。EDK2 要好得多，因为它几乎可以启动所有东西，并支持更多的硬件配置。它比上一版本中 Libreboot 的旧设置要灵活得多。

然后您只需重新构建即可。注意：在上述指南中，build_depend 默认假定为 grub/default seabios/build memtest86plus/default。您可能希望显式设置它们：

build_depend="seabios/build grub/default memtest86plus/default"

您可能还希望显式设置 GRUB 树：

grubtree="default"

示例配置：config/module/coreboot/t480_vfsp_16mb/target.cfg

只需执行此操作并在您希望恢复这些旧配置时重新构建。在可行的情况下将继续支持它，但可能会在某个时间点被移除，也许是几年后，也许是一周后。请趁它还在时使用它。xHCI 补丁仍在其中，所有内容都按应有的方式进行了配置。

在使用 EDK2 的配置中，请注意：不提供 txtmode。如果想要例如 SeaBIOS txtmode，请参阅例如：

• config/module/coreboot/t480_vfsp_16mb/config/libgfxinit_corebootfb

在此示例中将其重命名为 libgfxinit_txtmode，然后执行：

./mk -m coreboot t480_vfsp_16mb
./mk -s coreboot t480_vfsp_16mb

在出现的菜单中，进入 Devices -> Display -> Framebuffer mode 并选择 Legacy VGA text mode —— 这不推荐用于任何新安装，但 FreeBSD 引导加载程序以文本模式启动，而 coreboot 中的 framebuffer 模式无法切换回文本模式。在通过 BIOS 模式引导 FreeBSD 引导加载程序时，建议以文本模式启动，随后可以在 Xorg/Wayland 中为 FreeBSD 设置 KMS。否则，新安装应直接通过 EDK2（无兼容模块）以 EFI 模式完成。更多信息可在 Libreboot 的 BSD 文档中找到。

• Google Anahera
• Google Aurash
• Google Banshee
• Google Bujia
• Google Caboc
• Google Constitution
• Google Crota
• Google Dochi
• Google Felwinter
• Google Gaelin
• Google Gimble
• Google Gladios
• Google Jubilant
• Google Kano
• Google Kinox
• Google Kuldax
• Google Lisbon
• Google Lotso
• Google Marasov
• Google Mithrax
• Google Moli
• Google Moxie
• Google Anraggar
• Google Craaskov
• Google Craask
• Google Dirks
• Google Domika
• Google Epic
• Google Glassway
• Google Gothrax
• Google Guren
• Google Joxer
• Google Kaladin
• Google Meliks
• Google Nereid
• Google Nivviks
• Google Nova
• Google Pujjocento
• Google Pujjogatwin
• Google Pujjoga
• Google Pujjolo
• Google Pujjoniru
• Google Pujjo
• Google Quandiso2
• Google Quandiso
• Google Riven
• Google Rull
• Google Sundance
• Google Teliks
• Google Telith
• Google Tereid
• Google Tivviks
• Google Uldrenite
• Google Uldren
• Google Xivu
• Google Yaviks
• Google Yavilla
• Google Omnigul
• Google Osiris
• Google Primus
• Google Redrix4ES
• Google Redrix
• Google Taeko
• Google Taniks
• Google Vell
• Google Volmar
• Google Xol
• Google Coral
• Google Pyro
• Google Reef
• Google Sand
• Google Snappy
• Google Auron_Paine
• Google Auron_Yuna
• Google Buddy
• Google Gandof
• Google Guado
• Purism Librem 13 v1
• Purism Librem 15 v2
• Google Lulu
• Google Rikku
• Google Samus
• Google Tidus
• Google Banon
• Google Celes
• Google Cyan
• Google Edgar
• Google Kefka
• Google Reks
• Google Relm
• Google Setzer
• Google Terra
• Google Ultima
• Google Wizpig
• Google Banjo
• Google Candy
• Google Clapper
• Google Enguarde
• Google Expresso
• Google Glimmer
• Google Gnawty
• Google Heli
• Google Kip
• Google Ninja
• Google Orco
• Google Quawks
• Google Squawks
• Google Sumo
• Google Swanky
• Google Winky
• Google Akemi
• Google Ambassador
• Google Dooly
• Google Drallion
• Google Dratini
• Google Duffy
• Google Faffy
• Google Genesis
• Google Helios
• Google Jinlon
• Google Kaisa
• Google Kindred
• Google Kohaku
• Purism Librem 14
• Purism Librem Mini v2
• Google Moonbuggy
• Google Nightfury
• Google Noibat
• Google Scout
• Google Wyvern
• Google Dewatt
• Google Nipperkin
• Google Ampton
• Google Bloog
• Google Bobba
• Google Casta
• Google Dood
• Google Fleex
• Google Foob
• Google Garg
• Google Lick
• Google Meep
• Google Phaser
• Google Falco
• Google Leon
• Google Mccloud
• Google Monroe
• Google Panther
• Google Peppy
• Google Tricky
• Google Wolf
• Google Zako
• Google Awasuki
• Google Beadrix
• Google Blipper
• Google Boten
• Google Boxy
• Google Bugzzy
• Google Cret
• Google Dexi
• Google Dibbi
• Google Dita
• Google Drawcia
• Google Galtic
• Google Kracko
• Google Lantis
• Google Madoo
• Google Magolor
• Google Metaknight
• Google Pirika
• Google Sasukette
• Google Sasuke
• Google Storo
• Google Taranza
• Google Atlas
• Google Endeavour
• Google Eve
• Google Fizz
• Google Karma
• Purism Librem 13 v4
• Purism Librem 15 v4
• Google Nami
• Google Nautilus
• Google Nocturne
• Google Rammus
• Google Soraka
• Google Crystaldrift
• Google Frostflow
• Google Markarth
• Google Skyrim
• Google Winterhold
• Google Kanix
• Google Karis
• Google Screebo
• Google Berknip
• Google Dirinboz
• Google Ezkinil
• Google Gumboz
• Google Morphius
• Google Shuboz
• Google Vilboz
• Google Woomax
• Google Asuka
• Google Caroline
• Google Cave
• Google Chell
• Google Lars
• Purism Librem 13 v2
• Purism Librem 15 v3
• Google Sentry
• Google Butterfly
• Google Link
• SAMSUNG Lumpy
• Google Parrot
• Google Stout
• SAMSUNG Stumpy
• Google Aleena
• Google Careena
• Google Liara
• Google Treeya
• Google Chronicler
• Google Collis
• Google Copano
• Google Delbin
• Google Drobit
• Google Eldrid
• Google Elemi
• Google Lindar
• Google Voema
• Google Volet
• Google Voxel
• Purism Librem Mini
• Google Sarien

CSMWrap is the SeaBIOS CSM build provided inside EDK2. It hogs an entire CPU core at boot, so e.g. quad-core will show up as three-core inside Linux. It’s a known limitation that will be corrected in a future release, due to the design of CSMWrap. If you need backward compatibility, it’s better to use the GRUB EFI build instead which does not have this problem. Both GRUB EFI and SeaBIOS CSM are available in the EDK2 menu via ESC keypress at boot time.

Users are best served just switching to native UEFI boot with ESP, using Libreboot’s EDK2 payload.

Markdown file for this page: https://libreboot.org/news/libreboot2610.md

Site map

This HTML page was generated by the Libreboot Static Site Generator.