Libreboot 26.10 adds 233 Intel and AMD Chromebook configurations without providing prebuilt images for them. The October 15 release names one imported board, the Bay Trail-based Kip, as tested and says the others need testing. For owners of those machines, trying Libreboot now means compiling firmware and helping establish whether it works on their hardware. Those limits appear in the project's own release notes.
The same release changes how existing Libreboot machines start their operating systems. Most supported x86-64 boards now default to EDK2, an open-source implementation of UEFI, with older boot methods available through compatibility components. That creates a more familiar route into modern operating systems, though the migration notes describe limitations that deserve attention before an upgrade.
A board name is the starting point
Libreboot imported the configurations from MrChromebox, an established coreboot firmware project for Intel and AMD ChromeOS devices. It treats MrChromebox as an upstream supplier and intends to keep the imported work synchronized. Libreboot's installation guide says it incorporates that project's coreboot and EDK2 code, while directing users to MrChromebox for installation and update tooling.
Finding the right configuration requires a board identifier. The MrChromebox supported-device guide explains that the name shown in a shop or printed on a laptop isn't enough: firmware support follows the ChromeOS hardware ID. Several commercial models can share one board name. On a recovery or Developer Mode screen, that identifier is the first part of the hardware ID, before spaces or hyphens.
That makes the headline count less useful for an individual owner than a match in the device table. MrChromebox's guide gives the example of an ID beginning CROTA-LPXP: its board name is CROTA. The same table records firmware availability and the write-protection method for each supported device. Its scope is Intel and AMD x86-64 hardware. ARM Chromebooks fall outside this imported firmware family. Check the board listing before choosing an image or instructions.
Compiling comes before installing
The source-only designation leaves Chromebook owners with work that users of Libreboot's supplied binaries can skip. The project's build guide describes lbmk, its build system, which fetches and patches components and builds the necessary payloads. It includes dependency setup for several Linux distributions and can build an individual board target rather than the whole collection.
In an lbmk checkout, the documented target-list command prints the available build targets:
./mk -b coreboot list
That command belongs in a prepared Libreboot source checkout. It lists targets without establishing that the resulting firmware has booted on your hardware. The 26.10 announcement separates those two stages explicitly: it reports that all 233 imported configurations compile, while calling for testing beyond Kip. A successful build is the first result a tester needs, followed by a successful flash and checks on the actual machine.
UEFI changes the route into an operating system
Chromebooks already use coreboot in Google's stock firmware, paired with a payload called Depthcharge. Libreboot's EDK2 documentation explains that its x86 Chromebook setup replaces that payload with EDK2. Coreboot handles hardware initialization, while EDK2 provides the UEFI environment that loads a compatible operating system. The practical attraction is easier booting of conventional Linux and BSD installations, with Windows booting also possible.
The change extends beyond the imported Chromebook boards. Libreboot's installation documentation recommends its EDK2 images for modern releases, retaining GRUB and SeaBIOS inside EDK2 for compatibility. Users get a firmware setup menu rather than having to treat every change as a firmware rebuild. Settings are stored in an area called SMMSTORE, which persists in flash.
Updating that flash needs care. The general EDK2 guidance explains that writing only the COREBOOT section preserves SMMSTORE, while overwriting the settings area resets it. Boot-order preferences therefore depend on how an update is performed. An operating system starting successfully after a firmware update doesn't, by itself, show that the machine retained its previous settings.
Older boot paths have a measurable cost
The SeaBIOS compatibility option currently has a substantial limitation. Libreboot's CSMWrap erratum says the component occupies an entire CPU core at boot, giving the example of a four-core machine appearing to Linux as a three-core machine. The project recommends the GRUB EFI compatibility option instead where appropriate, or moving an installation to native UEFI boot. It says a future release will address the CSMWrap limitation, without giving a date.
Keyboard input also changes. According to the EDK2 errata, this release defaults to UK QWERTY in EDK2 and has no menu option to change that layout. GRUB's EFI build receives input through EDK2's drivers. Anyone whose boot routine depends on another keyboard layout should check this before replacing a working installation, particularly when typing characters whose positions differ between layouts.
Some machines retain the older standalone GRUB or SeaBIOS setup, including boards limited to 32-bit operation or constrained by flash space. Libreboot's legacy-payload notes also identify exceptions with unusual graphics arrangements. The release makes UEFI the preferred path across much of the supported hardware, with the exact boot arrangement still depending on the board.
Firmware support stops short of driver support
MrChromebox states a boundary plainly in its device documentation: firmware availability implies no particular level of functionality under an operating system other than ChromeOS. Linux distributions and Windows can differ in their support for the same device. The next check after finding a firmware target is therefore an operating-system compatibility report for that board, rather than assuming UEFI settles the matter.
Replacing the complete firmware also changes what you can return to through the normal boot screens. MrChromebox's firmware-type guide distinguishes Full ROM replacement from RW_LEGACY, which supplements stock firmware and permits dual booting. Full ROM removes the stock ChromeOS boot and recovery environment and requires a UEFI-compatible operating system. Owners who want to keep ChromeOS need to understand that distinction before following a replacement-firmware guide.
The preparation varies by generation. MrChromebox's write-protection instructions describe older hardware with a screw, jumper or switch, alongside newer security-chip controls. Ti50 devices require disabling read-only firmware verification as well as write protection. Disconnecting the battery, a method available on some CR50 boards, doesn't perform those jobs on Ti50. The documentation also says management enrollment can prevent access to the required debugging controls.
Libreboot's own Chromebook installation guide calls for backing up stock firmware because it can contain data unique to the device, including its serial number and hardware ID. It tells users to keep that backup on another machine and check their external recovery options. For source-only targets still awaiting testing, those steps are part of preparing an experiment whose outcome hasn't yet been established on the board in front of you.
Open firmware still depends on the hardware
Libreboot's binary-blob reduction policy permits vendor initialization code when a usable free implementation isn't available. It also requires available CPU microcode updates in default configurations because they fix processor bugs. The project's name shouldn't be read as a promise that every supported computer runs entirely without proprietary firmware components.
That policy helps explain the shape of this Chromebook import. The release notes describe replacing vendor memory initialization on Haswell Chromebooks with native code and using native graphics initialization on specified older Intel generations. Those are changes to particular parts of the boot process. The remaining dependencies still need to be assessed for the selected board.
The next useful evidence will be reports from more of the imported targets, followed by a decision about which are ready for binary distribution. The 26.10 announcement leaves that testing open and documents the current compatibility problems. Until those reports arrive, a matching board name gives an owner somewhere to begin testing. It doesn't tell them how their laptop will behave after the flash.