Canoeboot 26.11 “Carnivorous Olive” released! With full UEFI support.

Return to index

Article published by: Leah Rowe

Date of publication: 2 November 2026

• <<
• < Prev
• >>

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

Canoeboot 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 Canoeboot has added full UEFI support via MrChromebox EDK2 payload. Canoeboot 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 Canoeboot 26.01 release.

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 cbmk. This is the most important change in the release. Now everything else:

These were not added, unlike in the corresponding Libreboot 26.10 release. It’s possible that we can have from Intel SandyBridge, IvyBridge all the way up to Haswell in a future release, as native raminit and video initialisation is available on these boards; the EC firmware could be built from source quite easily. Work will be done on this, alongside Libreboot development.

NOTE: The EDK2 payload was added in this release, for Intel/AMD boards in Canoeboot that are able to use it.

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, with GRUB provided via SeaGRUB configuration.

Basically, these boards actually work for the first time.

The following boards now have an EDK2 UEFI payload available:

• dell_latitude_e4300_4mb
• dell_latitude_e5420_6mb
• dell_latitude_e5520_6mb
• dell_latitude_e5530_12mb
• dell_latitude_e6230_12mb
• dell_latitude_e6330_12mb
• dell_latitude_e6400_gpu_intel_4mb
• dell_latitude_e6430_12mb
• dell_latitude_e6530_12mb
• dell_latitude_e7240_12mb
• dell_optiplex_7010_sff_12mb
• dell_optiplex_780_mt_8mb
• dell_optiplex_780_mt_truncate_8mb
• dell_optiplex_780_usff_8mb
• dell_optiplex_780_usff_truncate_8mb
• dell_optiplex_9020_mt_12mb
• dell_optiplex_9020_sff_12mb
• dell_precision_t1650_12mb
• hp_elite_8300_cmt_16mb
• hp_elite_8300_usdt_16mb
• hp_pro_3500series_8mb
• lenovo_thinkpad_r400_16mb
• lenovo_thinkpad_r400_4mb
• lenovo_thinkpad_r400_8mb
• lenovo_thinkpad_r500_4mb
• lenovo_thinkpad_t400_16mb
• lenovo_thinkpad_t400_4mb
• lenovo_thinkpad_t400_8mb
• lenovo_thinkpad_t430_12mb
• lenovo_thinkpad_t440p_12mb
• lenovo_thinkpad_t500_16mb
• lenovo_thinkpad_t500_4mb
• lenovo_thinkpad_t500_8mb
• lenovo_thinkpad_t530_12mb
• lenovo_thinkpad_w500_16mb
• lenovo_thinkpad_w500_4mb
• lenovo_thinkpad_w500_8mb
• lenovo_thinkpad_w530_12mb
• lenovo_thinkpad_w541_12mb
• lenovo_thinkpad_x200_16mb
• lenovo_thinkpad_x200_4mb
• lenovo_thinkpad_x200_8mb
• lenovo_thinkpad_x230_12mb
• lenovo_thinkpad_x230t_12mb
• lenovo_thinkpad_x301_16mb
• lenovo_thinkpad_x301_4mb
• lenovo_thinkpad_x301_8mb

There targets have EDK2 available, but unlike Libreboot they do not have an EFI GRUB build, so only Coreboot GRUB (seagrub roms) are available, due to lower BIOS region size in these targets compared to Libreboot:

• hp_elite_8200_sff_8mb - this has EDK2-only images and GRUB images, but
• lenovo_thinkpad_t420_8mb - ditto
• lenovo_thinkpad_t420s_8mb - ditto
• lenovo_thinkpad_t520_8mb - ditto
• lenovo_thinkpad_x220_8mb - ditto

These targets, as seen below, do have EDK2 support in Libreboot but not in Canoeboot because Canoeboot’s design uses the vendor’s specified BIOS region size which is smaller and insufficient for EDK2:

• dell_latitude_e6220_10mb - this and the ones below have 2MB CBFS
• dell_latitude_e6320_10mb - it’s just about too small - about 100kb bigger
• dell_latitude_e6420_10mb - 100kb bigger than available in CBFS here
• dell_latitude_e6520_10mb - (2MB BIOS region on these latitudes)

Other targets (e.g. ThinkPad X60, T60, D945GCL5, MacBook1,1, 2,1) are either 32-bit-only or have insufficient flash capacity for EDK2. NOTE: Even where EDK2 is available, the legacy SeaBIOS/GRUB setups are also still available, but UEFI will be Canoeboot’s preferred payload (via EDK2) in this and future releases.

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 Canoeboot 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 Canoeboot 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 Canoeboot.

Several Canoeboot 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 Canoeboot supports.

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

• Windows 10 and 11
• 9front (fork of Plan 9)
• various other UEFI-compliant operating systems
• Linux UKI bootloaders, systemd-boot, etc. UKIs work perfectly now, booting from EDK2. Modern Linux distro setups now work (GRUB not required).
• OpenBSD with EFI bootloader and GPT partitioning (older SeaBIOS txtmode can only do MBR partitioning in Canoeboot)
• FreeBSD in UEFI mode - txtmode no longer required!
• ReactOS did not work, unfortunately (no UEFI support)
• RedoxOS probably works too.

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. Canoeboot finally has it as well.

This change alone is part of a much wider effort to modernise Canoeboot, and I’m only getting started. The next Canoeboot 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 Canoeboot, allowing us to support much newer hardware and it basically makes Canoeboot much easier to use; I expect Canoeboot 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!

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 Canoeboot release.

Nearly all major upstream revisions updated:

• Flashprog: updated to 24 September 2026 revision
• EDK2: imported version 26.09.2
• GRUB: updated to version 2.16
• Coreboot (default tree): Updated to 8ce4c91c41da3f042979f92095149a85bc93227d commit ID as of 18 September 2026.
• Coreboot (fam15h): removed (4.11_branch tree) and replaced with:
• Coreboot (fam15h_15h): 57e26bdcd959808c0171164f3c6197d4a347c3b2 commit ID as of 27 May 2026. This is a heavily improved fork of coreboot from version 4.11_branch, for improved initialisation reliability on AMD FAM15H hardware e.g. ASUS KGPE-D16.
• SeaBIOS (coreboot payload): Updated to 81ec9ec0bcf45df11fb7f98339ec9036b546fca0 commit ID as of 28 July 2026.

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 cbmk 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.

No new hardware was added in this Canoeboot release, but a lot of interesting features have been added to pre-existing hardware that Canoeboot supports.

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

• EDK2 payload support on most Intel/AMD boards with at least 4MB flash. This uses the MrChromebox version of EDK2, and Canoeboot has made extensive modifications e.g. add GRUB EFI build; this is provided as backward compatibility with older lone GRUB payload setups and should still boot existing Linux distros in a manner compatible.
• iPXE boot method added via EDK2 payload (ESC menu) - only EDK2 (not available in the lone SeaBIOS payload on older boards).
• Added fwsetup command in a GRUB menuentry on the EFI version, which boots back into the edk2 setup menu.
• GRUB at_keyboard driver: always force scancode set 2 with translation. This was already done, but only on the coreboot target; it is now also done on the EFI target, by just applying it universally to all targets. This is because it’s possible to use it with PS/2 keyboards on EDK2. It mitigates buggy PS/2 controllers that might not report modes correctly even when set, as on the Dell Latitude E6400.
• Scan every ESP directory in a given partition, via asterisks, on the GRUB payload (EDK2 and coreboot targets). This means that it will boot a larger number of non-UKI Linux distro setups if they use GRUB or Syslinux configs.
• TPM enabled where available, on all targets that use EDK2.
• Added ./mk test command which aggressively builds everything, much more than even ./mk release - it intentionally disables use of caching, so that downloads are aggressively tested as well. Config-related commands are also tested. This is a brutal stress test command used to find build errors.
• Flashprog: always keep the flash IC hot during command loops, rather that doing it in a toggle. The --workaround-mx option is retained, but no longer does anything as its behaviour is always applied. This improves general reliability as a lot of users don’t know about this option anyway. More people can reliably flash their boards now.
• New mkhelper type added: preconfig. This lets you run custom logic prior to configuration on a given project that uses config files. It also works on noconfig projects. This is used for example on coreboot, to build utils.
• Removed used of ccache everywhere in the build system, as it was causing subtle build errors (and possibly code bugs) in several stress test scenarios. We’d rather wait a bit longer for a reliable build. CCache is really only meant for development, not production.
• Removed the -c and x (clean and xgcc-clean) flags in cbmk, as they are largely superfluous; cbmk already auto-cleans everything before build anyway, to remove all build artifacts, and aggressively caches builds out of tree based on config metadata, deleting and re-fetching sources from local cache as required. These options were useless.
• Properly skip builds if makefile checks fail; this allows single-tree projects to build, by preventing error-prone use of copy_elf where no files exist.
• mk: Removed GCC/GNAT version pairing as upstream (coreboot) now does this its its buildgcc script. It’s redundant in cbmk. The coreboot version is better because it simply errs and exits, instead of trying to continue; the latter is what we did, which might actually cause more bugs in some cases. Better to fail hard, than corrupt the build.
• Danish keymap added for GRUB.

A lot of major design changes have been made!

• GRUB boot config simplified; only one menuentry now for boot, which boots everything, trying USB first. It selects the first config it finds, but you can press ESC to cycle through to the next one in the loop. Useful for dual-booting multiple Linux distros.
• Short defconfigs now used on coreboot, instead of full configs. This allows for easier maintenance, and cbmk has been modified to accomodate them. The inject scripts still resolve full configs automatically at runtime, needed for scanning paths at build time. The use of defconfigs reduces the chance of erroneous changes in config during updates, and makes use of olddefconfig possible instead of the less-reliable oldconfig command.
• New safety check: verify that a path prefix is set, when using it in logic. Otherwise, it’s possible that we might have directory escape bugs in cbmk. This is checked relentlessly, throughout the build system.
• No longer export XBMK_CACHE as it’s now hardcoded in config. The new handling is much stricter, and less likely to regress in future revision. This was done to reduce the possibility of a directory escape bug in cbmk.
• Fixed GRUB module list no longer used per GRUB tree. Instead, all modules are added per target but a blacklist is applied, configured per-tree.
• GRUB Syslinux and GRUB scanning now combined into one function, on GRUB configs. General simplifications to the GRUB config.
• GRUB is now one source tree, with multiple targets all re-using the very same tree where differing configurations are used.
• Always use --mirror git clones on include/env/get.sh. This makes cloning revisions more reliable on all projects, especially ones where we use revs inside branches other than main.
• When building EDK2, we use coreboot’s build system, but when doing it this way, custom_ prefix is not used in image file names. Proper edk2 prefix is used.
• Added a noconfig variable that can be set by build trees/targets, where they are multi-tree but no configs are used. This makes it appear under a fake name called noconfig, e.g. elf/grub/default/efi/noconfig/grub.elf when compiled.
• get.sh: use -L in find command, because some projects now use symlinks to metadata from other projects to ensure rebuilds. For example, edk2 coreboot targets (dummy targets) rely on grub and seabios efi builds. When these builds have to change, we need to ensure that the edk2 coreboot build is re-done. Here, we mean the find command used for finding files to hash when checking whether a given project has changed in build system setup.
• Properly sort submodules by directory name, so that recursive submodules can be handled in projects. This is in the submodule handling on get.sh.
• get.sh: support arbitrary submodule config path, for projects that use multiple versions of a submodule. For instance, EDK2 uses multiple versions of brotli.
• Stronger use of make distclean on projects before building, made feasible due to Canoeboot’s aggressive out-of-tree caching of project builds based on metadata checks in cbmk.
• Allow noconfig=n on a project, which allows it to be multi-tree and use the same tree on different targets, even when build configs aren’t required; in some cases, configs are done exclusively in mkhelper settings. This is part of Canoeboot’s decision to make all projects multi-tree, alongside allowing use of N upstreams per project instead of just one upstream.
• Simplify release=n handling in cbmk; don’t execute mkhelpers. Skip source fetches if release=n, so that the corresponding source won’t be downloaded.
• init.sh: Portable date usage; git’s own date handling now used. We no longer rely on GNU-specific extensions to the date command, for git repository initialisation on release builds.
• Allow running mk from outside the main work directory. The build system now changes work directory accordingly.
• Enable 3-way-merge when running git am in get.sh - this enables easier updates on project revisions.

• Most boards still use CBFS or NVRAM option table (static option table, or modify CBFS). A few boards, like the HP EliteBook 820 G2 and Topton X2E N150, use SMMSTORE-based option config but it has not yet been set up in cbmk.
• Set me_state to Disabled by default, tree-wide in coreboot (default tree). We already set the HAP bit in IFD anyway, but this is an extra layer of disablement, to make sure that the Intel ME is deader than dead.
• Optimised GRUB modules; all FS modules now included, fewer errors shown in the GRUB shell at boot. Modules generally optimised to ensure that there is still not a lot of flash space used compared to the default upstream setup.
• Added xxd to dependencies, needed by CSMWrap when making SeaBIOS EFI builds as it runs xxd -i on SeaBIOS CSM builds to create header files that are then wrapped inside CSMWrapper’s shim code. CSMWrap removed in 26.11rev12.
• Scan all GRUB configs on all devices, without using fixed device lists in GRUB. Instead, asterisks are used. More BTRFS subvolumes are also checked, also via use of asterisks.
• General cleanup on GRUB configs. Redundant features removed e.g. manipulation of gfxterm. The default setup works fine. GRUB never worked reliably for on serial output anyway and most modern computers don’t support any of the interfaces that GRUB supports in this context.
• Added ImageMagick to dependencies (needed for EDK2 boot logo).
• SMMSTORE enabled by default, on all targets that use EDK2 as a payload. This means that Canoeboot users can now enter a standard setup menu at boot time, configuring their machines (e.g. boot order) in a way that is both persistent and does not require re-building the firmware.
• Added 4MB and 8MB targets for KCMA-D8 and KGPE-D16 mainboards. This, along with use of the 15h.org fork of coreboot on these boards, for improved raminit and various bug fixes. It uses AMD AGESA source code instead of the custom source code written by Raptor Engineering. The modified AGESA code has better CPU and memory initialisation, supporting more hardware combinations and it supports higher amounts of RAM.
• 256KB SMM STORE used on all boards. This is a Canoeboot-specific setup, whereas Libreboot can also use 512KB on some boards.

• Preventative build fixes: removed used of -Werror on all projects, where feasible.
• Fixed a hanging bug on ThinkPad X230 targets, caused by an optimisation - now reverted for this fix - that optimised the CAR setup in coreboot. This fix reverses coreboot revision 97dbfd3098ae12ef3f51e5f95cd6d66c25214205. This revert was done by HustlerOne in their new Snowboot project, and copied from Snowboot into the Canoeboot project.
• Added fake menuconfig Make options to several projects, so that the related mk options don’t cause build errors (instead, a harmless no-op now occurs).
• mk: Only copy defconfigs back when running config commands if they actually exist. This fixes ./mk -s seabios which never saves a defconfig file.
• Backported several build fixes to our early 2025 revision of U-Boot, so that it builds on modern distros e.g. latest Arch Linux updates. (needed so that GRU Kevin/Bob chromebooks can continue to build).
• Removed src/gpio-scripts due to unclear licensing on the version used. (no license given on the changes to it, forked to standalone from coreboot where it fell back to coreboot’s COPYING file, but the fork repo did not have any licensing in it whatsoever - what changes were made was also unclear as a result).
• Safer handling of defconfigs; stricter error checks, including on noconfig projects.
• Fixed missing infinite loop detection in mk when resolving trees/revisions in projects. Trees that refer to other trees infinitely are now detected.
• Fixed pico-serprog build errors on GCC 16 (tested on the latest Arch Linux)
• Use std=gnu2x on coreboot/default instead of std=gnu23; gnu2x is code compatible with gnu23 on newer GCC versions, but older versions used in e.g. 2024 Linux Mint release will fail to build otherwise. This fixes older distros with no behaviour change on newer ones.
• ONLY skip make when if_skip_build is set in the main mk script, for more thorough mkhelper execution on all projects.
• Stricter preventation of build routine in GRUB when dry build mode is used; in some cases, it may have tried to add a non-existent GRUB payload to a non-existent ROM that was never compiled. Checks like these have been tightened up and generalised everywhere in cbmk.
• Added missing error handling on command -v usage in a few places when setting up cbmk.
• Preventative fix: call x_ in mk, wrapping xbmk_init. The latter never returns non-zero status, so this fix is purely preventative in case the function is ever redesigned at some point to do that.
• mk: Fix globbing issue in multi-tree command args. We previously populated a string with arguments, but now we use dollar-ampersand and cycle through arguments using shift which allows for proper double-quoting to be handled.
• Fully export git author/commit date when re-initialising cbmk on release builds. This is done on every related git command, for deterministic operation.
• Fam15h coreboot: patch out __unused variables and cast them to (void) instead, where unused, to prevent build errors in GCC 16.
• Gentoo Linux dependencies setup added to cbmk.
• Fix offline GRUB builds. The build system caches sources and repos, but GRUB had custom logic in it for downloading unversioned PO files from translationproject.org - so when I did my FOSDEM talk, my demo failed because the internet was down, while I wrongly believed I had everything cached. GRUB was modified to not download the files, and cbmk caches them instead. They are also now version-checked, by virtue of checksum; no versioning is actually provided upstream, but their contents were checked and further updates will inspect the diffs between them. Basically, whatever is on translationproject.org pertains to the current HEAD in GRUB. It’s fine because the way gettext works is that if a literal string is not defined, it defaults back to original language. In this context then, use of the wrong PO files will just result in some sentences not being translated. Still, a bug in the way the files are handled might allow for a… buffer overflow, on unversioned files that GRUB was downloading without checking hashes. Yes. Canoeboot fixed this reproducibility problem by forking the repository containing the files, keeping it static. Next time I do a talk, my demo won’t fail. I fixed this literally a few hours after my talk.

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

• Generally safer use of macros (use brackets).
• Removed errno-based error handling. Just return zero or one, based on logical errors, but do not rely on the status of errno for error exits. Only use return values as appropriate to POSIX in libc functions. However, errno reset is handled more reliably accordingly, after return from libc functions; not required but also not counterindicated by POSIX. - dell-flash-unlock errno handling also fixed in the same way. We previously relied heavily on errno for exit, in ways that were not portable. Not all libc will properly reset it, and may set it randomly even when a given function logically returns with success. Any number of things could set it, so it’s not a reliable mechanism for general error handling.
• Don’t use -pedantic flag - also remove this on spkmodem-recv. Reduces the chance of pedantic build errors based on warnings.
• General correctness fixes; bound checks, proper handling of word alignment, use of uintptr when converting pointers, etc. The code is generally much safer, in terms of memory management, as a result of extensive auditing.
• EINTR-safe wrappers for various functions; loop until EINTR clears, where error occurs, otherwise err-exist on non-EINTR errors. Properly ignore EINTR on close() if function returns with error (EINTR on close is not an error condition in POSIX, and the descriptor should be disregarded in such scenario).
• More testing and fixes for OpenBSD, especially on memory management (much stricter libc in OpenBSD).
• Generalised I/O functions for libc functions like read, write,preadandpwrite` - EINTR-safe, with stricter (than libc) checks against incomplete writes and such.

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 cbmk has been reduced, in spite of its advances in this release.

Specific cleanup includes:

• Projects under config/ centralised better, e.g. config/module/coreboot/ instead of config/coreboot. The directory config/ifd/ is moved to config/data/coreboot/ifd/ as it’s only ever used from coreboot.
• The config/ directory is generally better organised now, with more unified placement of files per-project.
• Systematically removed unused variables in the build system.
• mk: new forx function allows macro-like shorthand for loops, greatly simplifying much of the code.
• Removed several redundant checks in the build system, and generally tightened up all error handling.
• Various random and minor code cleanups; minor dead code removal in the build system.
• Generalised several macro’d mkhelper checks in cbmk, refactoring and reducing overall code complexity.
• lib.sh: Made build_sbase function a macro instead, so that it can be changed all in one place. It’s literally just one command (make -C util/sbase).
• Simplified add_uboot logic as it is only needed now for ARM64. The conditional logic for x86 was removed as we no longer use U-Boot on x86 at all; EDK2 is now the preferred payload on x86, for UEFI.
• Removed ccache from dependencies as we no longer use ccache, for reliability reasons.
• inject.sh: removed end message confirming successful insertion, and generally simplified all variable initialisation.
• release.sh: Removed the -m option as it’s useless. There is no context in which we want to generate a source archive without also building binaries. What’s the point in doing half a release? This is dead code. Knobs are for nobs.
• Unrolled several loops in cbmk, generalising them into macro-like functions. This allowed for a decent code size reduction while also increasing code readability. Macro-like programming is quite feasible in sh when you do it right.
• Used awk heavily in certain parts of the build system, to further unroll a few loops, especially in the err function.
• Removed u-boot-specific make-clean handling in mk; mk is more generalised now anyway. U-Boot was making use of git-clean but only on cbmk Git, not releases; so what’s the point? We want the behaviour on either to be in as much parity as possible, and doing unnecessary work is, well, unnecessary.
• Greatly simplified the findpath function in mk. It’s now one line of code, using forx. (wrapper function for readlink -f and realpath.
• Added error check (stricter one) on xbmkpwd initialisation in mk.
• Removed xprintf in mk; we now just printf ampersand into awk. Easy.
• Simplified xbmkpwd initialisation in mk; we now find the path to mk and cd to its base directory, which thus becomes xbmkpwd.
• mk: run xbmk_init from main script, not init.sh. This makes it clearer on first reading, where xbmk initialisation is called from. We do it just below the include of init.sh.
• Moved tree.sh into mk (merger). Everything centralised there, with custom functions now shimmed.
• All includes now done in bulk, and everything called from the main script. We previously included tree.sh (later merged into mk) conditionally. Now absolutely all state is global, which enabled further code simplication and variable cleanup.
• Simplified get.sh considerably. A lot of logic, especially submodule handling, was aggressively generalised.

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 cbmk 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:

• Still provided libc-like behaviour when requested, but:
• Stricter checks against use of world-writeable non-sticky directories.
• Generally stricter error-exit handling.
• Relentless checks against changes to files during operation/check, inode changes and so on. Checking that a file wasn’t operated on by another program - basically, openat2-like security was attempted to implement in userspace, though openat2 was also enabled as a fast method on Linux.
• Own implementation of rand, wrapping around Linux getrandom and BSD arc4random. It provided various functions for rand, including one that matched the semantics of arc4random_buf (rset function in libreboot-utils).
• Descriptorless operation in general, on files and directories.
• Pathless operation where possible - including userspace directory walking and sandboxing.
• Unveil-like restrictions in userspace (and pledge/unveil usage in OpenBSD).
• Use of symlinks disabled by default.

…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 cbmk 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 cbmk 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 cbmk 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:

• Edge detection along with amplitude, for more reliable operation on noisy signals
• Recalibrate timing to signals periodically, adjusting for tone. The idea was ta allow for the tone separator to drift over time, and have our code adapt to subtle changes to reduce the amount of noise. Right now, spkmodem shows a lot of noise on poor signals.
• A bunch of other equally useless changes.

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.

Just two canceled works:

• Updated U-Boot to a late 2026 revision on ARM64 chromebooks, but the bootflow menu looks ugly now and barely works. Upstream completely broke it. Therefore, we still use the early 2025 revision of U-Boot that was there in the Canoeboot 26.01 (January 2026) release.
• GRUB keymap support via parsing of keymap.gkb in CBFS when booting with EDK2. This was canceled because a better method will be implemented post release; use of HiiDatabase and a graphical config menu in EDK2 to change the keyboard layout and locale. This will be written to SMMSTORE and also used by payloads. For example, the GRUB EFI payload could read from SMMSTORE to know locale and then change its language accordingly, using its existing gettext integration (GRUB already supports internationalisation).

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 Canoeboot’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 Canoeboot 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; Canoeboot 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:

• https://arxiv.org/abs/2507.09089

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 Canoeboot 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:

• https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

The fork in question, of U-Boot, is heavily AI vibe-coded and thus useless to Canoeboot. 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 Canoeboot 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 Canoeboot 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 Canoeboot 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. Canoeboot 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: It was brought to my attention that the author of crabEFI uses AI heavily in new works, and indeed crabEFI itself seems to contain AI-assisted commits. This violates Canoeboot’s rigorous anti-AI policy, and thus crabEFI will no longer even be remotely considered for use in cbmk.

• Unpredictable toolchain setup. Most people use e.g. rustup and they set up all sorts of custom environments. Much less predictive than e.g. LLVM/GCC provided in distros. Libraries and such are provided by Cargo, instead of distros, and users often leave everything out of date, leading to breakage.
• Rust is not standardised; the specification is implementation-defined, and code written today may still compile in the future when the spec changes, but code behaviour would naturally change as a result of the latter.
• Given the above, we would have to bootstrap rustc/cargo ourselves, and we would have to do it from source (from a compiler like GCC which already has source bootstrapping courtesy of the Guix project and others).

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 Canoeboot 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, Canoeboot uses EDK2 to replace U-Boot and it has been enabled by default on all boards. Clankers are banned from Canoeboot.

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 Canoeboot’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.

Import from Libreboot 26.11 initially shipped with only EDK2 UEFI payload on 64-bit boards, which meant that you needed to modify cbmk to get the old bare GRUB/SeaBIOS setup (SeaGRUB) back.

Subsequent revisions to the release restored BIOS mode images, so now you have a choice. Example:

• lenovo_thinkpad_t480_16mb

The new naming scheme makes sorting through images easier. Image names with seabios or seagrub in the file name are BIOS-based (legacy setup).

Images with edk2 in the file name are UEFI-based; 26.11rev10 and higher also prefix images with bios_ or uefi_ - U-Boot and EDK2 images are uefi_, while SeaBIOS and SeaGRUB images are bios_.

Issues with S3 resume were found on Linux distros in the initial release, when booted using CSMWrap; these will of course be fixed, in addition to other CSMWrap errata, in a future revision. Moreover, it made sense to continue offering the older setup as some users may prefer it. CSMWrap removed in Canoeboot 26.11rev12, so you must use bare SeaBIOS now if you want SeaBIOS.

The plan initially was to make cbmk much simpler, thus EDK2-only on most boards. For the time being, Canoeboot will maintain dual configuration in this manner.

A new, more unified naming scheme was also introduced in revisions to the release, as above. For example, the arm64 images all say uefi_ but actually use U-Boot, not EDK2; U-Boot implements a subset of the UEFI specification, and it is the default payload on ARM64 Chromebooks. Intel/AMD targets with UEFI all use EDK2.

FreeBSD and DragonFlyBSD users who set up on SeaBIOS txtmode before are advised to once again choose one of the bios_ images, picking any SeaBIOS image with txtmode in the filename. This is for bootloader compatibility, irrespective of further setup - conversion to EFI is recommended, so that you can use the newer EDK2 setup.

This Canoeboot release also inherits several revisions to the Libreboot 26.10 release, detailed below. The bits that Canoeboot did not inherit are not listed:

Bugs were found in the main Libreboot release, later fixed, on legacy hardware where EDK2 was not used; here, we had standalone GRUB and SeaBIOS payloads. On setups with GRUB, some users reported broken keyboard input. This is because some machines need a timeout loop during PS/2 keyboard initialisation, and I’d overlooked this fact when making GRUB a standalone payload on legacy hardware.

I’ve thus made GRUB only available in the form of SeaGRUB once more. Images with GRUB now start SeaBIOS first.

Here is the full list of changes, from recent to oldest:

• CrabEFI payload added in legacy boards that cannot have EDK2, but marked source-only as it does not yet boot from SeaBIOS or GRUB payloads and thus should be provided as a standalone payload, for which there has been insufficient testing - it may or may not be provided in a further revision release of the Canoeboot 26.11 release series, or it may simply be provided in the next major Canoeboot release. Removed in later revisions for technical reasons, and now banned because it was found that crabEFI is an AI-assisted project.
• Added 32-bit memtest86plus builds on legacy hardware, where previously only 64-bit builds were provided on 64-bit capable hardware. This brings legacy hardware more into parity.
• Enable use of EDK2 payload on Dell OptiPlex 780 variants, as the default payload optionally booting GRUB EFI.
• Marked q45t m target source-only due to lack of testing.
• Marked Gigabyte GA-G41M-ES2L source-only due to lack of testing.
• Enforce use of SeaGRUB on GRUB setups. Do not allow standalone GRUB payload, because GRUB is not always reliable and could lead to softbricks if its input drivers fail; SeaBIOS provides more reliable keyboard initialisation, which mitigates GRUB issues. This restores the behaviour from previous Canoeboot releases.
• Blacklist usbtest module from EFI GRUB, because GRUB EFI does not handle USB (EDK2 handles USB).
• Removed the bsd module from GRUB as we already removed other BSD modules; BSD users are expected to boot with SeaBIOS or EDK2 as GRUB is not reliable for booting BSD. Also removed some redundant keyboard modules on the EFI GRUB target, as GRUB does not handle input drivers in EFI mode (EDK2 drivers are used).
• Made the anti-AI policy in AGENTS.md even more persuasive.
• rom.sh: Avoid grep when scanning defconfigs, for more reliable operation as grep returns non-zero status on both file system error and logical error; now, we use a while read loop, and thus error handling is more reliably separated from syserror and logic error. This enables more fine-grained error control when processing config files.
• rom.sh: Always make image tarballs even when not building in release mode. This makes versioned builds easier to handle, if dealing with multiple versioned builds of the same mainboards.
• Added LOCALVERSION to coreboot builds, so that dmi strings would say libreboot plus version number. This makes it easier for upstream projects to detect that someone is using Canoeboot when they send bug reports. This was done due to a complaint made by another coreboot project and rather than say all of what I wanted to say, I decided to honour their request. It just seemed like the right thing to do, as this affects all upstreams. It also means that Canoeboot now has a voice inside your DMI strings and inside the cbmem log, where it is also printed via printk.

Minor cleanup:

• grub/default: Removed an errant symlink in the config directory, that did not otherwise cause any behavioural changes whatsoever in the build system.
• EFI GRUB config: Don’t load non-existent at_keyboard and usb_keyboard modules. We don’t use these in EFI, because EDK2 handles everything.

CrabEFI was set release="n" in rev1, because it’s not yet ready for use as a standalone payload and is currently inserted for loading from SeaBIOS and GRUB; this isn’t working yet, so rev1 made it such that CrabEFI is not inserted into images via scripting in include/fw/rom.sh - this alone is sufficient and this third revision simply removes release="n" - otherwise, users could not build images in the source code tar archive unless they set the XBMK_RELEASE environmental variable. - CrabEFI banned from Canoeboot becrause it was found that it contains AI-assisted code.

This is because release tarballs disable source fetching, by virtue of whether or not a CHANGELOG file is prevent - absent in the Git repository but generated in release archives.

REMARK: MrChromebox sources also do not fetch/compile in the release archive, but this is OK because we don’t provide images for those in this release. You should just use the cbmk Git repository to build these.

Removed CrabEFI as I plan instead now to port edk2 on 32-bit, from the MrChromebox tree. This will be easier as the latter is maintained on 64-bit anyway, and work likely already exists. It’s better just to always standardise on one project. CrabEFI was only added experimentally anyway and wasn’t provided as a build in rev3. Just delete it.

Other changes:

• Re-added SeaBIOS/GRUB classic setups, on boards that recently had EDK2 added. The EDK2 setup is still present, and recommended; we now provide two tarballs per machine that has EDK2: one with EDK2, and one with SeaBIOS plus GRUB. On the SeaBIOS setups, txtmode images are also present which allows for use of text-mode bootloaders e.g. BIOS FreeBSD bootloader.
• Tidied up some defconfigs (a few board name strings, VBT paths).
• Rename all board targets to include the vendor in the name, and _bios or _uefi at the name.

The re-addition of BIOS targets alongside UEFI, where both are present on a given mainboard, is likely to remain permanent even when CSMWrap bugs are fixed. I initially reasoned that it’s best to keep things simple from my point of view, but it’s better to just provide users choices. With this, most users shouldn’t have any problem as the setup they’ve always used is still available, and they can otherwise upgrade to the new setup at their leisure. Yes, they call this: the principle of least surprise.

The reason I did this was also that S3 resume is currently broken on CSMWrap but not the bare SeaBIOS payload. Thus, we provide actual real BIOS setups alongside EFI; the EFI build also has CSM, but the SeaBIOS build does not have EFI.

Keymapped images were also re-added on the classic BIOS (SeaBIOS plus GRUB) targets; the EDK2 targets are still locked to only one keymap.

Reverted some defconfig changes that changed VBT path and SMBIOS vendor strings, to prevent build errors. I removed these, believing them to be redundant on a handful of boards, as they’d be defined in Kconfig. I’ve restored them, and also corrected them, e.g. Dell OptiPlex 780 variants now have correct board names in these strings.

The most pedantic revision of all, but I wanted to make everything a bit more clean:

• Renamed board names more consistently once again. For example, the T440p targets no longer say libremrc as it is a given now that we use native raminit on these boards. Consistent with W541 which also has libremrc/nri but did not specify thus.

Please note: these board target names make vendor file injection break on older release archives. Please rename accordingly, or just use image tarballs from the current rev6 release and beyond. Naming scheme is stable now in Canoeboot, thus:

• vendor_boardname
• vendor_boardname_variant

For example, variant can be 8mb on lenovo_x200_8mb.

Renamed more boards, for more consistent naming across all mainboards and platforms.

Renamed chromebook_ to cros_ in coreboot chromebook boards, for more consistent naming across different google products.

The new naming scheme is also more friendly to scripts (build systems).

Renamed cros rk3399 targets to match u-boot and coreboot target names. This affects gru bob/kevin chromebooks.

None of the changes from this rev were included (they were all for boards that Canoeboot does not support in this release).

Minor fixes and usability improvements:

• mk: Errors now properly printed to stderr, where an error occurs in cbmk.
• General simplifications to cbmk, for example GRUB EFI and GRUB coreboot are now compiled in the same coreboot targets; coreboot targets that have EFI and BIOS images have just one target now, not separate _bios or _uefi image sets. The same given target now has both types of images contained in each tar archive.
• inject function: the name of the tarball is now printed, making it more clear to the user that a tarball was modified.
• Dummy EDK2 builds not generated in bin/ as they are not intended for general use. Only the UEFIPAYLOAD.fd files from elf/ are used anyway, so to avoid confusing users, only the final real board build is provided in bin e.g. ThinkPad T480 build.
• EFI- and non-EFI targets on x86, where EDK2 is supported, both now have SMMSTORE in exactly the same configuration. This ensures that users swapping between the two can do so interchangeably, while preserving SMMSTORE.
• Removed experimental EDK2 builds on ASUS Fam15h boards as they were never intended for release anyway; these targets shall continue to use the legacy SeaGRUB setups as it is more rigorously tested on these machines. Users can still add EDK2 to the build if they want.
• Backwards compatibility introduced in ./mk inject commands, such that it works on tarballs from older Canoeboot releases. This is to mitigate the fact that the image names were changed heavily in this and other 26.11 revisions.

Of note, this revision backports a major coreboot patchset from upstream:

Nicholas Chin has done extensive rework on battery handling for Dell Latitude models. It is no longer done in SMM. It is now done in a generalised ACPI framework, and existing S3 fixes are done there (patching to prevent DRAM from powering down in S3).

This patchset also adds support for battery status in EC, via the new ACPI patching. This means you can now monitor battery usage / charge level in ACPI-enabled operating systems.

The following features are still broken (and previously broken too), on Dell Latitudes:

• Brightness controls via hotkey(software-based controls work except on the Latitude E4300)
• Physical wireless switch (soft enable/disable works fine)
• Battery charge thresholds (vendor firmware seems to have it on E6430, but coreboot and Canoeboot do not).
• Wake (S3 resume) on lid open; must press power button to wake from suspend, but this was already true.

The new EC handler code is more efficient, on Dell Latitudes. Doing it all in SMM violates one of coreboot’s main design criteria… putting everything in SMM is bloat. Doing it all in ACPI is just more performance-efficient, and easier to maintain. Note that these patches are still under review on the coreboot project, but they were deemed stable enough for a Canoeboot release.

The Canoeboot 26.11 release series has one extra dependency compared to the master branch of cbmk: 32-bit libc headers needed on 64-bit build hosts, for 32-bit memtest86+ builds.

Memtest86+ isn’t cross-compiled on cbmk, and not every distro will have 32-bit headers available for libc, so it’s 64-bit-only in cbmk master. 32-bit memtest is used on 32-bit-only hardware like ThinkPad X60, as a nice-to-have.

E.g. lib32-glibc package on Arch Linux.

Use of x86-64 is assumed, when building Canoeboot releases. We do also have 32-bit support, for building 32-bit machines on 32-bit hosts. For example, a Thinkpad X60 can be used to build X60 images in cbmk.

Please just make sure to have 32-bit libc headers available on 64-bit hosts when building the 26.11 release series - maintaining this dependency in the main branch is unacceptable, so cbmk would have to cross-compile payloads, which is in fact on TODO but not currently handled (cbmk uses host toolchains for nearly everything except coreboot and U-Boot, which are both compiled with crossgcc, but non-U-Boot payloads are built with the host toolchain).

Minor tweaks to RK3399 coreboot chromebooks (fix payload setup). Switching to defconfigs nuked CONFIG_PAYLOAD_NONE for some reason - more investigation needed, but rk3399 configs were switched back to full configs for now. This bug does not affect Intel/AMD boards, so they are still defconfig. Without this setting, cbmk’s payload insertion is skipped. This is a bug upstream that needs to be fixed, mitigated for now in this revision release.

Moved RK3399 chromebooks in coreboot to their own tree, for coreboot and u-boot, both trees named cros_arm.

CSMWrap payload deleted from EDK2. It was decided that Canoeboot 26.11 would be UEFI-only in earlier revisions, but I later re-added bare SeaBIOS/SeaGRUB payloads which makes CSMWrap redundant. If you want SeaBIOS, then please use the SeaBIOS images or run CSMWrap yourself; you can use CSMWrap builds in ESP, booted from EDK2. Bundling it in cbmk is a maintainer burden, and several major bugs were reported in CSMWrap (broken S3 resume, weird graphical issues on some boards, etc). My OpenBSD installation, that I use for my LibreWolf port updates (I maintain the LibreWolf port in OpenBSD) also crashed and brought down my entire package database; it’s possible that CSMWrap may have produced buggy conditions that led to this, though it could have just been a bad SSD.

Yes, CSMWrap is a liability to maintain in cbmk. We already know that the bare coreboot payload of SeaBIOS works well, and this is available on most boards. We will provide this instead.

Users are still recommended to use the new EDK2-based images. Note that the GRUB EFI and Memtest86+ EFI builds are still available in EDK2, and these do provide value. GRUB EFI especially, can be used to unlock encrypted /boot and bypass the need for an ESP, while still having an EFI runtime in the Linux distro of the user’s choice.

This change is permanent. We will no longer provide CSMWrap builds in Canoeboot. Please note: SMMSTORE is still present, intentionally, on SeaBIOS images, so that the user can switch interchangeably between SeaBIOS and EDK2 images via FMAP-based flashing (e.g. flashing only the COREBOOT section in FMAP). This is an intentional design choice, on the understanding that the lesser amount of space used in flash by payloads (on SeaBIOS setups without EDK2) compared to EDK2 images, is less than the cost of a SMMSTORE region in flash. Therefore, this provides a sensible regime upon which the user essentially does have, in a roundabout way, the benefits of a CSM except that they have to re-flash to get a BIOS image.

We’re not the proprietary vendors. Users can just build whatever they want in Canoeboot. It’s better to keep setups simple, so providing two versions of SeaBIOS is pointless.

Several major design issues exist in CSMWrap, such as hogging an entire CPU core, and these design issues are caused by the fact that CSMWrap is designed to work on proprietary UEFI firmware where they don’t have access to firmware, for instance they can’t use SMM. Here in Canoeboot, we could properly integrate CSMWrap and remove many of its limitations, but this would mean forking CSMWrap - which then means we are maintaining a fork of SeaBIOS, while still using SeaBIOS upstream on bare metal. Pointless. Completely pointless work.

Thus, CSMWrap was removed. It was assumed that it would be more stable in the release, and that we’d only do UEFI images, but this design change was canceled.

Fixed a critical remote code execution bug in EDK2, as reported by Intel’s Tianocore Security Advisory here:

https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m

An unchecked bound on incoming ICMP packets allowed attackers to send large packets during the PXE boot window, which could allow the ICMP buffer in EDK2 to overflow and, hence, the attacker could run unsigned code in an unprivileged context.

Tianocore released this patch to fix the CVE:

https://github.com/tianocore/edk2/pull/13302 - fixes CVE-2026-97631; users who did not boot with PXE were unaffected by this issue.

Backported a patch from MrChromebox which fixes SD card booting on (tested models) ThinkPad W541 and Dell Latitude E7240:

https://github.com/MrChromebox/edk2/commit/c205cebb1a534261c9aef428c37f889c3661e2cb

Fixes a hanging bug in EDK2 when booting operating systems via SD card on affected hardware. The fix is done by reverting a previous patch that forced eMMC probing as some soldered-down mmc flash may report itself as removeable; see notes in the patch, linked above. This patch was backported into Canoeboot EDK2, for the 26.11 release series.

Removed forx function in the build system, removed unused srclink variable, don’t use backticks on commands; general cleanup in the build system. More: removed trivial uses of eval and awk in the build system. The build_sbase macro is now a function.

Sources only cleaned before doing a build, to save on build time.

Simplified building of PCSX-Redux Open BIOS, by making use of the cpbin variable recently added to the Libreboot build system.

Simplified building of serprog images by using cpbin instead of custom copy logic.

In get.sh, more thorough hash checks are done based on build_depend and fetch_depend, which makes adding symlinks to config directories unnecessary (useful on Chromebooks where EDK2 is built while depending also on GRUB EFI - Libreboot-only, not available in Canoeboot yet).

Added EDK2 build with just iPXE, nothing else, for images with 3MB of CBFS space. Not used in this Libreboot release, but some targets in Canoeboot have this smaller size compared to Libreboot, on specific boards.

NOTE: No rev15 builds will be provided, because it did not change any in-firmware behaviour compared to rev14. This rev15 release is being tagged, so as to cleanly sync up with Canoeboot - now we have a reference point as to how the two projects align, as the Canoeboot 26.11rev1 release is in sync with Libreboot 26.10rev15.

Canoeboot 26.11 was in sync with Libreboot 26.10rev14.

Canoeboot 26.11rev1 adds the changes from Libreboot 26.10rev15, and it is thus in sync with Libreboot 26.10rev15.

Re-added 32-bit memtest86+ on 32-bit targets. Accidentally removed in the rev1 release.

Added missing SMMSTORE config on ThinkPad T420, T420s and T520.

Also enabled SMMSTORE config on HP Elite 8200 SFF

SPDX-License-Identifier: GFDL-1.3-or-later

Markdown file for this page: https://canoeboot.org/news/canoeboot2611.md

Site map

This HTML page was generated by the Libreboot Static Site Generator.