Quick Answer: The release of libreboot uefi support in version 26.10 "Ominous Olive" replaces bare-metal coreboot payloads with MrChromebox’s EDK2 implementation across 64-bit hardware. This update enables native Microsoft Windows booting, expands board compatibility to 233 Chromebook targets, integrates the 15h.org code for AMD Fam15h servers, and hardens Intel ME disablement by default.

For over a decade, open firmware enthusiasts traded UEFI convenience for absolute software freedom, accepting narrow OS compatibility to avoid proprietary vendor binaries. Libreboot 26.10 "Ominous Olive" fundamentally changes that dynamic. By incorporating complete libreboot uefi support through an EDK2 payload pipeline, maintainer Leah Rowe has brought modern boot standards, Windows compatibility, and 233 new Chromebook mainboards into the project's ecosystem without weakening its strict security posture.

The Architectural Pivot: EDK2 Takes Over coreboot Payloads

In earlier releases, Libreboot initialized hardware via coreboot and immediately handed control to a bare-metal payload—typically GRUB or SeaBIOS—flashed directly into the SPI ROM's coreboot filesystem (CBFS). Libreboot 26.10 shifts this model entirely for 64-bit hardware. EDK2 (Intel's reference EFI Development Kit II) now serves as the primary coreboot payload across all supported 64-bit platforms, including older classic ThinkPads like the X200, X220, and T420.

+-------------------------------------------------------------------+
|                        SPI Flash ROM                              |
| +------------------+  +-----------------------------------------+ |
| | Intel ME / IFD   |  | coreboot Initialisation                 | |
| | (HAP Bit Set)    |  | (native raminit / libgfxinit / AGESA)   | |
| +------------------+  +-----------------------------------------+ |
|                                   |                               |
|                                   v                               |
|                       +-----------------------+                   |
|                       |  EDK2 UEFI Payload    |                   |
|                       | (Tianocore / Core)    |                   |
|                       +-----------------------+                   |
|                                   |                               |
|          +------------------------+------------------------+      |
|          |                        |                        |      |
|          v                        v                        v      |
|  +---------------+        +---------------+        +------------+ |
|  | EFI Bootloader|        | GRUB EFI Build|        | CSMWrap    | |
|  | (Win/Linux/BSD)        | (Reads CBFS)  |        | (SeaBIOS)  | |
|  +---------------+        +---------------+        +------------+ |
+-------------------------------------------------------------------+

Instead of removing legacy interfaces entirely, Libreboot embeds GRUB EFI and SeaBIOS (via CSMWrap) directly inside the EDK2 build environment. Pressing the ESC key during early initialization calls up the EDK2 setup menu, allowing you to load these sub-payloads on demand.

Legacy Model:      [coreboot] ---> [Bare-Metal GRUB / SeaBIOS] ---> [OS Kernel]
26.10 Model:        [coreboot] ---> [EDK2 UEFI Payload] ---------> [OS Bootloader / CSM]

This structural shift solves a persistent deployment problem: operating systems expecting UEFI runtime services no longer stall or require patched kernel parameters. Furthermore, Libreboot uses libgfxinit for native graphics initialization up to Intel Kaby Lake generations rather than relying on binary Graphics Output Protocol (GOP) drivers, keeping the initialization display pipeline open-source.

When you transition bare-metal payloads to EFI wrappers, coreboot startup times change by only a few hundred milliseconds, but payload management becomes simpler because CBFS no longer needs separate build targets for every minor OS quirk. That said, there's a real catch here for legacy MBR-only drives...

233 Chromebooks Ingested: The MrChromebox Integration

The headline additions to the Libreboot hardware roster are 233 Intel and AMD Chromebook mainboards imported from the MrChromebox project. Utilizing a newly written internal tool located at util/mrimport, the lbmk build system now parses upstream coreboot configurations, fetches submodules, and generates exact build targets for everything from Intel Bay Trail up to recent AMD Ryzen and Intel Alder Lake Chromebooks.

Importing these boards is not merely a mirror job. Libreboot applies several structural overrides during the automated build process to enforce stricter security guarantees:

  • Forced ME Disablement: The build script automatically sets the Intel ME HAP bit (High Assurance Platform) at build time via ifdtool. Upstream MrChromebox releases typically rely on software scripts executed within ChromeOS to disable the Management Engine. Libreboot bakes this setting straight into the flash image binaries.
  • Unlocked IFD Regions: Flash descriptor write protections are unlocked systematically, allowing subsequent in-system firmware updates without requiring external hardware programmers (e.g., CH341A SPI tools).
  • VBT/GOP Payload Modifications: Libreboot applies custom theme assets (such as the signature purple background and rainbow logo) while routing Video BIOS Tables (VBT) through CBFS.

Testing on Bay Trail hardware (such as the Toshiba Chromebook 2 "Kip") confirms full stability, though the bulk of the 233 imported Chromebook builds remain source-only in this release cycle. Users wanting to flash these targets must compile them via lbmk rather than downloading pre-compiled ROM images.

Importing hundreds of configurations automatically sounds clean until you run into board-specific memory initialisation routines. Here's where it gets interesting...

Fixing AMD Fam15h: The 15h.org AGESA Shift

For users running open-source firmware on dual-socket AMD Opteron server motherboards—specifically the ASUS KGPE-D16 and KCMA-D8—previous Libreboot releases were plagued by unreliable memory initialisation (raminit) and broken hardware virtualization primitives. Libreboot 26.10 abandons coreboot's unmaintained custom Fam15h init code in favor of the 15h.org coreboot fork.

This switch replaces custom initialisation routines with AMD's open-source AGESA (AMD Generic Encapsulated Software Architecture) framework code. The practical impacts on production server builds are immediate:

  1. Memory Channel Stability: Fully populating multi-channel Registered ECC DDR3 memory configurations no longer results in random memory training hangs at POST.
  2. IOMMU Realignment: AMD-Vi (IOMMU) page tables compile properly, allowing clean PCI pass-through to virtual machines under Proxmox VE or KVM.
  3. TPM Integration: Built-in Trusted Platform Module communication bugs that previously prevented TPM 1.2/2.0 discovery have been patched.
Fam15h Memory Init Flow (Legacy):  [coreboot] -> [Custom Raminit] -> [Frequent Training Hangs]
Fam15h Memory Init Flow (26.10):   [coreboot] -> [AGESA Framework] -> [Stable Reg-ECC DDR3]

However, a technical edge case exists for display outputs on these server mainboards. EDK2 requires a graphical framebuffer to render its setup interface. The onboard ASPEED AST2050 BMC graphics controller on the KGPE-D16 defaults strictly to text-mode execution under open-source initialisation; running EDK2 on it requires executing proprietary Option ROMs, which Libreboot refuses to ship. Consequently, EDK2 builds for AMD Fam15h remain experimental source-only configurations meant strictly for nodes with secondary discrete PCIe graphics cards. For headless BMC server applications, stick to the standard SeaBIOS release binaries.

Most guides skip this hardware nuance, assuming server chips behave like consumer motherboards. This next part matters more than it looks if you plan to dual-boot desktop software...

Booting Windows and Navigating Payload Deprecation

Can a libre computer boot Microsoft Windows? Historically, doing so on a Libreboot system required complex SeaBIOS chains, legacy MBR partition schemes, and custom ACPI table patches. With full libreboot uefi support supplied via Tianocore EDK2, Windows 10 and Windows 11 boot out of the box on supported 64-bit mainboards.

+-----------------------------------------------------------------------------------+
|                            OS Boot Compatibility Grid                             |
+---------------------+-------------------------------+-----------------------------+
| Operating System    | Legacy Payload (SeaBIOS/GRUB) | 26.10 EDK2 UEFI Payload     |
+---------------------+-------------------------------+-----------------------------+
| Linux (Modern GPT)  | Requires manual boot parameters| Native (via systemd-boot/EFI)|
| FreeBSD / OpenBSD   | Native (via SeaBIOS CSM)      | Native (via EFI loader)     |
| Microsoft Windows   | Broken / Complex Workarounds  | Native (Full UEFI ACPI)     |
+---------------------+-------------------------------+-----------------------------+

Because EDK2 exposes standard UEFI runtime services and ACPI tables directly to the operating system, Windows detects standard hardware state without crashing on coreboot-specific ACPI quirks.

Legacy Payload Deprecation

With EDK2 serving as the unified default, bare-metal SeaBIOS and bare-metal GRUB payloads are official marked as deprecated in 26.10. While still downloadable as fallback builds, they will eventually be phased out of pre-compiled release tarballs.

If you are upgrading an existing Linux installation previously configured for bare-metal GRUB, you do not need to reformat immediately. Simply boot into the EDK2 startup menu (ESC key), select the embedded GRUB EFI payload option, and point it to your existing root filesystem. For long-term reliability, repartition your drive with a standard 512MB EFI System Partition (ESP) formatted as FAT32 and install grub-efi-amd64 or systemd-boot.

Architectural Comparison: Legacy vs. 26.10 Ominous Olive

To evaluate how this release alters overall system capabilities, review the functional differences between legacy builds and the current architecture:

Component / FeatureLegacy Libreboot (<= 26.01)Libreboot 26.10 "Ominous Olive"
Default 64-Bit PayloadBare-Metal GRUB or SeaBIOSEDK2 UEFI Payload (Tianocore)
Windows Boot SupportNon-functional / UnstableFull Native UEFI Support
Chromebook Target BoardsHandful of older models233 Intel/AMD Mainboards
Intel ME DisablementTarget-dependent scriptsForced HAP Bit via build toolchain
AMD Fam15h SupportUnstable custom raminit15h.org AGESA Coreboot Fork
Backward CompatibilityDirect Payload ExecutionCSMWrap / EFI GRUB inside EDK2

Before wiping your existing partition layout to build an ESP, look at how the build system modifications alter how code is pulled upstream...

Build System Overhauls and the Anti-AI License Policy

Maintaining custom patches against multiple coreboot distributions can quickly become unmanageable. To keep Libreboot synchronized with external upstream work, Leah Rowe restructured the lbmk build framework to handle an arbitrary number of upstream git repositories per board module. This structural rewrite allows lbmk to pull directly from coreboot upstream, MrChromebox repos, and 15h.org simultaneously without patch collisions.

Another critical addition in release 26.10 is the implementation of an explicit anti-AI policy documented in AGENTS.md. Located within the main lbmk repository, this policy explicitly forbids automated web scrapers, LLM training bots, and automated coding agents from utilizing the source code or contributing machine-generated pull requests.

For developers compiling from source, the build workflow remains straightforward:

# Clone the build system repository
git clone https://git.libreboot.org/lbmk.git
cd lbmk

# Dependencies installation (Debian/Ubuntu example)
sudo ./build dependencies debian

# Build standard EDK2 image for a target mainboard (e.g., ThinkPad T420)
./build roms t420_11mb

The resulting binaries are written directly to the bin/ directory, complete with pre-configured IFD regions and HAP bit flags already inserted.

Frequently Asked Questions

Can Libreboot boot Windows?

Yes. Thanks to the inclusion of full libreboot uefi support via the EDK2 payload, modern versions of Microsoft Windows (including Windows 10 and 11) boot natively on supported 64-bit Libreboot machines without needing custom kernel modifications or broken ACPI workarounds.

How to install Libreboot on Chromebook models added in 26.10?

Install Libreboot on supported Chromebooks by using the built-in lbmk utility to compile an image from source using ./build roms [board_name]. Next, put your Chromebook into Developer Mode, disable hardware write-protect (via screw removal or battery disconnection depending on the model), and flash the output binary using MrChromebox's installation scripts or a hardware SPI programmer.

Does Libreboot UEFI support break legacy Linux installations?

No, it does not immediately break them. Although EDK2 is now the default payload, it includes an EFI version of GRUB and a SeaBIOS CSM wrapper accessible by pressing ESC during system boot. This allows existing legacy MBR-installed Linux systems to boot without forcing an immediate disk reformat.

What is the primary difference between coreboot and Libreboot?

Coreboot is an open-source upstream firmware project that often requires third-party binary blobs (such as memory initialisation code or microcode) to boot modern hardware. Libreboot is a downstream distribution that cleans coreboot, automates the build system, strips non-free blobs where possible, hardens security configurations like the Intel ME HAP bit, and delivers ready-to-flash payload configurations.

Moving Forward With Libreboot 26.10

Libreboot 26.10 "Ominous Olive" resolves the long-standing tension between strict free firmware requirements and modern operating system standards. By making EDK2 the default payload, the project delivers practical libreboot uefi support while retaining precise control over internal blob usage and ME disablement.

If you are running an older release on a desktop or ThinkPad, consider building a test image from source or trying out the pre-compiled EDK2 tarballs on a secondary system first. Check out our comprehensive Open Source Firmware Installation Guide or read our deep-dive on How to Disable Intel ME With IFDTool to prepare your flashing hardware.