[KongchangAI]
· 3 min read· 1,586 words

Libreboot 26.10 Released: Adds UEFI and Chromebook Support

Libreboot 26.10 Released: Adds UEFI and Chromebook Support

Libreboot 26.10 adds UEFI and Chromebook support for the first time, a controversial step toward mainstream compatibility.

The open-source firmware project Libreboot has released version 26.10, codenamed Ominous Olive, adding UEFI boot support and Chromebook compatibility for the first time. Libreboot has long aimed to reject all proprietary binaries, and UEFI and Chromebooks were once explicitly excluded, so this update is seen as a route-level shift. The new version is expected to lower the barrier for new users and let idle Chromebooks run regular Linux distributions after flashing free firmware, which has positive implications for the second-hand device market and e-waste. But community controversy focuses on two points: whether UEFI support violates the project's original intent, and whether actual usability is adequate given Chromebook firmware locks and write protection. The article reminds readers that flashing firmware carries risks and that device compatibility should be confirmed before proceeding.

The open-source firmware project Libreboot has released version 26.10, codenamed "Ominous Olive." This release has stirred up considerable discussion in the community, as it brings two forms of support that were previously unimaginable: UEFI booting and Chromebook compatibility. For those who have long followed free firmware, this is almost a route-level shift — Libreboot was known for being "absolutely pure, rejecting proprietary code," and both UEFI and Chromebooks were once things it explicitly excluded.

Screenshot of the Libreboot 26.10 "Ominous Olive" release announcement

From "Pure Firmware" to Compatibility with Reality

Libreboot's positioning has always been clear: to provide a completely free BIOS/UEFI replacement for specific motherboards, stripping out all proprietary binaries. Its predecessor was GNU Libreboot, which later became independent from the GNU project due to philosophical disagreements. This background determines that its user base is fairly niche, but extremely loyal.

The addition of UEFI support in version 26.10 means it can now interface with mainstream operating system boot chains. UEFI itself is not "evil" — the problem is that most implementations contain proprietary modules. Libreboot's approach would presumably be to provide its own UEFI implementation path rather than directly wrapping vendor firmware. If this step is taken steadily, it will significantly lower the barrier to entry for new users.

To understand the tension between Libreboot and UEFI, one needs to distinguish between the UEFI specification and UEFI implementations. UEFI is a boot interface specification developed by the UEFI Forum; it is itself a public, open document that defines how firmware initializes hardware, how it hands control over to the operating system, and how it provides runtime services. What truly raises the alarm in the free software community is the implementations that vendors stack on top of this specification: they often contain undisclosed closed-source modules, network stacks, drivers, and even remote management components, and most require digital signatures before a bootloader can be loaded. If Libreboot introduces its own UEFI implementation path, it would essentially be using open-source code to cover the interface layer required by the specification, thereby allowing modern operating systems to recognize and boot normally without introducing vendor binaries. For free firmware that has long relied only on traditional BIOS boot chains, this is a catch-up at the interface level.

The digital signature mechanism in firmware also deserves explanation. Traditional BIOS does not verify bootloaders, whereas UEFI introduced signature verification, originally intended to defend against boot sector viruses and low-level persistent attacks, but objectively it hands part of the control over the boot chain to platform vendors. The free firmware community's typical response is to provide signing schemes where users can import their own keys, or to simply disable mandatory verification. How Libreboot handles this mechanism while remaining free will directly affect its practical experience on mainstream distributions.

What Chromebook Support Means

The Coreboot that Chromebooks run is itself a common foundation for open-source firmware. Libreboot is built on top of Coreboot, so extending to Chromebooks is theoretically a natural step. But Chromebooks' firmware locks, write protection mechanisms, and ties to the Google ecosystem make this far more complicated than desktop motherboards.

For users, the most direct value is this: a spare Chromebook lying around gets a second life — after flashing free firmware, you can install a regular Linux distribution. This is a positive signal for both the second-hand device market and the e-waste problem.

Coreboot is Libreboot's technical foundation, so it deserves a separate explanation of its role. Coreboot is an open-source firmware framework responsible for the most basic hardware initialization — that is, bringing memory controllers, chipsets, and basic peripherals from a cold start state to a state where subsequent code can execute. It deliberately stays lean, and the actual boot logic is handled by payloads, common ones including GRUB, SeaBIOS, and UEFI implementations. Libreboot is precisely a distribution built on top of Coreboot that packages curated payloads and configurations, forming an out-of-the-box usable distribution with proprietary binaries removed. This also explains why Libreboot's expansion capability is highly dependent on platforms already supported by Coreboot: as long as there is upstream porting code for a corresponding motherboard, extending downward becomes technically feasible.

Chromebook write protection mechanisms are another often underestimated aspect. To prevent firmware tampering, Chromebooks typically use hardware write protection, putting the firmware chip into a read-only state via a screw, shield, or dedicated jumper on the motherboard, while at the software level this pairs with read-only firmware regions and verified boot. Removing write protection generally requires disassembling the device and modifying hardware, and some models also require first entering developer mode and clearing boot state flags stored in firmware. Such operations carry high irreversible risk: if power is lost mid-process or a mistake is made, the device may no longer boot into recovery mode. This is also the main technical reason the community is skeptical about Chromebook flashability.

Controversy and Doubts

The discussion on Hacker News (original post) was not all applause. The core controversy centers on two points: whether UEFI support violates the project's original intent, and whether Chromebook hardware compatibility has really reached a usable level.

Such doubts are not rare in the free software community. Every compromise toward the mainstream leads some to worry about a "slippery slope." But conversely, a project that serves only a tiny number of old motherboards ultimately has limited influence. Moderately expanding compatibility may be the way to keep the philosophy alive.

The slippery slope often mentioned in the free software community refers to a project centered on purity introducing its first compromise, after which the boundaries become increasingly blurred and it eventually becomes no different from an ordinary open-source project. This concern is not unfounded: historically, some projects have indeed gradually accepted more proprietary components after adding binary firmware support, diluting their original free commitments. But critics of the slippery slope argument point out that the value of a principle lies in whether it can be continuously practiced; if strict purity standards shut out the vast majority of users, the philosophy can only remain in a small circle. The debate around Libreboot 26.10 is essentially another collision between these two orientations.

It is worth noting that the GNU project's criteria for judging firmware often differ from intuition. What GNU cares about is not whether firmware is preinstalled on a device, but whether users can replace, modify, and reflash it. A network card that can be freely flashed may be considered acceptable even if it ships with proprietary firmware; conversely, a device with non-replaceable firmware burned in does not meet the standard even if it runs open-source drivers. Libreboot's early pickiness about motherboards was largely an execution of this judgment logic, which is also the fundamental reason it supports so few models.

What It Means for Ordinary Users

If you have never encountered Libreboot, this release may be an entry point worth noting. It no longer requires you to own an old motherboard of a specific model, nor does it require you to completely bypass the modern boot process.

Of course, flashing firmware always carries risk, and removing Chromebook write protection requires especially careful operation. It is recommended to consult official documentation and community tutorials first, and confirm that your device model is on the supported list before proceeding.

Libreboot 26.10 is a directional experiment. Whether it can find a balance between "freedom" and "usability" will depend on subsequent releases and community feedback.

Before flashing firmware, the most basic step is to verify the device model against the official support lists of Coreboot or Libreboot; motherboards from different production batches within the same product line may use completely different chipsets. An external programmer is the most reliable recovery tool. Common tools include inexpensive programmers based on the CH341A chip paired with clips or probes, which can directly read and write the firmware chip even when the device cannot boot at all. It is therefore advisable to prepare one beforehand and confirm that you can read a backup of the factory firmware.

Risks also come from power and the firmware image itself. A power loss during flashing may leave the chip in a half-written state, and an image with a mismatched checksum can likewise prevent booting. The prudent approach is to first make a complete backup of the original firmware, operate in a stable power environment, and prioritize models with active community support and verification by others. For Chromebooks, you must additionally confirm developer mode, the write protection removal method, and whether firmware boot flags need to be reset, to avoid being unable to return to a recoverable state after removing write protection.

One-line Summary

Libreboot 26.10 adds UEFI and Chromebook support for the first time, taking a controversial step toward mainstream compatibility.

Paragraph Summary

The open-source firmware project Libreboot has released version 26.10, codenamed Ominous Olive, adding UEFI boot support and Chromebook compatibility for the first time. Libreboot has long aimed to reject all proprietary binaries, and UEFI and Chromebooks were once explicitly excluded, so this update is seen as a route-level shift. The new version is expected to lower the barrier for new users and let idle Chromebooks run regular Linux distributions after flashing free firmware, which has positive implications for the second-hand device market and e-waste. But community controversy focuses on two points: whether UEFI support violates the project's original intent, and whether actual usability is adequate given Chromebook firmware locks and write protection. The article reminds readers that flashing firmware carries risks and that device compatibility should be confirmed before proceeding.

#Libreboot#UEFI#Chromebook#open-source firmware#Coreboot#free software#firmware flashing
Share:

Related articles