12 November 2026
Article published by: Leah Rowe
Date of publication: 12 November 2026
You can find today’s release in https://rsync.libreboot.org/stable/26.11/ 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.10 release. Please note that some of the changes were also present in revisions to 26.10, but this changelog is relative to the original 26.10 release, for safety.


Boards that use EDK2 UEFI payload now only use EDK2 UEFI payload. Users urged to switch fully to UEFI in existing OS installs, with full ESP; consult your OS documentation.
Legacy usage still possible (GRUB, SeaBIOS) using the guidance here:
Re-adding legacy payloads to Libreboot EDK2.
OF NOTE: The CSM module for EDK2, as documented there, is ReBIOS which offers much improved VGA emulation over traditional SeaBIOS or the previously used CSMWrap payload. Actual legacy BIOS-based operating systems work now. For example, DOS games might actually work in FreeDOS. ReactOS and Windows XP were tested - more notes provided below.
Users warned to please adapt their OS installs to UEFI before installing this new release. This same change was made in the corresponding RBoot 26.11 release, codename “Iodine” - formerly known as Canoeboot. This is maintained by the same developer, Leah Rowe, and it was established recently for the specific purpose of proposing RBoot to the GNU project. RBoot is Leah Rowe’s deblobbed fork of Libreboot, with much lower hardware support than Libreboot, but intended for Free Software diehards who don’t mind having slightly broken and/or outdated hardware.
OF NOTE: ReBIOS CSM module tested with EDK2, and it was able to boot ReactOS! Unlike SeaBIOS’s SeaVGABIOS implementation, ReBIOS implements its own full VGA BIOS emulation and it works perfectly with legacy VGA modes. Windows XP also tested on a ThinkPad X220. We can now actually use legacy BIOS-based operating systems in Libreboot, using ReBIOS, but note that VT-d or AMD equivalent is required (IOMMU) as it runs inside a hypervisor with hardware passthrough; this enables operating systems to use real drivers, while it provides INT10h services (VGA) and everything else required in a BIOS. ReBIOS is based on CSMWrap and uses its own heavily modified fork of SeaBIOS as the core - not included in releases, but see notes below. Users wanting to run old operating systems can do it easily, using ReBIOS added to EDK2. Please read the notes below (they also cover GRUB and MemTest86).
NOTES:
Boards using EDK2 are EDK2-only in this release, with iPXE optionally. Users can re-add GRUB EFI, ReBIOS (SeaBIOS CSM) and MemTest86plus to EDK2 using a generalised feature in lbmk: place grub.efi, mt86plus.efi and rebios.efi in efi/ in lbmk, when compiling. If the board uses EDK2, any images mentioned here will be added. Not all required; for example, you could just add rebios.efi.
Libreboot lbmk no longer builds these legacy payloads, but the documentation was updated to tell the user how to build them, or get builds from upstream. The user inserts them by recompiling Libreboot in this new scheme, described in the document:
Inserting legacy payloads in Libreboot EDK2
Please do note: GRUB-coreboot also removed (the coreboot payload). A minority of legacy 32-bit-only Intel/AMD boards still use SeaBIOS. One or two boards that could run EDK2 still use SeaBIOS, because they start with textmode via VGA ROM or libgfxinit; unknown if EDK2 could work (linear framebuffer).
Nearly all boards in Libreboot ship now with just EDK2. This is a simple, conservative default and it is now the responsibility of the user to maintain their own use of the legacy payloads if they wish. Users are advised to upgrade their existing OS installs to full UEFI. Please consult the documentation for your operating system. Libreboot is now boring, conservative UEFI firmware. Libre UEFI firmware. The only one of its kind, at the scale that Libreboot exists at, and will exist at, in ongoing and upcoming development - going EDK2 allows many new feature changes; for example, Kabylake ThinkPads now enable TPM 2.0 by default, which was unstable in SeaBIOS but works perfectly in EDK2.
./mk inject, which would allow distributing firmware images while still avoiding the distribution of these additional files. The sources provided are largely the upstream coreboot sources, plus modifications made by MrChromebox. They have been audited heavily, long before MrChromebox was even added to Libreboot - auditing of the entire MrChromebox project began in early 2025!bios_ or uefi_ to ROM image filenames (coreboot), making it clearer which is which: U-Boot and EDK2 are uefi and SeaBIOS is bios.vendor_model_variant_sizeofflash - backward compatibility added so that old target names can be used for builds.LOCALVERSION to let upstreams know a coreboot log is from Libreboot. This makes confusion with upstream less likely, when users report bugs upstream. This was done, after much-heated discussion.efi/ directory in lbmk: insert any combination here of grub.efi, and rebios.efi or mt86plus.efi - when building EDK2-based targets, these will be added to EDK2. This is skipped on release builds. This lets users re-add payloads easily, in their own builds. Information about this is included in the documentation. Libreboot is EDK2-only now in release builds, on targets that use EDK2. SeaBIOS targets (several legacy 32-bit boards) are SeaBIOS-only. Payloads have been vastly simplified as a result of this../mk release - allow skipping binary builds. Do ./mk release src and it will only generate the src tarball. This is useful for people distributing modified firmware on computers, where they just want to distribute source code. (useful for Libreboot resellers)cpbin=y - set this in target configs to support copying and creating tar archives out of builds from elf/ on a per-target basis, copying the tarball into bin. This was put to use for PCSX-Redux OpenBIOS, Pico Serprog and STM32 vserprog firmware releases. That is to say: image release tarball creation is more generalised across projects. The coreboot logic is still custom, but creates tarballs along the same scheme. Tarballs named thus: libreboot-VERSION_project_targetname - coreboot images omit coreboot in the name, for this release../mk inject: old target names now work, and dummy (nobin=y, release=n) targets added for ThinkPad T440p/W541 MRC targets to allow insertion of legacy MRC on old ThinkPad Haswell images - now the modern lbmk revisions can inject vendor files in Libreboot releases going all the way back to 20221214. This was done because building sources for utils on older releases would likely make build errors. Backward compatibility is essential, if the user simply wants to inject files in older releases. Please note that E6400 VGA support is still gone, because Nvidia E6400 latitude variants were always buggy and worthless to even own, due to bad hardware design and buggy nouveau drivers.bin/ if a target.cfg file for the board specifies nobin=y, because some targets are not intended for general use. This was turned on for the dummy edk2 coreboot targets.skip_gbe_cook=y in the target.cfg file per board../mk inject because E6400 Nvidia support was removed. We now only support the Intel GPU variant. The Nvidia variant was always buggy and never booted reliably on any operating system.cros_vendor_model instead of mrchromebox_model_vendor_uefi to avoid confusion as although the code is MrChromebox, equating Libreboot with upstream might have otherwise caused users to erroneously report bugs upstream. GRU chromebooks also renamed thus: cros_rk3399_gru_bob and cros_rk3399_gru_kevin../mk crosinfo - list chromebook models. Will we re-added as necessary, in a branch, for the next Chromebook update. It makes a Markdown page for the Libreboot website, listing Chromebooks in coreboot../mk import_uboot - import defconfigs from U-Boot, converting to lbmk setup and setting up cross compilers. It works, but actual boards need testing so just having them all in the tree is pointless for now. Will re-add when these are tested. It is a future ambition of Libreboot to become a U-Boot distro, automatically importing and reconfiguring various boards for our purposes. It currently mostly just focuses on coreboot, but U-Boot itself provides initialisation on several thousand boards.nuke.list per project tree, on regular downloads in lbmk and on releases. Previously only on releases. This brings parity with release builds, and confusion can be eliminated by just commiting the deletions before adding new patches for testing, being careful to avoid including the deletion patch. It used to be that when building in lbmk, we would make sure never to use files that got deleted in release builds. This change eliminates all doubt.config/ - simpler and easier to maintain, and in practise doesn’t cause many performance issues. This is because Libreboot’s design makes tracking such artifacts a bit harder, so we just nuke everything before each build../mk inject - this also makes it easy to know which tarball was created in bin/ for a build, as tarballs are ALSO now versioned, according to the lbmk revision. This was a bug because otherwise users didn’t know what the hell they built. Ditto: added a friendly remark at the end, when GbE region available, reminding the user to re-run it if they want to change the MAC address.build_sbase is once again a function instead of a macro, to prevent globbing issues in the code.newvar - it is used now only in cases where we have unknown variables to initialise (variables initialised as per configuration). This reduces the attack surface, in case of future bugs.srclink variable, initially used by EDK targets that relied on adding other payloads like GRUB, to symlink config from other trees to trigger re-build. This was replaced later by resolving project config hashes on the basis of dependencies as well - hashes of build dependencies and fetch dependencies added to the concatenation of hashes on the target build, thus dependency changes now trigger re-builds on targets.forx function and a bunch of other hacky eval logic in the build system. Code was made simpler, and safer. Eval usage was reduced systematically, throughout.rom.sh - GRUB later removed entirely.grubtree variable and instead specified the GRUB tree via payload_grub - and grub was later removed entirely.rom.sh, modularising their behaviour; GRUB support was later removed entirely, in lbmk.fetch function to vfetch to eliminate maintainer confusion, as this is not a generalised fetch function. This is to avoid possible namespace pollution when later refactoring get.sh as it is likely someone (probably me) would write another function called fetch.inject.shGRUB has been removed entirely. However, some development was done on the GRUB payload prior to deletion. Reasons for deletion can be found in the legacy page showing how to re-add GRUB, SeaBIOS etc - modern Libreboot, as in this release, is EDK2-only in release ROMs for most boards, to reduce the maintenance burden. Maintenance of legacy payloads shifted to the user. EDK2 information can be found on the EDK2 page.
However, the GRUB changes prior to GRUB being deleted were:
build.list, so that the user can run e.g. grub-mkpasswd-argon2 post-build.Markdown file for this page: https://libreboot.org/news/libreboot2611.md
This HTML page was generated by the Libreboot Static Site Generator.