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

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.

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.

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.