Back Original

Libreboot 26.10 "Ominous Olive" released with UEFI, Chromebook support

Return to index

Article published by: Leah Rowe

Date of publication: 15 October 2026

You can find today’s release in https://rsync.libreboot.org/stable/26.10/ or you can use one of the mirrors.

Libreboot is free, open source boot firmware replacing proprietary BIOS/UEFI firmware on supported Intel/AMD and ARM64 hardware. It initialises the hardware inside your computer such as the CPU or memory controller, configuring the machine in such a way as to enable use of an operating system like Linux or BSD at boot - and now Microsoft Windows is also compatible because Libreboot has added full UEFI support via MrChromebox EDK2 payload. Libreboot offers greater security and customisation compared to proprietary firmware; its goal, plainly, is to rid the world of proprietary software and to do that, we therefore try to provide firmware that is extremely easy for non-technical users to understand.

Today’s release changelog is relative to the previous Libreboot 26.01 release.

This is a very special release, with several major design changes made regardless of hardware changes, so users should read this changelog very carefully - and read it twice.

First thing’s first. (and yes, you read the previous paragraph correctly)

A strongly anti-AI policy was added to a new file: AGENTS.md in lbmk. This is the most important change in the release. Now everything else:

WARNING: MAJOR design changes were made to this release, in ways that may affect lots of existing setups. We now use EDK2 as the default payload, with GRUB/SeaBIOS provided in flash as EFI builds for backward compatibility. Everything works, but there are some caveats so please read this release changelog very carefully.

The first major change is:

233 Intel/AMD Chromebooks added

The full list of boards is quite long, so it’s shown at the end of this article. All 233 of them!

MrChromebox supports nearly every Chromebook, and this release imports all boards from that project. This includes everything up to the most recent Intel and AMD hardware.

Imported all 233 currently supported Chromebooks from the MrChromebox coreboot distro. Baytrail (Kip) tested - others need testing. Source-only in this release (must build from source, no binaries provided).

This was done with a utility I wrote at util/mrimport/ which generates configs for lbmk, including revisions and submodules. I made further tweaks manually; further updates upstream can be synced in Libreboot by diffing again the output of mrimport between revisions, adapted into Libreboot irrespective of the latter’s modifications which are numerous - and will be covered next.

Libreboot makes these modifications to MrChromebox coreboot, in its version:

The additional payloads are, as above, available in the boot menu via ESC keypress at startup. iPXE is also enabled by default, as in upstream, on specific boards. EFI GRUB and CSM SeaBIOS have replaced the coreboot payload versions of these; bare metal SeaBIOS/GRUB are now deprecated and may be removed in a future Libreboot release, although they can be re-enabled by those willing to build Libreboot from source.

This is NOT a fork of MrChromebox, which is to be regarded as Libreboot’s upstream on Intel/AMD Chromebooks. Efforts will be made, as with regular coreboot, to remain as closely in sync with it as possible at all times. I have worked extensively with MrChromebox, and even submitted a few minor fixes to his project; he also implemented CBFS-based VBT and GOP handling per my request, which I will integrate post-release.

Regardless, MrChromebox’s own installation scripts should work, with Libreboot images, so check out MrChromebox documentation for installation. Despite changes, Libreboot’s setup remains behaviourally compatible with the MrChromebox one and, thus, MrChromebox tooling should still work alongside corresponding documentation.

This is made possible by a new feature in Libreboot’s build system: support for an arbitrary number of upstreams per project. We still provide regular coreboot on non-Chromebook mainboards.

Yes, 233. I counted. All automated. My scripting and my fastidiousness ensured that what I imported and configured in lbmk closely matched upstream, and I’m quite careful at maintaining my own divergence from it inside Libreboot.

Yes, Libreboot runs on Chromebooks now!

E.g. KGPE-D16. We use the coreboot fork from 15h.org now, on AMD Fam15h mainboards. This uses AMD AGESA source code instead of Timothy’s custom init code. It has much more reliable raminit and CPU initialisation; more RAM also supported. Many bugs are fixed. IOMMU works, I also saw that they mentioned TPM is fixed in their version, now our version also.

Regular binaries with SeaBIOS and GRUB payloads provided - we also have experimental EDK2-based images, currently source-only (no binaries available). EDK2 requires a framebuffer to be set up, and the integrated AST2050 chip only starts in text mode on native initialisation; the vendor VGA ROM can set up VESA, but we will not use the VGA ROM. The EDK2-based images are source-only on these boards, intended for use with graphics cards.

Basically, these boards actually work for the first time.

EDK2 UEFI payload by default

EDK2 is Intel’s reference implementation of the UEFI specification, for booting. It’s typically used by vendors, in proprietary forks of Intel’s BSD-licensed code, but Intel’s reference code is Free Software. We use their reference code, and full source code is provided in this Libreboot release. EDK is short for: EFI Development Kit.

More specifically:

We use a fork of EDK2 provided by MrChromebox, which specifically offers use of EDK2 as a generic coreboot payload. This is a complete, industry-standard UEFI implementation capable of booting any compliant operating system.

All. Nearly all boards use it in Libreboot now, even older ones e.g. ThinkPad X200. Tested on all platforms. Older, 32-bit-only mainboards still use the setup from the previous release, while virtually all 64-bit-compatible hardware now use EDK2. EFI builds of GRUB and SeaBIOS are provided in flash, accessible from the EDK2 setup menu (press ESC at boot time when prompted), for backward compatibility with existing Linux/BSD installations in Libreboot.

EDK2 support was integrated as a prerequisite for Chromebooks, but then it was extended for use on all previously existing supported mainboards in Libreboot. It even runs well on really old machines e.g. ThinkPad T500.

All Libreboot boards now use an open source UEFI implementation by default, where feasible. All of them, and it’s by default - the bare metal GRUB and SeaBIOS coreboot payloads have been removed, replaced by EFI versions that are backward compatible.

We previously did not provide UEFI at all, except for U-Boot on a few select mainboards. We now provide full UEFI, with all four freedoms intact, on nearly every mainboard that Libreboot supports.

All of the following operating systems were tested and confirmed working, on various Libreboot machines using EDK2:

Modern computers and operating systems are all UEFI, and this new setup can boot basically all of it reliably. More testing will be required, but this is battle-tested code and it has been used extensively in coreboot by many users, for many years. Libreboot finally has it as well.

This change alone is part of a much wider effort to modernise Libreboot, and I’m only getting started. The next Libreboot releases will draw heavily on this, as EDK2 is pretty much the expected payload on a lot of modern coreboot setups these days. Integration of EDK2 removes all limitations in Libreboot, allowing us to support much newer hardware and it basically makes Libreboot much easier to use; I expect Libreboot to become much more popular and useful over time, as a result.

Some caveats and extra notes are provided at the end of this release page, for migration purposes. For example, despite boasting about all, older 32-bit-only hardware still use bare GRUB/SeaBIOS. Nearly all boards use EDK2 however!

Modern GPU support (via EDK2)

Finally, some notes about graphics cards that may be of interest to the more demanding users.

EDK2 alongside PCI-E relocatable BAR (rebar) means that you can now use modern graphics cards that require allocations above 4GB. Rebar is not enabled by default, but you can enable it in menuconfig (coreboot). Enabling it causes breakage of Intel GPU video output on libgfxinit in testing, and no fix was found yet, so rebar is disabled by default.

PCI-E Option ROMs are enabled by default where necessary, for EDK2 builds. This means you can use it on desktops with graphics cards. Tested on several desktops (Dell OptiPlex 9020 SFF and 5050 SFF).

On boards with only external GPU, rebar can be left enabled by default. On systems with functioning integrated graphics, accidental enablement of rebar can be remedied by inserting a graphics card; when the video output in the payload does become broken, the Linux i915 video driver still initialises video framebuffer properly in KMS/DRM.

This will be added to general documentation, pending fixes upstream. Note that even with this issue, Linux video output works fine. This will be corrected and rebar enabled by default, on a future Libreboot release.

Nearly all major upstream revisions updated:

The 4.11_branch tree of coreboot was removed, because we now use the 15h.org fork of coreboot on AMD Fam15h hardware. This is much improved, with proper AGESA-based initialisation which initialises CPUs and memory controller more reliably. More RAM is supported, and several features were fixed too e.g. IOMMU and TPM.

The use of multiple coreboot upstreams was enabled by a design improvement in lbmk that makes all projects multi-tree, just with some projects ony having one tree in use. We can have N number of upstreams per project now, enabling use of forks.

The coreboot update brings in GCC 15.2, MPC 1.4.1, Nasm 3.02, acpica 20251212 and binutils 2.46.1 on crossgcc.

All 233 chromebooks currently supported by MrChromebox have been imported and adapted for use in Libreboot. They all compile. All of them. I repeat:

More hardware added besides Chromebooks:

We add SeaBIOS CSM and GRUB EFI builds inside EDK2, for parity with Libreboot’s older GRUB/SeaBIOS payload setups. The EFI payloads work very much the same.

Use of EDK2 makes it easier to support newer machines, which will be the focus from now on. EDK2 came first, as part of a general modernisation effort; newer Intel and AMD hardware will be added over time, making exclusive use of EDK2 payload by default.

This is very much a features release. A lot of feature changes were made!

A lot of major design changes have been made!

A lot of changes were made to util/nvmutil/ to the extent that it deserves its own release log:

NOTE: This applies to the standalone version of nvmutil. There was an attempt to rewrite it in a much larger utility, mentioned in the following section about canceled changes for this release (see notes below about libreboot-utils).

Roughly one thousand lines of dead code were cleaned out of the build system, but several hundred more were added due to new feature changes. Overall, the amount of code in lbmk has been reduced, in spite of its advances in this release.

Specific cleanup includes:

A few changes were worked on, but did not land in this release. They pertain to two major projects:

This was an extension of nvmutil that later became a generalised set of utilities alongside a library for handling things like atomic writes, and userspace mitigation against various types of TOCTOU attacks. Not really critical for nvmutil itself, but…

An attempt was made to implement a hardened version of mktemp called mkhtemp. It implemented several mitigations in userspace against TOCTOU attacks e.g. directory replacement and symlink attacks.

Check lbmk git log for util/libreboot-utils to see more (might have been util/libreboot_utils.

Mkhtemp was started when implementing atomic writes for nvmutil, but then I naturally made use of tmpfiles for that, and that led to me auditing every implementation of mktemp. I concluded that I could do better - and I did.

Examples of how mkhtemp innovated:

…it was an over-engineered piece of crap, and had several memory issues related to stack memory usage, which tripped up a lot on BSD. The could could be tidied up and finished, but I came to a conclusion:

Distros would never accept it. Mkhtemp worked fine on Linux, but it had much stricter operation that would trip up most build systems that use it. I tried it in lbmk to replace mkhtemp, symlinking it in PATH, but for example GRUB had virtually no error checking on mktemp. Most programs that use mktemp wrongly assume that it can never fail, so it doesn’t; implementations try to mitigate errors and continue operation, in ways that are extremely complex. Mkhtemp was a clean attempt at stricter TMPDIR usage.

Because I decided it was a waste of time, I don’t think I care to write more about it in this changelog. Check lbmk git log if you’re interested.

A heavily extended version of util/spkmodem-recv that implemented much stronger noise protection, attempted automatic tone detection and frequency selection, plus more. I went a bit overboard with it and decided that it was an overengineering effort. It will not be resumed at any point. You can find it in lbmk git log. (might have been util/spkmodem_decode).

Pointless effort. Spkmodem the protocol is unusable in most setups regardless.

The most pointless effort ever, such as:

Completely pointless. The simpler code works just fine, so the effort was abandoned and thus spkmodem-recv is still present; this is a cleaned up version of what was inherited from GNU GRUB several years ago.

Miscallaneous canceled work

Just two canceled works:

Hidden third cancelation, because there always is one:

Linuxboot. Now with EFI support, we can easily use any number of UKIs added to flash if we want to - and we will, in a future release. The term Linuxboot refers to any flash-based Linux distro that can boot other Linux kernels via Kexec - my preference is ZFSBootMenu, or at least something inspired by it as ZFSBootMenu’s build system is thoroughly incompatible with Libreboot’s strict design principles.

(which is a polite way of saying that I hate podman/docker with a passion)

Linux UKIs are common now, for boot, and Libreboot EDK2 can easily integrate it.

U-Boot x86 payload REMOVED

The ARM64 payload is still present, but EDK2 has replaced U-Boot on x86.

This deserves its own section, in this release, as it is a major design change. EDK2 was not merely added as an option; it has replaced U-Boot on x86. I could make this its own article. It deserves one. It deserves my judgement, publicly as I’m now about to articulate in no uncertain terms:

U-Boot was used for lightweight UEFI implementation on Intel/AMD boards, but the person chiefly in charge of the x86 coreboot payload for U-Boot has largely forked U-Boot into a newly vibe-coded project; Libreboot opposes heavily the use of AI, as per new policy. AI is no good, and upstream x86 U-Boot support has largely bitrotted although several interesting patches were merged.

U-Boot is thus a liability on x86. EDK2 is more fully functional already, so this is used instead. Think AI makes you a super hacker? Think again:

U-Boot was always buggy on x86 anyway. It’s really just not ready at all. It is better used on RISCV and ARM64(where we continue to use it).

U-Boot upstream itself is staunchly anti-AI, at least at the time of this release, and much discussion of the above was had on their mailing list. It would not be productive to re-ligitate that on this release page, but it should suffice to say that the Libreboot project considers U-Boot to be effectively dead on x86. The ARM-based development is still ongoing strongly, upstream, and we will continue to use U-Boot for UEFI on ARM64 (chromebooks for example).

I will not say his name, or the name of his fork, because I don’t want to promote him or his U-Boot fork. If you know his name or his project, you should not say it or promote it either. AI is bad, very bad, for reasons here:

The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to Libreboot. This is not mere conjecture; in said aforementioned U-Boot mailing list thread, the author stated thus. We will not, in any way, encourage or facilitate use of AI. It has been made clear that several projects Libreboot uses also have some AI-assisted commits; GCC, GRUB, etc. This is not our fault, but it is my intention that I and others will audit these projects in the future, de-slopping them and possibly even forking them entirely for that very reason. The author of the fork basically went insane with it, proposing to the U-Boot upstream that his work be “custodian”, and merged slowly into the upstream U-Boot tree. He was basically pressuring them to accept AI code against their wills. I say in my capacity as leader of the Libreboot project that U-Boot should never allow AI to taint its project. When you accept AI, you become deskilled and you erode the trust that exists between you and your users. You remove the human connection between maintainers and users, and your project will start to become dependent on what is - yes - proprietary technology, paid for in blood. AI is one of the single biggest consumers of electricity and water on the planet, leading to resource shortages all over the world and its increasing control over what information people see in the news is even a threat to democracy worldwide. This is before even arguing about unclear licensing, copyright violations and so on. It was decided that Libreboot would join the crusade against all artificial intelligence. The countries chiefly in charge of AI training and infrastructure are the United States (led by several companies currently attacking democracy worldwide) and the People’s Republic of China; even if all the other problems with AI didn’t exist, it would be a very bad idea to give these countries even more power over our computing.

NO. Libreboot says no to AI. Thus, we will continue using upstream U-Boot as they say no also, and we will not use any vibecoded forks of it. Even if that causes me to have to spend weeks integrating a totally new system to replace it. That is precisely, exactly and indubitably how far I will go to prove my point.

That is why I went to such extreme effort integrating EDK2. Rather than replace U-Boot with yet another incomplete UEFI implementation, I simply added EDK2 which is already feature-complete as it is the reference, industry-standard implementation of the UEFI spec.

CrabEFI was what I initially considered, to replace U-Boot. This is a new payload written by Arthur Heymans, and the project itself is excellent, but rustc/cargo is inherently unreliable for several reasons:

Rust is awesome, but in my opinion not production-ready yet. Give it another ten years. EDK2 is infinitely more complex, but the size of the code is not a concern as it is generally stable, and written in C (some small bits of it are in C++). It has the most amount of eyes on it, and regularly receives security audits. It’s one of the most battle-tested codebases on the internet, and works well.

CrabEFI will likely be merged in Libreboot at some time in the future, when Rust tooling has stabilised across distros (including BSDs). It has a much better design, even if it’s not yet feature-complete, and use of Rust means that it will have fewer memory bugs. For now, Libreboot uses EDK2 to replace U-Boot and it has been enabled by default on all boards.

On memory safety, we can say contrarily that EDK2 is at least stable; bugs are also stable. That’s the point. We have stable C/C++ compilers, properly tested according to formalised standards (not really, because GCC and LLVM do all sorts of whacky things too, but they also try to be compatible with each other behaviourally). You want your code, when compiled, to behave exactly the same, bugs included. This is more strongly guaranteed with projects written in C and C++ (especially pure C projects, and most of EDK2 is in fact pure C).

It was originally intended that U-Boot would become Libreboot’s primary payload on x86, but alas. I bit the Intel-flavoured bullet and went with EDK2.

Say no to AI. AI makes you stupid. AI is the reason we can’t have nice things.

No ability to change the keyboard layout yet - a graphical menu option can be added for this later in EDK2, saved to SMMSTORE. The EFI build of GRUB uses terminal_input console only, and input is thus handled by the EDK2 input drivers (ditto USB mass storage and other storage devices); GRUB’s nativedisk driver is removed for example, and its native NVMe/xHCI drivers are no longer needed as in previous Libreboot releases.

EDK2 input drivers work with both USB and PS/2 keyboards in Libreboot. GRUB is made to use console input instead of at_keyboard as it otherwise lacks USB keyboard support in the EFI build. Thus, layouts must be handled by EDK2. There is code for this in EDK2, not currently handled by either Libreboot or MrChromebox so it all defaults to UK QWERTY in this release. Upstream (MrChromebox) uses US QWERTY by default, but Libreboot is a British project, so EDK2 was patched accordingly. Work will be done post-release.

Keymapped images no longer provided. There is now only one ROM image per config on each mainboard. This simplifies builds, and users can insert a keymap.gkb file inside CBFS from config/data/grub/keymap/ if they wish; if you add a grub.cfg to flash with terminal_input set to at_keyboard, this will work on devices with PS/2 keyboards if wanting to use the GRUB EFI payload (a command in grub.cfg to load the keymap is also needed, specifically keymap (cbfsdisk)/keymap.gkb.

EDK2 has been tested extensively on all Intel hardware from GM45 e.g. ThinkPad X200/T400, all the way to Intel Kabylake hardware supported by Libreboot e.g. ThinkPad T480, X280, Dell Optiplex 3050/5050.

Want old GRUB/SeaBIOS back?

The new compatibility modules in EDK2 should more than suffice for most users, who may still want GRUB/SeaBIOS for booting their existing Linux and BSD setups. It is recommended that you convert these to EFI or just reinstall them - use of UEFI is strongly encouraged as the default from now on, but Libreboot must (will) continue supporting older setups.

FreeBSD users booting with SeaBIOS text mode may be interested in this, as BIOS-mode FreeBSD bootloaders do not boot with anything else. A UEFI-based FreeBSD installation will work just fine in EDK2 though, so new FreeBSD installations are best recommended via EDK2 (do not use the compatibility modules of GRUB/SeaBIOS).

Some users might want it. Here are some brief notes. They won’t be added to the main documentation as they pertain to a configuration that Libreboot now regards as obsolete, but some users may nonetheless find it useful in the short term:

Older mainboards that are 32-bit only or with limited flash space still use the standalone GRUB/SeaBIOS payloads without EDK2; some newer ones with weird graphics setups also still use lone SeaBIOS/GRUB e.g. HP EliteBook 8560w.

To re-enable use of standalone GRUB/SeaBIOS (without edk2), modify target.cfg as follows for your board: remove build_depend, payload_edk2 and grubtree variables. Then add these lines:

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

This is obsolete now in Libreboot and may even be removed in a future release. EDK2 is much better as it boots nearly everything, and supports more hardware setups. It is simply much more versatile than Libreboot’s old setup as in the previous release.

Then you can just re-build. NOTE: In the above guidance, build_depend is assumed to be grub/default seabios/build memtest86plus/default by default. You may want to set them explicitly:

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

You may also wish to set the GRUB tree explicitly:

grubtree="default"

Example config: config/module/coreboot/t480_vfsp_16mb/target.cfg

Just do this and re-build if you want these old setups back. This will be supported for as long as feasible, but will probably be removed at some point, maybe years from now, maybe a week from now. Use it while it’s there. The xHCI patches are still in there, and everything is configured as it should be.

In setups with EDK2, please note: txtmode not provided. If wanting e.g. SeaBIOS txtmode, look at e.g.:

Renamed it to libgfxinit_txtmode in this example and do:

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

In the menu that appears, go into Devices -> Display -> Framebuffer mode and select Legacy VGA text mode - this is not recommended for any new setups, but the FreeBSD bootloader starts in text mode and the framebuffer modes in coreboot can’t switch back to it. Booting in text mode is recommended when booting the FreeBSD BIOS-mode bootloader, and then FreeBSD can be set up for KMS in Xorg/Wayland. Otherwise, new installations should be done in EFI mode directly via EDK2 (no compatibility modules). More information about this is available in Libreboot’s BSD documentation.

List of Chromebooks added

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.