Leah Rowe
parent
72a4ffea39
commit
507ea08b12
|
|
@ -6,8 +6,6 @@ x-toc-enable: true
|
|||
The main purpose of this article is to describe how the Canoeboot project
|
||||
operates, why it exists and what it does. Who, what, why and when.
|
||||
|
||||
You may also be interested in: [Canoeboot vs GNU Boot](gnuboot.md)
|
||||
|
||||
What is Canoeboot?
|
||||
===================
|
||||
|
||||
|
|
@ -66,95 +64,6 @@ a handful of mainboards from coreboot, and sometimes
|
|||
several [mitigations](https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e)
|
||||
may be required to stabilise certain functionalities under these conditions.
|
||||
|
||||
The project called *GNU Boot* launched
|
||||
during June 2023, in opposition to Libreboot's new policy as of November 2022;
|
||||
however, GNU Boot's base Libreboot revision was from around the time of the
|
||||
Libreboot 20220710 release, so their base was roughly 1 year out of date
|
||||
compared to Libreboot. Canoeboot was created to directly compete with GNU Boot,
|
||||
which is lead by different people.
|
||||
|
||||
GNU Boot *originally* started as a hostile fork attempt; the FSF tried to steal
|
||||
the name Libreboot by setting up a Libreboot project at another TLD (instead of
|
||||
libreboot.org) and claiming to be the real thing, despite the fact that the
|
||||
real Libreboot project was actively developed, and doing releases. [This
|
||||
video](https://media.libreplanet.org/u/libreplanet/m/taking-control-over-the-means-of-production-free-software-boot/)
|
||||
at LibrePlanet 2023, on 19 March 2023, announced the FSF's *Libreboot* project,
|
||||
which was the *hostile* fork; this was anticipated, so the *real* Libreboot at
|
||||
libreboot.org made a new release that same day, having prepared for it several
|
||||
weeks beforehand. This resulted in the *[Libreboot 20230319
|
||||
release](https://libreboot.org/news/libreboot20230319.html)*, and
|
||||
started an aggressive counter-coup out-competing them. It succeeded, and the FSF
|
||||
lost; they renamed their project to GNU Boot, starting from June 2023.
|
||||
|
||||
Canoeboot was originally designated as *GNU Boot* unofficially, launching in
|
||||
the month of July 2023 as a proof of concept based
|
||||
upon [Libreboot 20230625](https://libreboot.org/news/libreboot20230625.html) to
|
||||
help the real GNU Boot get up to date
|
||||
versus Libreboot. GNU Boot's June 2023 revision was nearly 1 year behind on
|
||||
Libreboot. The unofficial GNU Boot was renamed and re-branded to nonGeNUine Boot
|
||||
on [21 July 2023](../news/nongenuineboot20230717.html#update-21-july-2023) when
|
||||
the real GNU Boot sent a legal threat to the Libreboot project (citing trademark
|
||||
infringement) - an innocent mistake, based on a misunderstanding. The purpose
|
||||
of the original *unofficial* project was merely to provide a base for the real
|
||||
GNU Boot project to just use however they wish, but they took it the wrong way.
|
||||
The logic then was: if there is *going* to be another FSDG distro, continuing
|
||||
on from the *old* Libreboot policy (based on GNU FSDG), it should at least be
|
||||
high quality, and released to a high standard, so the unofficial project was
|
||||
made to show them precisely how the Libreboot project is run, so as to provide
|
||||
them with inspiration.
|
||||
|
||||
GNU FSDG policy is [heavily
|
||||
misguided](https://libreboot.org/news/policy.html#problems-with-fsdg). Libreboot
|
||||
is vastly superior to Canoeboot, but it can at least be developed to a high
|
||||
standard (within the FSF and GNU dogma); as of 26 October 2023, GNU Boot's build
|
||||
system and revisions were still largely based on Libreboot 20220710, with very
|
||||
few meaningful changes; Canoeboot was released on that day (26 Oct 2023), based
|
||||
on Libreboot 20231021 which is *13 months newer* than Libreboot 20220710; the
|
||||
[nonGeNUine Boot 20230717 change log](news/nongenuineboot20230717.md) was in
|
||||
reference to Libreboot 20220710, and the [Canoeboot 20231026 change
|
||||
log](news/canoeboot20231026.md) is in reference to nonGeNUine Boot 20230717 -
|
||||
if you combine both change logs, you then more or less have a list of all the
|
||||
things *Canoeboot 20231026* can do that *GNU Boot* 0.1 RC didn't. It's a lot!
|
||||
|
||||
On this day, 26 October 2023, Canoeboot also supported *more boards* than GNU
|
||||
Boot, namely: Dell Latitude E6400, gru\_bob chromebooks and gru\_kevin
|
||||
chromebooks. The chromebooks are using ARM-based RK3399 SoCs with a heavily
|
||||
modified version of U-Boot, developed for Libreboot. GNU Boot still didn't
|
||||
have bootable U-Boot configurations on that day!
|
||||
|
||||
nonGeNUine Boot was renamed to Canoeboot, with the [Canoeboot 20231026
|
||||
release](../news/canoeboot20231026.md) in October 2023, based
|
||||
upon [Libreboot 20231021](https://libreboot.org/news/libreboot20231021.html).
|
||||
|
||||
Why does Canoeboot exist?
|
||||
----
|
||||
|
||||
On the day of the first Canoeboot release, GNU Boot 0.1 RC was out but not much
|
||||
different to the state it was in during July 2023, and they had not accepted the
|
||||
help of the original nonGeNUine Boot project; their 0.1 RC release was essentially
|
||||
Libreboot 20220710, but with a few build fixes on newer distros, some of which
|
||||
were created by the unofficial GNU Boot first (e.g. fix KGPE-D16 build errors).
|
||||
It was decided then that Canoeboot would be created, as an official project in
|
||||
direct competition with GNU Boot, for fun - the GNU Boot project started in June
|
||||
2023, in opposition to Libreboot's change of policy. Canoeboot started, with
|
||||
the desire to provide FSDG-compliant releases based on Libreboot, exactly in
|
||||
line with the GNU Free System Distribution Guidelines, as a proof of concept
|
||||
to show what *Libreboot* would otherwise be.
|
||||
|
||||
Libreboot is on the forefront, bringing coreboot to ordinary people, and Canoeboot
|
||||
follows the same pattern, providing high quality releases in parallel to it.
|
||||
|
||||
Canoeboot exists purely *for fun*, to see what is technically possible under GNU
|
||||
policy. It is a fun technical challenge. Every effort is made to ensure perfect
|
||||
compliance with GNU FSDG criteria.
|
||||
|
||||
Libreboot's Binary Blob Reduction Policy is more ideal, because it allows
|
||||
more people to use coreboot, thus increasing software freedom overall for more
|
||||
people, but there is no harm in Canoeboot so long as it does not stifle Libreboot
|
||||
development; so Canoeboot is only updated after each Libreboot release,
|
||||
cherry-picking what can be included under Canoeboot policy and done in an
|
||||
extremely efficient manner.
|
||||
|
||||
Release schedule
|
||||
--------------
|
||||
|
||||
|
|
|
|||
|
|
@ -52,13 +52,6 @@ executed from Canoeboot's SeaBIOS payload.
|
|||
Encrypted /boot via LUKS2 with argon2
|
||||
=======================================
|
||||
|
||||
**WARNING: The Canoeboot 0.1 release only supports LUKS1 with PBKDF2. It's
|
||||
a special release that uses much older GRUB. The November 2023 releases of
|
||||
Canoeboot contain LUKS2 support. If you're using LUKS encryption, please
|
||||
use Canoeboot from November 2023 - or use a release after 0.1. The reason why
|
||||
Canoeboot 0.1 has this issue will be clear if you read the Canoeboot 0.1
|
||||
release announcement. Canoeboot 0.1 is not intended for production use.**
|
||||
|
||||
Full encryption for basic LUKS2 (with PBKDF or argon2 key derivation) is
|
||||
supported in Canoeboot. Legacy LUKS1 is also supported. On *most* other
|
||||
systems, `/boot` must be unencrypted, but Canoeboot supports use of the
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
* [Diese Seite bearbeiten](/git.de.md)
|
||||
* [Wer entwickelt Canoeboot?](/who.md)
|
||||
* [Lizenz](/license.md)
|
||||
* [History of Canoeboot vs GNU Boot](/about.md)
|
||||
* [Vorlage](/template-license.md)
|
||||
* [Autoren](/contrib.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
* [Edit this page](/git.md)
|
||||
* [Who develops Canoeboot?](/who.md)
|
||||
* [License](/license.md)
|
||||
* [History of Canoeboot vs GNU Boot](/about.md)
|
||||
* [Template](/template-license.md)
|
||||
* [Authors](/contrib.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
* [Modifica questa pagina](/git.de.md)
|
||||
* [Chi sviluppa Canoeboot?](/who.de.md)
|
||||
* [Licenza](/license.md)
|
||||
* [History of Canoeboot vs GNU Boot](/about.md)
|
||||
* [Modelli di licenze](/template-license.md)
|
||||
* [Autori](/contrib.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
* [Редагувати цю сторінку](/git.md)
|
||||
* [Хто розробляє Canoeboot?](/who.md)
|
||||
* [Ліцензія](/license.md)
|
||||
* [History of Canoeboot vs GNU Boot](/about.md)
|
||||
* [Шаблон](/template-license.uk.md)
|
||||
* [Автори](/contrib.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@
|
|||
* [编辑本页面](/git.md)
|
||||
* [谁在开发 Canoeboot?](/who.md)
|
||||
* [许可证](/license.md)
|
||||
* [History of Canoeboot vs GNU Boot](/about.md)
|
||||
* [模板](/template-license.md)
|
||||
* [作者](/contrib.md)
|
||||
|
||||
|
|
|
|||
764
site/gnuboot.md
764
site/gnuboot.md
|
|
@ -1,764 +0,0 @@
|
|||
---
|
||||
title: Canoeboot vs GNU Boot
|
||||
x-toc-enable: true
|
||||
...
|
||||
|
||||
If you want to understand the issue Canoeboot had with GNU Boot, please
|
||||
read the [about page](about.md) and the [Libreboot Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Basically, the FSF
|
||||
decided to attempt a *hostile fork* of Libreboot, which they announced on 19
|
||||
March 2023 at their 2023 *LibrePlanet* conference. You can read about *that*
|
||||
and more of the history between GNU/FSF and Libreboot, by also reading
|
||||
the [10-year anniversary history page on
|
||||
libreboot.org](https://libreboot.org/news/10.html) - Canoeboot started in self
|
||||
defense, to provide a project that is as technically superior to GNU Boot as
|
||||
possible, while adhering to GNU Free System Distribution Guidelines as policy,
|
||||
which is the same policy that GNU Boot uses, in contrast to
|
||||
Libreboot's [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html).
|
||||
|
||||
Canoeboot is *aggressively* developed, rebasing upon each new release of
|
||||
Libreboot and, thus, maintaining absolute sync with Libreboot. It does this by
|
||||
providing all of the same boards and features, minus those boards/features or
|
||||
behaviours that are not in line with GNU policy. As a result, Canoeboot has
|
||||
weaker hardware support, but it provides a solution to those hardcore diehards
|
||||
who absolutely must have everything adhere to GNU.
|
||||
|
||||
Canoeboot is technically superior
|
||||
----------------------------------
|
||||
|
||||
tl;dr as of 26 October 2023, Canoeboot code is about 1 year ahead of GNU Boot
|
||||
in terms of development, and about 2 years ahead in terms of documentation.
|
||||
Read on, if you want details. GNU Boot is also known as *gnuboot*. The purpose
|
||||
of *Canoeboot* is to demonstrate the inferiority of GNU policy, by providing the
|
||||
highest quality releases possible, based on Libreboot, keeping sync with
|
||||
Libreboot while showing what boards/features would have to be removed from
|
||||
Libreboot, if it were to comply with GNU Boot. In other words, Canoeboot is the
|
||||
logical conclusion of what is *possible* under GNU policy.
|
||||
|
||||
Libreboot's [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html) provides an alternative, where
|
||||
users have boot firmware that is as much free software as possible, while not
|
||||
being dogmatic about it. You can learn more by reading that policy.
|
||||
|
||||
Canoeboot and GNU Boot are *both* forks of Libreboot, designed to comply with
|
||||
the GNU Free System Distribution Guidelines. This page is maintained, to show
|
||||
the differences between these two projects.
|
||||
|
||||
This current version of the page pertains to *Canoeboot 20231026*
|
||||
versus *GNU Boot 0.1 RC*. You can find GNU Boot ("gnuboot") on the GNU Savannah
|
||||
website.
|
||||
|
||||
You can also read the [Canoeboot 20231101 changelog](news/canoeboot20231101.md);
|
||||
that release only came out 7 days after the 20231026 release, so the rest of
|
||||
this page is more or less accurate, when combined with the facts on
|
||||
the 20231101 announcement.
|
||||
|
||||
GNU Boot 0.1 RC based on Libreboot 20220710
|
||||
===========================================
|
||||
|
||||
This fact is very important; nonGeNUine Boot's 20230717 changelog is relative
|
||||
to Libreboot 20220710, and Canoeboot 20231026's changelog is relative to
|
||||
nonGeNUine Boot 20230717's changelog.
|
||||
|
||||
Therefore, this page will analyse differences in both projects, at these two
|
||||
points. First, let's analyse GNU Boot, with the tag reset to `0.1-rc1`, which
|
||||
corresponds to commit ID `a64d284fd798d843133c9d7274bba17bd7837174`. Since GNU
|
||||
Boot also contains the Libreboot history that it forked from, it contains the
|
||||
Libreboot 20220710 release tag, so we can do this:
|
||||
|
||||
git log --graph --pretty=format:'%Cred%h%Creset %s %Creset' --abbrev-commit 20220710..0.1-rc1
|
||||
|
||||
Within the GNU Boot git repository, this would yield the following response:
|
||||
|
||||
```
|
||||
* a64d284 .gitignore: order alphabetically
|
||||
* 0df4fe5 GRUB: config from HDD/SSD: Add support for gnuboot_grub.cfg
|
||||
* ce13d22 GRUB: Use GNU Boot logo
|
||||
* 74b678c GRUB: Say the name GNUBoot in the grub menu
|
||||
* eeddd2b build/dependencies: debian: adding python-is-python3 to build seabios properly
|
||||
* 58b8e09 coreboot/fam15h: don't build ada toolchain for generic platforms
|
||||
* f7c0fec coreboot/fam15h: update code base, deblob, unset CONFIG_STM (see bug #64535)
|
||||
* de9297f coreboot/fam15h: fix crossgcc acpica build on newer hostcc
|
||||
* c38348d coreboot/fam15h: fix for gcc/gnat building
|
||||
* 0d77d99 coreboot/fam15h: fixing binutils not building properly
|
||||
* b773079 coreboot/default, coreboot/fam15h: use GNU mirror for acpica
|
||||
* bf17993 Continue Libreboot under the GNU project
|
||||
```
|
||||
|
||||
And that's all. The fam15h-related fixed are actually merged from
|
||||
the `fsdg20230625` branch of Libreboot, made during July 2023. See:
|
||||
<https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625>
|
||||
|
||||
The other patches are also merged (cherry-picked) from Libreboot! The above
|
||||
commit log is all that GNU Boot did, for their 0.1 RC1 release.
|
||||
|
||||
Therefore, to know the differences between Canoeboot and GNU Boot, I will copy
|
||||
all items first from the nonGeNUine Boot 20230717 change log, and then the
|
||||
Canoeboot 20231026 change log, but I will skip those entries that define
|
||||
features which GNU Boot already has.
|
||||
|
||||
On this day, GNU Boot's current commit ID (in the `main` branch)
|
||||
is `54c6ae497d49c233b654c171978baa77b90ffe17` from 12 October 2023. Most of
|
||||
the changes since 0.1 RC1 up to that commit are just documentation changes,
|
||||
and even still, only cherry-picking minor patches here and there that were
|
||||
already done in Libreboot, in some cases years ago. It's worth noting that
|
||||
the GNU Boot documentation is based on Libreboot documentation from *late 2021*
|
||||
or at most, very early 2022.
|
||||
|
||||
I don't need to compare documentation, and it would take too long. Their
|
||||
documentation is *2 years out of date*, what more is there to say?
|
||||
|
||||
Now, feature comparisons in the build systems:
|
||||
|
||||
Canoeboot 20231026 features that GNU Boot lacks
|
||||
===============================================
|
||||
|
||||
Board support
|
||||
-------------
|
||||
|
||||
Canoeboot has *these* boards fully supported, that GNU Boot currently lacks
|
||||
support for:
|
||||
|
||||
* [Dell Latitude E6400](docs/hardware/e6400.md)
|
||||
* [ASUS Chromebook Flip C101 (gru-bob)](docs/install/chromebooks.md)
|
||||
* [Samsung Chromebook Plus (v1) (gru-kevin)](docs/install/chromebooks.md)
|
||||
|
||||
Git revisions in Canoeboot 20231026:
|
||||
------------------------------------
|
||||
|
||||
* Coreboot (default): commit ID `d862695f5f432b5c78dada5f16c293a4c3f9fce6`, 12 October 2023
|
||||
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
|
||||
* GRUB: commit ID `e58b870ff926415e23fc386af41ff81b2f588763`, 3 October 2023
|
||||
* SeaBIOS: commit ID `1e1da7a963007d03a4e0e9a9e0ff17990bb1608d`, 24 August 2023
|
||||
* U-Boot: commit ID `4459ed60cb1e0562bc5b40405e2b4b9bbf766d57`, 2 October 2023
|
||||
|
||||
Git revisions in GNU Boot 0.1 RC1:
|
||||
---------------------------------
|
||||
|
||||
* Coreboot (default): commit ID `b2e8bd83647f664260120fdfc7d07cba694dd89e`, 17 November 2021
|
||||
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
|
||||
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 25 October 2021
|
||||
* SeaBIOS: commit ID `1281e340ad1d90c0cc8e8d902bb34f1871eb48cf`, 24 September 2021
|
||||
* U-Boot: **does not exist** (no ARM/U-Boot support in Libreboot 20220710)
|
||||
NOTE: GNU Boot *does* support downloading, deblobbing and re-compressing
|
||||
U-Boot archives, and in fact does a better job of *that* than Canoeboot in
|
||||
some ways, but it does not yet actually build U-Boot, and it does not boot
|
||||
U-Boot in any way, on any actual mainboards.
|
||||
|
||||
As you can see, Canoeboot's revisions are a lot newer.
|
||||
|
||||
GRUB LUKS2 support with argon2
|
||||
------------------------------
|
||||
|
||||
Canoeboot 20231026 contains a heavily patched version of GRUB, which contains
|
||||
argon2 support. This allows full decryption of LUKS2 volumes, without having
|
||||
to switch to different key derivation (PBKDF2) and without needing to use
|
||||
LUKS1. You can simply use the default LUKS2 setup provided by any distro, and
|
||||
it will work. More information is available about GRUB cryptomount, in
|
||||
the [GNU+Linux guide](docs/gnulinux/) - search on that page for LUKS2 or argon2.
|
||||
|
||||
GNU Boot completely *lacks* this feature, as of 26 October 2023. It can only
|
||||
support LUKS2 if the key derivation is downgraded to PBKDF2 (insecure, or to
|
||||
LUKS1 (also insecure).
|
||||
|
||||
For all intentions, the average user cannot have a fully encrypted system on
|
||||
GNU Boot. They must leave `/boot` unencrypted on GNU+Linux distros.
|
||||
|
||||
With Canoeboot, you can have encrypted `/boot` very easily. This is a boon for
|
||||
security, because it reduces the chance of someone tampering with your data
|
||||
successfully, and combined with [other steps](docs/gnulinux/grub_hardening.md),
|
||||
can be used to reduce the risk of evil maid attacks (by making it infeasible).
|
||||
|
||||
GRUB detached LUKS headers
|
||||
--------------------------
|
||||
|
||||
GRUB 2.12 also supports detached LUKS headers, whereas GRUB 2.06 does not.
|
||||
GNU Boot *currently* uses GRUB 2.06 as its payload. Canoeboot and Libreboot
|
||||
both use GRUB 2.12 as a payload.
|
||||
|
||||
Serprog support
|
||||
---------------
|
||||
|
||||
Canoeboot can build firmware images for RP2040 and STM32 microcontrollers,
|
||||
using `pico-serprog` and `stm32-vserprog` respectively. This can be used to
|
||||
set up an SPI flasher of high quality, but these parts are low-cost.
|
||||
|
||||
GNU Boot does not support this feature, as of 26 October 2023.
|
||||
|
||||
Simplified command structure
|
||||
----------------------------
|
||||
|
||||
There are *9* shell scripts in Canoeboot 20231026, versus about 50 in GNU
|
||||
Boot 0.1 RC1, because GNU Boot uses the pre-audit design; Libreboot used to
|
||||
have lots of very simple scripts, but ended up with a lot of code repetition.
|
||||
|
||||
The new lbmk design generalises all of the logic, doing away with the very
|
||||
hacky logic that existed in the old build system design.
|
||||
|
||||
The interface in Canoeboot's build system is much easier to use. For example,
|
||||
the commands are shorter, and easier to remember. See:
|
||||
[cbmk maintenance manual](docs/maintain/) tells you everything about the
|
||||
Canoeboot build system.
|
||||
|
||||
GNU Boot doesn't even *have* a maintenance manual, in their version. Their
|
||||
documentation exists in the same repository as code, but their
|
||||
version of `docs/maintain/` does not actually contain any instructions,
|
||||
at least as of commit ID a64d284fd798d843133c9d7274bba17bd7837174 on 17
|
||||
August 2023.
|
||||
|
||||
Better documentation
|
||||
--------------------
|
||||
|
||||
Canoeboot has much better documentation, but this is obvious if you've been
|
||||
paying attention. As already stated: GNU Boot's documentation is horribly
|
||||
out of date, even relative to the version of Libreboot that they're using!
|
||||
(which itself is also horribly out of date)
|
||||
|
||||
Canoeboot's build system is smaller
|
||||
-----------------------------------
|
||||
|
||||
Smaller doesn't mean worse; in fact, Canoeboot's build system is more
|
||||
efficient. It's about 1250 sloc (source lines of code), when counting shell
|
||||
scripts in the core of the build system. Libreboot, Canoeboot and GNU Boot
|
||||
build systems all use the same design, written in shell scripts.
|
||||
|
||||
1250 sloc in Canoeboot, versus 2111 in gnuboot; gnuboot however lacks many
|
||||
of the features and improvements that you're about to see below. The
|
||||
Canoeboot build system does several times as many things, in half
|
||||
the amount of code! The code is generally just more reliable, less error
|
||||
prone, and easier to work with, in Canoeboot. GNU Boot uses a very old version
|
||||
of the Libreboot build system design, from long before I started any massive
|
||||
audits. There have been *three* Libreboot build system audits in 2023, as
|
||||
of 26 October 2023.
|
||||
|
||||
Three audits, and Canoeboot has inherited the improvements of all of them.
|
||||
GNU Boot's design is based on the pre-audit lbmk codebase.
|
||||
|
||||
Build system / performance improvements in Canoeboot:
|
||||
|
||||
* Much stricter, more robust error handling; too many changes to list here, so
|
||||
check the git log. Also, errors that *are not errors* are no longer treated as
|
||||
such; nonGeNUine Boot 20230717's build system was actually too strict, sometimes.
|
||||
* Most logic has been unified in single scripts that perform once type of task
|
||||
each, instead of multiple scripts performing the same type of talk; for
|
||||
example, defconfig-based projects now handled with the same scripts, and
|
||||
preparing trees for them is done the same. These unifications have been done
|
||||
carefully and incrementally, with great thought so as to prevent *spaghetti*.
|
||||
The code is clean, and small.
|
||||
* GitHub is no longer used on main Git repository links, instead only as backup
|
||||
* Backup repositories now defined, for all main repos under `config/git/`
|
||||
* Single-tree projects are no longer needlessly re-downloaded when they already
|
||||
have been downloaded.
|
||||
* GRUB LUKS2 support now available, with argon2 key derivation; previously, only
|
||||
PBKDF2 worked so most LUKS2 setups were unbootable in Canoeboot. This is fixed.
|
||||
* Vastly reduced number of modules in GRUB, keeping only what is required.
|
||||
* Use `--mtime` and option options in GNU Tar (if it is actually GNU Tar), when
|
||||
creating Tar archives. This results in partially reproducible source archives,
|
||||
and consistent hashes were seen in testing, but not between distros.
|
||||
* Always re-inialitise `.git` within lbmk, for the build system itself, if
|
||||
Git history was removed as in releases. This work around some build systems
|
||||
like coreboot that use Git extensively, and are error-prone without it.
|
||||
* More robust makefile handling in source trees; if one doesn't exist, error
|
||||
out but also check other makefile name combinations, and only error out if
|
||||
the command was to actually build.
|
||||
* ROMs build script: support the "all" argument, even when getopt options are
|
||||
used e.g. `-k`
|
||||
* Disabled the pager in `grub.cfg`, because it causes trouble in some
|
||||
non-interactive setups where the user sees an errant message on the screen
|
||||
and has to press enter. This fixes boot interruptions in some cases, allowing
|
||||
normal use of the machine. The pager was initially enabled many years ago,
|
||||
to make use of cat a bit easier in the GRUB shell, but the user can just
|
||||
enable the pager themselves if they really want to.
|
||||
* U-Boot can now be compiled standalone, without using the ROMs build script,
|
||||
because crossgcc handling is provided for U-Boot now in addition to coreboot.
|
||||
* All helper scripts are now under `include/`, and main scripts in `script/`,
|
||||
called by the main `build` script
|
||||
* Generally purge unused variables in shell scripts
|
||||
* Simplified initialisation of variables in shell scripts, using the `setvars`
|
||||
function defined under `include/err.sh`
|
||||
* Support patch subdirectories, when applying patches. This is done recursively,
|
||||
making it possible to split up patch files into smaller sets inside sub
|
||||
directories, per each source tree (or target of each source tree, where a
|
||||
project is multi-tree within lbmk)
|
||||
* SPDX license headers now used, almost universally, in all parts of cbmk.
|
||||
* Files such as those under `config/git` are now
|
||||
concatenated, traversing recursively through the target directory; files first,
|
||||
then directories in order, and for each directory, follow the same pattern
|
||||
until all files are concatenated. This same logic is also used for patches.
|
||||
This now enables use of subdirectories, in some config/patch directories.
|
||||
* General code cleanup on `util/nvmutil`
|
||||
* Git histories are more thoroughly deleted, in third party source trees during
|
||||
release time.
|
||||
* Symlinks in release archives are no longer hard copies; the symlinks are
|
||||
re-created by the release script, because it clones the current lbmk work
|
||||
directory via Git (local git clone), rather than just using `cp` to copy links.
|
||||
* Properly output to stderr, on printf commands in scripts where it is either
|
||||
a warning prior to calling `err`, or just something that belongs on the error
|
||||
output (instead of standard output).
|
||||
* Don't use the `-B` option in make commands.
|
||||
* SECURITY: Use sha512sum (not sha1sum) when verifying certain downloads. This
|
||||
reduces the chance for collisions, during checksum verification.
|
||||
* Set GRUB timout to 5s by default, but allow override and set to 10s or 15s
|
||||
on some mainboards.
|
||||
* Support both curl and wget, where files are downloaded outside of Git; defer
|
||||
to Wget when Curl fails, and try each program three times before failing. This
|
||||
results in more resilient downloading, on wobbly internet connections.
|
||||
* Don't clone Git repositories into `/tmp`, because it might be a tmpfs with
|
||||
little memory available; clone into `tmp/gitclone` instead, within lbmk,
|
||||
and `mv` it to avoid unnecessary additional writes (`mv` is much more efficient
|
||||
than `cp`, for this purpose).
|
||||
* Removed unused `target.cfg` handling in vendor scripts, because they use
|
||||
the concatenated config format instead (they always have).
|
||||
* Coreboot builds: automatically run make-oldconfig, to mitigate use of raw
|
||||
coreboot config where a revision was updated but the config was untouched.
|
||||
This may still result in a confirmation dialog, and it's still recommended
|
||||
that the configs be updated per revision (or switch them to defconfigs).
|
||||
* Vastly simplified directory structure; `resources/scripts/` is now `script/`,
|
||||
and `resources/` was renamed to `config/`; ifd and gbe files were also moved
|
||||
to `config/ifd/`. Commands are now 1-argument instead of 2, for example
|
||||
the `./build boot roms` command is now `./build roms`.
|
||||
* memtest86plus: only build it on 64-bit hosts, for now (32-bit building is
|
||||
broken on a lot of distros nowadays, and lbmk doesn't properly handle cross
|
||||
compilation except on coreboot or U-Boot)
|
||||
* (courtesy of Riku Viitanen) don't use cat on loops that handle lines of text.
|
||||
Instead, use the `read` command that is built into `sh`, reading each line.
|
||||
This is more efficient, and provides more robust handling on lines with
|
||||
spaces in them.
|
||||
* *ALL* projects now have submodules downloaded at build time, not just multi
|
||||
tree projects such as coreboot - and a few projects under `config/git` have
|
||||
had certain `depend` items removed, if a given project already defines it
|
||||
under `.gitmodules` (within its repository).
|
||||
* Improved cbutils handling; it's now even less likely to needlessly re-build
|
||||
if it was already built.
|
||||
* The release build script no longer archives what was already built, but
|
||||
instead builds from scratch, creating an archive from source downloads
|
||||
first before building the ROM archives. This saves time because it enables
|
||||
a single build test per release, whereas at was previously necessary to test
|
||||
the Git repository and then the release archive. Testing both is still desired,
|
||||
but this behaviour also means that whatever is built at release time is
|
||||
guaranteed to be the same as what the user would build (from archives).
|
||||
* Improved handling of `target.cfg` files in multi-tree projects coreboot,
|
||||
SeaBIOS and U-Boot. Unified to all such projects, under one script, and
|
||||
with improved error handling.
|
||||
* GRUB payload: all ROM images now contain the same ELF, with all keymaps
|
||||
inserted. This speeds up the build process, and enables easier configuration
|
||||
when changing the keyboard layout because less re-flashing is needed.
|
||||
* Simplified IFD handling on ICH9M platforms (e.g. X200/T400 thinkpads); the
|
||||
ich9gen utility wasn't needed anymore so ich9utils has been removed, and now
|
||||
the IFD/GbE files are included pre-assembled (generated by ich9gen). Ich9gen
|
||||
can still be used, or you can re-generate with coreboot's bincfg; the ifdtool
|
||||
util can be used to edit IFD and nvmutil (part of Canoeboot) can change MAC
|
||||
addresses. The ich9utils code was always redundant for the last few years,
|
||||
especially since 2022 when nvmutil was first written.
|
||||
* Running as root is now forbidden, for most commands; lbmk will exit with
|
||||
non-zero status if you try. The `./build dependencies x` commands still work
|
||||
as root (they're the only commands available as root).
|
||||
* Enabled memtest86plus on more boards, where it wasn't previously enabled.
|
||||
* Only enable SeaBIOS as first payload on desktops, but still enable GRUB as
|
||||
second payload where GRUB is known to work (on each given host). The text
|
||||
mode and coreboot framebuffer modes are provided in each case, where feasible.
|
||||
* The `list` command has been mostly unified, making it easier to tell (from
|
||||
lbmk) what commands are available, without having to manually poke around
|
||||
under `script/`.
|
||||
* The `-T0` flag is now used, universally, on xz commands. This makes `xz` run
|
||||
on multiple threads, greatly speeding up the creation of large tar archives.
|
||||
* Universally use `-j` in make commands, for multi-threading, but it relies
|
||||
on `nproc` to get thread count, so this only works if you have `nproc` (you
|
||||
probably don't, if you run BSD; BSD porting is still on TODO for Canoeboot)
|
||||
* File names as arguments now universally have quotes wrapped around them, and
|
||||
similar auditing has been done to all variables used as arguments everywhere
|
||||
in lbmk. There were cases where multiple arguments were wrongly quoted then
|
||||
treated as a single argument, and vice versa. This is now fixed.
|
||||
* Re-wrote `.gitcheck`; now, a global git name/email config is always required.
|
||||
The only behaviour (setting local config, and unsetting) was quite error-prone
|
||||
under fault conditions, where cleanup may not have been provided, or when
|
||||
execution was interrupted, resulting sometimes in accidentally committing
|
||||
to `lbmk.git` as author named `lbmkplaceholder`.
|
||||
* The new BSD-like coding style is now used on *all* shell scripts in lbmk. A
|
||||
few scripts still used the old lbmk coding style, as of audit 2.
|
||||
* Scripts no longer directly exit with non-zero status, under fault conditions;
|
||||
instead, `x_` or `err` is used to provide such behaviour. This results in all
|
||||
exits from lbmk being consolidated to `err`, under fault conditions. - zero
|
||||
exits are also consolidated, going only through the main script, which has its
|
||||
own exit function called `lbmk_exit` that provides `TMPDIR` cleanup.
|
||||
* BSD-style error handling implemented, with an `err` function (and functions
|
||||
that use it) inside `include/err.sh`; there is also `x_` which can be used
|
||||
to run a command and exit automatically with non-zero status, useful because
|
||||
it provides more verbose output than if you just relied on `set -e`, and it
|
||||
still works when a script *does not* use `set -e` - however, it is not used
|
||||
on all functions, because it works by executing `$@` directly, which can break
|
||||
depending on arguments. Therefore, some scripts just default to `|| err` for
|
||||
providing breakage in scripts.
|
||||
* Memtest *6.2* now used (instead of *5.x* releases). This is essentially a
|
||||
re-write, and it works on the coreboot framebuffer, whereas previous revisions
|
||||
only worked on text mode setups.
|
||||
* NO MAKEFILE. The Makefile in lbmk has been removed. It was never meaningfully
|
||||
used because all it did was run lbmk commands, without implementing any logic
|
||||
itself. A Makefile may be added again in the future, but with a view to
|
||||
installing *just the build system* onto the host system, to then build ROM
|
||||
images under any number of directories. Lbmk's design is strictly no-Makefile,
|
||||
but it uses Makefiles provided by third party source trees when building them.
|
||||
* Safer GRUB configuration file handling between GRUB memdisk and coreboot CBFS;
|
||||
it is no longer possible to boot without a GRUB config, because the one in
|
||||
GRUB memdisk is provided as a failsafe, overridden by *inserting* one in CBFS,
|
||||
but there is no config in CBFS by default anymore.
|
||||
* The build system *warns* users about `elf/` vs `bin/`, when it comes to
|
||||
flashing coreboot ROM images; it tells them to use `bin/` because those
|
||||
images do contain payloads, whereas the ones under `elf/` do not.
|
||||
* VASTLY more efficient build process; all coreboot ROMs without payload are
|
||||
now cached under `elf/`, as are payloads, then they are joined separately by
|
||||
the usual ROMs build script, and these cached ROMs contain many changes in
|
||||
them that were previously handled by `moverom` in the main ROM build script.
|
||||
Under the new design, repetitive steps are avoided; payloads are inserted into
|
||||
a copy of the cached ROMs under `TMPDIR`, *before* being copied for keymaps
|
||||
and small files; this eliminates delays caused by slow compression (LZMA is
|
||||
always used, when inserting payloads). After crossgcc and the payloads are
|
||||
compiled, the ROM with coreboot builds in under a minute, whereas it would
|
||||
have previously taken several minutes on most Canoeboot-supported hardware.
|
||||
* VASTLY reduced GRUB payload size; modules that aren't needed have been removed
|
||||
resulting in much smaller GRUB payloads, that also boot faster.
|
||||
* ALL defconfig creation, updating and modification are handled by the same
|
||||
script that *also* handles compiling, as mentioned in the bullet-point below.
|
||||
* ALL main source trees are now compiled, downloaded, configured and cleaned
|
||||
using the same script. The *download* (Git) logic is a separate file
|
||||
under `include/` and its functions are called by the main build script, which
|
||||
provides a stub for this.
|
||||
* Scripts are no longer executed directly, ever, except the main script. All
|
||||
scripts are otherwise executed from `script/`, inheriting the `TMPDIR`
|
||||
variable set (and exported) by lbmk.
|
||||
* Generally improved user feedback in scripts, especially the vendor scripts.
|
||||
* Coreboot, U-Boot and SeaBIOS are now downloaded, configured and compiled using
|
||||
the exact same script. Although these codebases differ wildly, their build
|
||||
systems use the same design, and they are compatible from a user-interface
|
||||
perspective.
|
||||
* Vastly improved `/tmp` handling; a universal `TMPDIR` is set (environmental
|
||||
variable) and exported to all child processes running lbmk scripts. On exit,
|
||||
the main tmp directory is purged, cleaning all tmp directories under it.
|
||||
* General simplification of coding style on all shell scripts.
|
||||
* Fixed some variable initialisations in the coreboot ROM image build script
|
||||
* Don't enable u-boot on QEMU x86 images (due to buggy builds, untested)
|
||||
* Fixed coreboot-version file inserted into coreboot trees, when compiled
|
||||
on Canoeboot release archives.
|
||||
* Very general auditing has been done, finding and fixing bugs.
|
||||
* Reduced the number of scripts significantly. There were about 50 scripts in
|
||||
the nonGeNUine Boot 20230717 build system. There are closer to *20* in today's
|
||||
Canoeboot 20231026 revision.
|
||||
* Many scripts that were separate are now unified. For example: the scripts
|
||||
handling defconfigs files on SeaBIOS, u-Boot and coreboot have now been
|
||||
merged into a single script, performing the same work *better* in less code.
|
||||
* Ditto many other scripts; repeated logic unified, logic generalised. The
|
||||
logic for *downloading* coreboot and u-boot was unified into one script,
|
||||
basing off of the coreboot one, and then expanding to also cover SeaBIOS.
|
||||
Most building (e.g. handling of Makefiles) is now done in a single script.
|
||||
* Far superior error handling; in many scripts, the `-e` option in `sh` was
|
||||
heavily relied upon to catch errors, but now errors are handled much more
|
||||
verbosely. *Many* fault conditions previously did not make lbmk *exit* at all,
|
||||
let alone with non-zero status, and zero status was sometimes being returned
|
||||
under some edge cases that were tested. Error handling is more robust now.
|
||||
* `util/ich9utils` (containing `ich9gen`) was *removed*, thus eliminating about
|
||||
3000 source lines (of C code) from lbmk. The `nvmutil` program, also provided
|
||||
by and originating from the Canoeboot project, can already change GbE MAC
|
||||
addresses. Coreboot's bincfg can generate ich9m descriptors, and ifdtool can
|
||||
manipulate them; so the features provided by ich9utils were superfluous, since
|
||||
they are available in other projects that we ship. We now ship pre-built
|
||||
ifd/gbe configs on these machines, which can be modified or re-assembled
|
||||
manually if you want to. This eliminates a moving part from Canoeboot, and
|
||||
speeds up the build a little bit.
|
||||
* ROM images (of coreboot) build *much faster*: no-payload coreboot ROMs are
|
||||
cached on disk, as are payloads, where previously only the latter was cached.
|
||||
These cached images have as much inserted into them as possible, to eliminate
|
||||
redundant steps in the build process. The `elf` directory contains these, and
|
||||
the existing `bin` directory still holds the full ROM images (containing
|
||||
payloads) when compiled.
|
||||
* GRUB payload: vastly reduced the size of the payload, by eliminating GRUB
|
||||
modules that were not needed. About 100KB of compressed space saved in flash!
|
||||
* GRUB payload: [argon2 key derivation supported](argon2.md) - this means LUKS2
|
||||
decryption is now possible in GRUB. This work was performed by Nicholas
|
||||
Johnson, rebasing from Axel's AUR patch for GRUB 2.06 (Canoeboot currently
|
||||
uses GRUB 2.12).
|
||||
* The *new* coding style is now used on many more scripts, including
|
||||
the `build/boot/roms_helper` script - the new style is much cleaner,
|
||||
mandating that logic be top-down, with a `main()` function defined; it's
|
||||
basically inspired by the OpenBSD coding style for C programs, adapted to
|
||||
shell scripts.
|
||||
* All GRUB keymaps now included; a single `grub.elf` is now used on all ROM
|
||||
images. The `grub.cfg` goes in GRUB memdisk now, but can be overridden by
|
||||
inserting a `grub.cfg` in CBFS; many behaviours are also controlled this way,
|
||||
for example to change keymaps and other behaviours. This results in *much*
|
||||
faster builds, because a different GRUB payload doesn't have to be added to
|
||||
each new ROM image; such takes time, due to time-expensive LZMA compression.
|
||||
This, plus the optimised set of GRUB modules, also makes GRUB itself load
|
||||
much faster. All of the fat has been trimmed, though still quite a lot more
|
||||
than a Crumb.
|
||||
* A lot of scripts have been removed entirely, and their logic not replaced;
|
||||
in many cases, Canoeboot's build system contained logic that had gone unused
|
||||
for many years.
|
||||
* More reliable configs now used on desktop mainboards: SeaBIOS-only for start,
|
||||
but GRUB still available where feasible (in the SeaBIOS menu). This makes it
|
||||
more fool proof for a user who might use integrated graphics and then switch
|
||||
to a graphics card; the very same images will work.
|
||||
* TMPDIR environmental variable now set, and exported from main parent process
|
||||
when running lbmk; child processes inherit it, and a single tmp dir is used.
|
||||
This is then automatically cleaned, upon exit from lbmk; previously, lbmk did
|
||||
not cleanly handle `/tmp` at all, but now it's pretty reliable.
|
||||
* A [HUGE build system audit](https://libreboot.org/news/audit.html) inherited
|
||||
from Libreboot, is part of the Canoeboot tree; the entire build system was
|
||||
re-written in a much cleaner coding style, with much stricter error handling
|
||||
and clear separation of logic. A *lot* of bugs were fixed. A *LOT* of bugs.
|
||||
Build system auditing has been the *main* focus, in these past 12 months.
|
||||
* `cros`: Disable coreboot-related BL31 features. This fixes poweroff on gru
|
||||
chromebooks. Patch courtesy of Alper Nebi Yasak.
|
||||
* `u-boot`: Increase EFI variable buffer size. This fixes an error where
|
||||
Debian's signed shim allocates too many EFI variables to fit in the space
|
||||
provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
|
||||
* Coreboot build system: don't warn about no-payload configuration. nonGeNUine Boot
|
||||
compiles ROM images *without* using coreboot's payload support, instead it
|
||||
builds most payloads by itself and inserts them (via cbfstool) afterwards.
|
||||
This is more flexible, allowing greater configuration; even U-Boot is
|
||||
handled this way, though U-Boot at least still uses coreboot's crossgcc
|
||||
toolchain collection to compile it. Patch courtesy Nicholas Chin.
|
||||
* `util/spkmodem-recv`: New utility, forked from GNU's implementation, then
|
||||
re-written to use OpenBSD style(9) programming style instead of the
|
||||
originally used GNU programming style, and it is uses
|
||||
OpenBSD `pledge()` when compiled on OpenBSD. Generally much cleaner coding
|
||||
style, with better error handling than the original GNU version (it is forked
|
||||
from coreboot, who forked it from GNU GRUB, with few changes made). This
|
||||
is a receiving client for spkmodem, which is a method coreboot provides to
|
||||
get a serial console via pulses on the PC speaker.
|
||||
* download/coreboot: Run `extra.sh` directly from given coreboot tree. Unused
|
||||
by any boards, but could allow expanding upon patching capabilities in lbmk
|
||||
for specific mainboards, e.g. apply coreboot gerrit patches in a specific
|
||||
order that is not easy to otherwise guarantee in more generalised logic of
|
||||
the nonGeNUine Boot build system.
|
||||
* `util/e6400-flash-unlock`: New utility, that disables flashing protections
|
||||
on Dell's own BIOS firmware, for Dell Latitude E6400. This enables nonGeNUine Boot
|
||||
installation *without* disassembling the machine (external flashing equipment
|
||||
is *not required*). Courtesy Nicholas Chin.
|
||||
* Build dependencies scripts updated for more modern distros. As of this day's
|
||||
release, nonGeNUine Boot compiles perfectly in bleeding edge distros e.g. Arch
|
||||
Linux, whereas the previous 20220710 required using old distros e.g.
|
||||
Debian 10.
|
||||
* `cbutils`: New concept, which implements: build coreboot utilities like
|
||||
cbfstool and include the binaries in a directory inside lbmk, to be re-used.
|
||||
Previously, they would be compiled in-place within the coreboot build system,
|
||||
often re-compiled needlessly, and the checks for whether a given util are
|
||||
needed were very ad-hoc: now these checks are much more robust.
|
||||
Very centralised approach, per coreboot tree, rather than selectively
|
||||
compiling specific coreboot utilities, and makes the build system logic in
|
||||
nonGeNUine Boot much cleaner.
|
||||
* GRUB config: 30s timeout by default, which is friendlier on some desktops
|
||||
that have delayed keyboard input in GRUB.
|
||||
* ICH9M/GM45 laptops: 256MB VRAM by default, instead of 352MB. This fixes
|
||||
certain performance issues, for some people, as 352MB can be very unstable.
|
||||
* U-Boot patches: for `gru_bob` and `gru_kevin` chromebooks, U-Boot is used
|
||||
instead of Google's own *depthcharge* bootloader. It has been heavily
|
||||
modified to avoid certain initialisation that is replaced by coreboot, in
|
||||
such a way that U-Boot is mainly used as a bootloader providing UEFI for
|
||||
compliant GNU+Linux distros and BSDs. Courtesy Alper Nebi Yasak.
|
||||
* lbmk: The entire nonGeNUine Boot build system has, for the most part, been made
|
||||
portable; a lot of scripts now work perfectly, on POSIX-only implementations
|
||||
of `sh` (though, many dependencies still use GNU extensions, such as GNU
|
||||
Make, so this portability is not directly useful yet, but a stepping stone.
|
||||
nonGeNUine Boot eventually wants to be buildable on non-GNU, non-GNU/Linux systems,
|
||||
e.g. BSD systems)
|
||||
* nvmutil: Lots of improvements to code quality, features, error handling. This
|
||||
utility was originally its own project, started by Leah Rowe, and later
|
||||
imported into the nonGeNUine Boot build system.
|
||||
* build/boot/roms: Support cross-compiling coreboot toolchains for ARM platforms,
|
||||
in addition to regular x86 that was already supported. This is used for
|
||||
compiling U-boot as a payload, on mainboards.
|
||||
* U-boot integration: at first, it was just downloading U-Boot. Board integration
|
||||
for ARM platforms (from coreboot) came later, e.g. ASUS Chromebook Flip C101
|
||||
as mentioned above. The logic for this is forked largely from the handling
|
||||
of coreboot, because the interface for dealing with their build systems is
|
||||
largely similar, and they are largely similar projects. Courtesy Denis Carikli
|
||||
and Alper Nebi Yasak.
|
||||
* New utility: `nvmutil` - can randomise the MAC address on Intel GbE NICs, for
|
||||
systems that use an Intel Flash Descriptor
|
||||
* General build system fixes: better (and stricter) error handling
|
||||
* Fixed race condition when building SeaBIOS in some setups.
|
||||
* GRUB configs: only scan ATA, AHCI or both, depending on config per board.
|
||||
This mitigates performance issues in GRUB on certain mainboards, when
|
||||
scanning for `grub.cfg` files on the HDD/SSD.
|
||||
* GRUB configs: speed optimisations by avoiding slow device enumeration in
|
||||
GRUB.
|
||||
|
||||
Summary
|
||||
=======
|
||||
|
||||
So, in conclusion: this page is not trying to tell you why you should use
|
||||
Canoeboot; rather, it's just telling you that someone worse exists. Canoeboot
|
||||
and GNU Boot are *both* inherently flawed in their designs; *both* projects are
|
||||
completely *inferior* to the Libreboot project, for all the reasons laid out in
|
||||
the [Binary Blob Reduction Policy](https://libreboot.org/news/policy.html) - the
|
||||
Canoeboot project is provided, specifically, to prove the merits of that policy,
|
||||
by showing what Libreboot would have been by now if it continued adhering to
|
||||
GNU policy, instead of changing to its current Blob Reduction Policy.
|
||||
|
||||
Libreboot provides all of the same blob-free configurations as Canoeboot, when
|
||||
possible on any given mainboard, and that is the preference, but the FSF/GNU
|
||||
dogma states that the user must never run any proprietary software. This dogma
|
||||
is wrong; a more correct approach is to say that proprietary software is bad,
|
||||
because it restricts the user's freedom to study and modify the software; it
|
||||
removes their power to say no when the developer wants to change the program in
|
||||
a bad way, it leaves them at the mercy of that developer - the point is this:
|
||||
|
||||
Free software is good, and we should be promoting as much of it as possible.
|
||||
This means that a hardline no-blob approach like the policy implemented by
|
||||
Canoeboot (or GNU Boot for that matter), is entirely misguided, because it
|
||||
will only alienate those who just want *some* free software. Most people like
|
||||
the idea of software freedom but cannot go all the way yet; we should encourage
|
||||
people to make the right choices, but otherwise just help them in whatever way
|
||||
we can, meeting people where they're at right now.
|
||||
|
||||
And that is why Libreboot exists in the way that it does. Canoeboot serves as an
|
||||
example of what would happen in the best-case scenario if Libreboot never changed
|
||||
its policy. The best possible release of Canoeboot will still be missing a ton
|
||||
of boards and features from Libreboot. Indeed, the Canoeboot 20231026 and
|
||||
nonGeNUine Boot 20230717 both illustrate that quite nicely.
|
||||
|
||||
GNU Boot 0.1 RC3 and Canoeboot 20240102
|
||||
---------------------------------------
|
||||
|
||||
Dubbed *Canoeboot 20240102*, though it's not actually a release. For context,
|
||||
first read: <https://libreboot.org/news/audit4.html>
|
||||
|
||||
Canoeboot imported these changes, in
|
||||
revision `102ce12cea023783729d6a2cd1576afc95bf7540` on 2 January 2024. This
|
||||
revision is referred to unofficially as *Canoeboot 20240102*.
|
||||
|
||||
These changes add the following noteworthy improvements, that benefit Canoeboot
|
||||
users:
|
||||
|
||||
* GRUB 2.12 stable release, instead of GRUB 2.12-rc1. The stable release came
|
||||
out on 20 December 2023.
|
||||
* Generic cmake and autoconf handling now, in the build scripts. This means that
|
||||
many more projects can be added more easily to the build system (utilities
|
||||
and such)
|
||||
* Higher default drive level of 12mA, instead of 4mA, when building serprog
|
||||
images for RP2040-based MCUs
|
||||
* Generic fixes in the build system, better error checking; failed Git patching
|
||||
now actually exits, whereas in previous releases (and also in GNU Boot's
|
||||
build system, because it inherits Libreboot which had this bug for years),
|
||||
in many older releases, `git am` failing does not cause the build system to
|
||||
exit. The build continues, erroneously. Libreboot fixed this in audit 4, and
|
||||
Canoeboot has imported this.
|
||||
* Crossgcc tarballs no longer bundled in releases, making them smaller. The
|
||||
build system still downloads these at build time, but this means that now
|
||||
you will only download what you need, when you build Canoeboot for a board.
|
||||
* Single-tree projects are now configurable with `target.cfg` files. This could
|
||||
enable use of crossgcc, if you set `xarch`, and make/cmake/autoconf arguments
|
||||
are now all configurable in `target.cfg` - previously, this file was only
|
||||
possible for multi-tree projects.
|
||||
* `grub.cfg`: the default config scanning now also searches for syslinux configs,
|
||||
in addition to extlinux, though it still looks for GRUB configs first. GRUB
|
||||
can parse syslinux/extlinux configuration files. Canoeboot's GRUB is also now
|
||||
configured to search for configs on the *ESP* (EFI System Partition), both
|
||||
on USB media and on the installed system. With these changes, Canoeboot now
|
||||
boots distros much more reliably, especially UEFI-based ones, even though
|
||||
UEFI is not implemented in Caneoboot on x86 yet.
|
||||
|
||||
These and other/subsequent changes will be merged with the lists above, when
|
||||
the next Canoeboot release comes out. The main lists of changes above are
|
||||
for the current binary release of Canoeboot, versus GNU Boot.
|
||||
|
||||
GNU Boot 0.1 RC3
|
||||
----------------
|
||||
|
||||
The article above compares Canoeboot 20231107 and GNU Boot 0.1 RC1. It should
|
||||
be noted that 0.1 RC3 is now available, but it doesn't really add any major
|
||||
changes, and most of the changes are documentation changes. Here is a brief list
|
||||
of changes that would be beneficial to users:
|
||||
|
||||
* Removed a few binary blobs that GNU Boot overlooked, which were included in
|
||||
the GNU Boot (these were also overlooked in Canoeboot releases, and have
|
||||
been handled in Canoeboot, thanks to reports sent by Denis Carikli of GNUBoot)
|
||||
* The `CONFIG_USE_BLOBS` setting was disabled on all coreboot configs - it
|
||||
is an extra setting that reduces the chance of the coreboot build system
|
||||
accidentally downloading blobs.
|
||||
* Uses the coreboot build system to generate TOP SWAP bootblocks on i945,
|
||||
rather than using dd. This means that the 2nd bootblock is present in CBFS,
|
||||
reducing the chance that it will be overwritten at build time.
|
||||
* They've started integrating the Guix package manager into their build system,
|
||||
for example they now use Guix (not to be confused with Guix System, which
|
||||
ironically cannot build GNU Boot due to lack of GCC-Gnat) to build GRUB.
|
||||
This results in higher maintenance burden and slows down development of
|
||||
GNU Boot - I considered using Nix in lbmk, but I need to be able to change
|
||||
everything quickly. Extra complexity like that is overkill. The benefit
|
||||
though is that users can more easily build the software, without thinking
|
||||
about it as much.
|
||||
|
||||
GNU Boot 0.1 RC has not altered the coreboot code on any machines, nor the
|
||||
GRUB code, and in fact it seems to be vanilla GRUB 2.06. Most of the changes
|
||||
by 0.1 RC3 have been further integration of the Untitled Static Site Generator
|
||||
maintained by Leah Rowe, adapting Untitled (which builds the Libreboot,
|
||||
Canoeboot and GNU Boot websites) so that it can be used with the GNU Savannah
|
||||
infrastructure more easily (as of 2 January 2024, the GNU Boot project is
|
||||
considering adapting the website for use with Haunt instead of Untitled).
|
||||
|
||||
GNU Boot's code complexity increased, considerably. Counting build scripts,
|
||||
the GNU Boot build system is **3216 lines of code**, as of 0.1 RC3 - whereas,
|
||||
the Canoeboot *20240102* build system is **1127 lines of code**. That's about
|
||||
3x smaller, but don't let size fool you. Canoeboot's [design](docs/maintain/)
|
||||
is highly efficient. It does a lot more than GNU Boot currently does. You'll
|
||||
note that this figure of 1127 is *lower* than the one given for Canoeboot
|
||||
version 20231107, above. That is because Canoeboot became *more* efficient
|
||||
since then!
|
||||
|
||||
Despite the considerable reduction in code size, by comparison, the Canoeboot
|
||||
build system is *much* more powerful. It *does* a lot more, patching and
|
||||
building a lot more projects, including U-Boot, and it handles cross compilation
|
||||
too, for ARM - it also integrates Serprog firmware projects, for STM32
|
||||
and RP2040 devices, and has much better support for autoconf/cmake-based projects.
|
||||
|
||||
The Canoeboot build system is so vastly efficient due to its design. GNU Boot
|
||||
is based upon and expanded from Libreboot 20220710, which used a much more
|
||||
complicated build system design. The *Canoeboot* build system inherits changes
|
||||
from Libreboot Build System Audit [1](https://libreboot.org/news/audit.html),
|
||||
[2](https://libreboot.org/news/audit2.html),
|
||||
[3](https://libreboot.org/news/audit3.html) and
|
||||
[4](https://libreboot.org/news/audit4.html), the purpose of which was (and is)
|
||||
to reduce build system complexity, improving efficiency and reliability, while
|
||||
adding many more features. Essentially, Canoeboot generalises a lot more logic,
|
||||
handling codebases (download, patch, configure, compile) more generically with
|
||||
a single script, whereas GNU Boot has separate scripts for each project, and
|
||||
thus *duplicates* a lot of logic. While the latter design of GNU Boot is more
|
||||
flexible in some ways, it does result in much higher complexity.
|
||||
|
||||
It should be noted that GNUBoot's code complexity *increased* a lot, relative
|
||||
to Libreboot 20220710 which it forked, while not actually adding any new
|
||||
functionality (none that will be beneficial to most users). The 20220710
|
||||
build system was *2117* lines of code, versus GNU Boot's 3216,
|
||||
Canoeboot's 1127 and Libreboot's (on 2 January 2024) 1562!
|
||||
|
||||
That's all. The information above, and more, will be properly merged into this
|
||||
page when the next release of Canoeboot comes out, or when/if GNU Boot makes
|
||||
considerable technical improvements to their project.
|
||||
|
||||
As of 2 January 2024, GNU Boot is *still* about 1 year behind on code and
|
||||
about 2 years behind on documentation, when comparing to the technical
|
||||
progress of Libreboot; the same numbers also apply to Canoeboot vs GNU Boot.
|
||||
|
||||
Canoeboot 20240504
|
||||
==================
|
||||
|
||||
See: [Canoeboot 20240504 release](news/canoeboot20240504.md).
|
||||
|
||||
On this day, 4 May 2024, GNU Boot still has not made much progress; they're
|
||||
still stuck on 0.1 RC3, without my fixes that I showed off in Canoeboot 0.1,
|
||||
that I sent to them;
|
||||
|
||||
Now I have Canoeboot 20240504, which is vastly more up to date than the
|
||||
November 2023 Canoeboot release, based on the newest Libreboot 20240504
|
||||
release (simultaneous release!)
|
||||
|
||||
Look at the changelog in that release announcement, and you will see many
|
||||
further changes that Canoeboot has made. GNU Boot is essentially now a
|
||||
pointless project, more so than before; Canoeboot is so far ahead that the
|
||||
only feasible way GNU Boot could survive is to delete itself and start over,
|
||||
by forking from the current revisions of Canoeboot.
|
||||
|
||||
But why would they do that? Canoeboot is already FSDG compliant, and provides
|
||||
exactly what they want. But I'm maintaining it, and will continue to do so,
|
||||
so why should anyone want to use their project?
|
||||
|
||||
|
|
@ -78,16 +78,3 @@ Reguläre Binär Veröffentlichungen bieten diese ROM Images vor-kompiliert,
|
|||
und Du kannst dies einfach installieren ohne spezielle technische
|
||||
Kenntnisse oder Fertigkeiten abgesehen von der Fähigkeit einer
|
||||
[vereinfachten Anleitung, geschrieben für technisch unerfahrene Benutzer](docs/install/) zu folgen.
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
||||
|
|
|
|||
|
|
@ -74,15 +74,3 @@ de connaissances techniques décente pour écrire une configuration qui marche.
|
|||
Les versions de Canoeboot fournissent ces images ROM pré-compilés et vous
|
||||
pouvez les installez simplement, sans connaissance ou compétence particulière
|
||||
à savoir, sauf [suivre des instructions simplifiés écrite pour des utilisateurs non techniques](docs/install/).
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
|
|
|||
|
|
@ -72,15 +72,3 @@ tecniche per produrre una configurazione funzionante.
|
|||
I rilasci binari di Canoeboot forniscono immagini ROM precompilate,
|
||||
che puoi semplicemente installare senza troppe conoscenze tecniche o abilita'
|
||||
particolari ad eccezione del seguire [semplici istruzioni scritte per chiunque](docs/install/).
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
|
|
|||
|
|
@ -85,15 +85,3 @@ ROM images pre-compiled, and you can simply install them, with no special
|
|||
knowledge or skill except the ability to
|
||||
follow [simplified instructions, written for non-technical
|
||||
users](docs/install/).
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
|
|
|||
|
|
@ -69,15 +69,3 @@ Coreboot помітно складний для встановлення для
|
|||
знань або навичок, окрім можливості
|
||||
слідувати [спрощеним інструкціям, написаним для нетехнічних
|
||||
користувачів](docs/install/).
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
|
|
|||
|
|
@ -30,15 +30,3 @@ Canoeboot 是一个 *coreboot 发行版*，就好比 *Alpine Linux* 是一个 *L
|
|||
如果你要构建常规的 coreboot，而不使用 Canoeboot 的自动构建系统，那么需要有很多的干预以及相当的技术知识，才能写出一份能工作的配置。
|
||||
|
||||
Canoeboot 的常规二进制版本，提供了这些预编译的 ROM 镜像。你可以轻松安装它们，而无需特别的知识和技能，只要能遵循[写给非技术用户的简单指南](docs/install/)。
|
||||
|
||||
Canoeboot was *originally* named [nonGeNUine Boot](news/nongenuineboot20230717.html),
|
||||
provided as a proof of concept for the GNU Boot
|
||||
or *gnuboot* project to use a more modern Libreboot base, but
|
||||
they went in their own direction instead. Canoeboot development was continued,
|
||||
and it maintains sync with the Libreboot project, as a parallel development
|
||||
effort. See: [How are Canoeboot releases engineered?](about.md#how-releases-are-engineered)
|
||||
|
||||
Canoeboot adheres to the *GNU Free System Distribution Guidelines* as policy,
|
||||
whereas Libreboot adheres to its own [Binary Blob Reduction
|
||||
Policy](https://libreboot.org/news/policy.html). Canoeboot and Libreboot
|
||||
are *both* maintained by the same person, Leah Rowe, sharing code back and forth.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
canoeboot20240504.md
|
||||
canoeboot0.1.md
|
||||
canoeboot20231107.md
|
||||
canoeboot20231103.md
|
||||
canoeboot20231101.md
|
||||
canoeboot20231026.md
|
||||
nongenuineboot20230717.md
|
||||
|
|
|
|||
|
|
@ -1,74 +0,0 @@
|
|||
% Canoeboot v0.1 released!
|
||||
% Leah Rowe in Canoe Leah Mode™
|
||||
% 27 January 2024
|
||||
|
||||
**WARNING: This release lacks LUKS2 support. If you want LUKS2 with argon2,
|
||||
please use the November 2023 release, or use a release made after 0.1. This
|
||||
is because 0.1 uses an older GRUB revision (more context provided below)**
|
||||
|
||||
**Canoeboot 0.1 is a meme release, and this will become clear when you read
|
||||
the notes below. Canoeboot 0.1 is not intended for production use, but only as
|
||||
a proof of concept. To reiterate: please use the November 2023 Canoeboot
|
||||
release, or a release made after Canoeboot 0.1.**
|
||||
|
||||
This is a special release. It is *not* based on the recent
|
||||
[Libreboot 20240126 release](https://libreboot.org/news/libreboot20240126.html).
|
||||
No, it is very special indeed.
|
||||
|
||||
I have recently sent GNU Boot some patches for their 0.1 RC3 release, fixing
|
||||
it so that it compiles on modern distros. Their release only compiled on really
|
||||
old distros like Debian 10 or Trisquel 10. I made it compile on the latest
|
||||
Gentoo, Arch and Debian(Sid) as of 14 January 2024. I also added Dell Latitude
|
||||
E6400, gru\_bob and gru\_kevin chromebooks. I also added several initialisation
|
||||
fixes for keyboards in their GRUB payload, in addition to EFI System Partition
|
||||
support in their `grub.cfg` - in other words, I've backported several fixes
|
||||
and improvements from Canoeboot and Libreboot, to their project.
|
||||
|
||||
I did this, purely for fun, to see if it was technically feasible. And it was.
|
||||
I sent these patches and they are now under review by the GNU people.
|
||||
|
||||
As you may know from reading this Canoeboot website, Canoeboot is vastly more
|
||||
up to date than GNU Boot, using revisions 2 years newer (from 2023), whereas
|
||||
GNU Boot uses old 2021 coreboot, GRUB and SeaBIOS revisions. It does not contain
|
||||
improvements such as GRUB argon2 support.
|
||||
|
||||
Well, purely for fun, I made this special Canoeboot v0.1 release, which re-uses
|
||||
the same *old* 2021 revisions as GNU Boot 0.1 RC3, but with my special fixes
|
||||
as mentioned above (so, it has E6400/gru\_bob/gru\_kevin, and builds on modern
|
||||
distros). However, that release is compiled using Canoeboot's build system,
|
||||
which is vastly more efficient than the GNU Boot one (about twice as fast, and
|
||||
less error prone, due to optimisations made during the four Libreboot build
|
||||
system audits of 2023).
|
||||
|
||||
You can find the Canoeboot v0.1 release on the mirrors, alongside regular
|
||||
releases. It should boot and work perfectly, albeit it on those very old code
|
||||
revisions. It is advised that you still use the November 2023 Canoeboot
|
||||
release, for the time being. A proper Canoeboot update, based on
|
||||
Libreboot 20240126 (which uses Coreboot revisions from January 2024) will be
|
||||
done at a date in the near future.
|
||||
|
||||
Anyway, the fixes that I did were sent to the GNU Boot mailing list. Check
|
||||
the `gnuboot-patches` mailing list archive from 16 January 2024.
|
||||
|
||||
GNU Boot 0.1 RC3 fixes:
|
||||
<https://git.disroot.org/vimuser/gnuboot/commits/branch/0.1-fix-build-v3>
|
||||
|
||||
Canoeboot v0.1 branch:
|
||||
<https://codeberg.org/canoeboot/cbmk/commits/branch/v0.1>
|
||||
|
||||
I also did another GNU Boot branch for fun, that updates it to the
|
||||
October 2023 revisions used in Libreboot/Canoeboot releases from November 2023:
|
||||
<https://git.disroot.org/vimuser/gnuboot/commits/branch/20240113-update-revs-3> \
|
||||
...these patches were also sent, but it seems they still prefer to use my
|
||||
Libreboot 20220710 release.
|
||||
|
||||
The GNU Boot 0.1 RC3 release is essentially Libreboot 20220710, with a few
|
||||
minor changes, and Canoeboot v0.1 is essentially Libreboot 20220710 aswell,
|
||||
but with *substantial* build system design changes (but the overall code
|
||||
is identical, when analysing the binaries).
|
||||
|
||||
PS: I use a new GPG signing key on Libreboot releases now. Check the Libreboot
|
||||
download page for it. At the time of writing, the new key is not listed on
|
||||
the Canoeboot page but I used that key.
|
||||
|
||||
|
||||
|
|
@ -542,8 +542,7 @@ not needed.
|
|||
As a result, the Canoeboot build system is about 1250 sloc when counting shell
|
||||
scripts of the build system; the Libreboot build system is about 1750. This
|
||||
comparison is between Canoeboot 20231026 and Libreboot 20231021 - by contrast,
|
||||
Libreboot 20230625 was 3388 sloc, and GNU Boot 0.1 RC is 2111 sloc (counting
|
||||
shell scripts, because it uses the same design as lbmk and cbmk).
|
||||
Libreboot 20230625 was 3388 sloc.
|
||||
|
||||
That ~1250 sloc in Canoeboot is *with* all the extra features such as serprog
|
||||
integration and U-Boot support (on actual mainboards, that you can flash it
|
||||
|
|
@ -750,49 +749,10 @@ not the only choice, but there was a time when osboot didn't even exist, let
|
|||
alone the new Libreboot, and the other more pragmatic coreboot distros do not
|
||||
support as much hardware as Libreboot does today.
|
||||
|
||||
You should use Libreboot, even if your hardware is compatible with Canoeboot.
|
||||
I make these Canoeboot releases, specifically so that I have something to crap
|
||||
all over. I could criticise GNU Boot more heavily, but GNU Boot is even more
|
||||
inferior; I make Canoeboot as good as it can feasibly be at any point in time,
|
||||
and criticise *that* result. My arguments are stronger when an *example* exists,
|
||||
especially a strong example such as Canoeboot. If the best possible solution is
|
||||
still inferior, then that will further invalidate the even lesser solutions,
|
||||
and that is the entire purpose of Canoeboot; I do Canoeboot releases, specifically
|
||||
so that I can crap all over them. I'm allowed to do that if it's mine.
|
||||
|
||||
I say again. Canoeboot is inferior.
|
||||
I say again. Canoeboot is inferior. An inferior, but well-engineered monster.
|
||||
|
||||
[Download Libreboot 20231021 instead](https://libreboot.org/news/libreboot20231021.html).
|
||||
|
||||
Censored Libreboot 20230710 release
|
||||
===================================
|
||||
|
||||
On this day, the websites of Censored Libreboot and nonGeNUine Boot are being
|
||||
redirected (HTTP 301 return) to the Canoeboot website.
|
||||
|
||||
An archive of nonGeNU 20230717's announcement is contained on this website,
|
||||
but not Censored Libreboot 20230717; it was virtually identical to
|
||||
nonGeNUine Boot 20230717, the latter of which was just a re-brand of
|
||||
Censored Libreboot.
|
||||
|
||||
If you do want to see either nonGeNU or C-Libreboot, go to these links:
|
||||
|
||||
* <https://browse.libreboot.org/lbmk.git/log/?h=fsdg20230625>
|
||||
* <https://codeberg.org/libreboot/lbwww/commits/branch/c20230710>
|
||||
* <https://libreboot.org/news/censored-libreboot20230710.html>
|
||||
|
||||
And for nonGeNUine Boot, though the code (website and code) is included in
|
||||
the Canoeboot repositories, here are the original repositories:
|
||||
|
||||
* <https://codeberg.org/vimuser/gbmk>
|
||||
* <https://codeberg.org/vimuser/gbwww>
|
||||
* <https://codeberg.org/vimuser/gbwww-img>
|
||||
|
||||
You can find the actual software release archives for nonGeNUine Boot 20230717
|
||||
and Censored Libreboot 20230710 under Libreboot rsync mirrors,
|
||||
in the `canoeboot` directory. They have been moved there, from where they
|
||||
were previously hosted.
|
||||
|
||||
Post-release errata
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,345 +0,0 @@
|
|||
% nonGeNUine Boot 20230717 released!
|
||||
% Leah Rowe in GNU Leah Mode™
|
||||
% 17 July 2023
|
||||
|
||||
Original GNU Boot ("gnuboot") release
|
||||
=====================================
|
||||
|
||||
This project was *originally* named GNU Boot or *gnuboot*, unofficially, with
|
||||
the intent that it would be re-used by the *real* GNU Boot project, to help them
|
||||
get in sync with modern Libreboot releases; on 17 July 2023, they still used
|
||||
very old Libreboot releases, with old coreboot revisions from around ~mid 2021.
|
||||
|
||||
This non-**G**e**NU**ine release was renamed to *nonGeNUine Boot* after
|
||||
receiving a [legal threat, citing trademark infringement](#update-21-july-2023)
|
||||
from the official GNU Boot project.
|
||||
|
||||
More context for this is provided on the [GNU Boot vs Canoeboot](../gnuboot.md)
|
||||
page.
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
nonGeNUine Boot provides boot firmware for supported x86/ARM machines, starting a
|
||||
bootloader that then loads your operating system. It replaces proprietary
|
||||
BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
|
||||
on [ARM-based chromebooks](../docs/install/chromebooks.html) supported
|
||||
(U-Boot bootloader, instead of Google's depthcharge bootloader). On x86
|
||||
machines, the GRUB and SeaBIOS coreboot
|
||||
payloads are officially supported, provided in varying configurations per
|
||||
machine. It provides an [automated build system](../docs/maintain/) for the
|
||||
[configuration](../docs/build/) and [installation](../docs/install/) of coreboot
|
||||
ROM images, making coreboot easier to use for non-technical people. You can find
|
||||
the [list of supported hardware](../docs/hardware/) in nonGeNUine Boot documentation.
|
||||
|
||||
nonGeNUine Boot's main benefit is *higher boot speed*,
|
||||
[better](../docs/gnulinux/encryption.md)
|
||||
[security](../docs/gnulinux/grub_hardening.md) and more
|
||||
customisation options compared to most proprietary firmware. As a
|
||||
[libre](https://www.gnu.org/philosophy/free-sw.html) software project, the
|
||||
code can be audited, and coreboot does
|
||||
regularly audit code. The other main benefit is [*freedom* to study, adapt and
|
||||
share the code](https://www.gnu.org/licenses/license-list.en.html), a freedom
|
||||
denied by most boot firmware, but not nonGeNUine Boot! Booting GNU+Linux and BSD is
|
||||
also [well](../docs/gnulinux/) [supported](../docs/bsd/).
|
||||
|
||||
Changes, relative to Libreboot 20220710
|
||||
========================================
|
||||
|
||||
nonGeNUine Boot is a fork of Libreboot. This release is based on Libreboot 20230625,
|
||||
with certain boards/documentation removed so as to comply with the [GNU
|
||||
System Distribution Guidelines (GNU
|
||||
FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html).
|
||||
|
||||
*Libreboot 20220710* was the *last* regular Libreboot release to comply
|
||||
with the old *Binary Blob Extermination Policy* adhering to GNU FSDG
|
||||
ideology. Read the [Libreboot 20220710 release
|
||||
announcement](https://libreboot.org/news/libreboot20220710.html).
|
||||
|
||||
For the purpose of *continuity*, this release will list changes relative to that
|
||||
version. Future releases of nonGeNUine Boot will reference past releases of *itself*.
|
||||
|
||||
New mainboards supported
|
||||
------------------------
|
||||
|
||||
These laptops would have been compatible with Libreboot, under the old
|
||||
policy, and they were added in this release of nonGeNUine Boot:
|
||||
|
||||
* [Dell Latitude E6400](../docs/hardware/e6400.md)
|
||||
* [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
|
||||
* [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
|
||||
|
||||
KFSN4-DRE, KCMA-D8, KGPE-D16 *update*
|
||||
-------------------------------------
|
||||
|
||||
FUN FACT: This includes building of ASUS KFSN4-DRE, KCMA-D8 and KGPE-D16
|
||||
boards, which were updated based on coreboot `4.11_branch`. ROM images are
|
||||
provided for these boards, in this nonGeNUine Boot release. The toolchain in
|
||||
this coreboot version would not build on modern GNU+Linux distributions, so I
|
||||
spent time patching it.
|
||||
|
||||
Coreboot, GRUB, U-Boot and SeaBIOS revisions
|
||||
------------------------------------
|
||||
|
||||
In nonGeNUine Boot 20230717:
|
||||
|
||||
* Coreboot (default): commit ID `e70bc423f9a2e1d13827f2703efe1f9c72549f20`, 17 February 2023
|
||||
* Coreboot (cros): commit ID `8da4bfe5b573f395057fbfb5a9d99b376e25c2a4` 2 June 2022
|
||||
* Coreboot (fam15h\_udimm): commit ID `1c13f8d85c7306213cd525308ee8973e5663a3f8`, 16 June 2021
|
||||
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 14 February 2023
|
||||
* SeaBIOS: commit ID `ea1b7a0733906b8425d948ae94fba63c32b1d425`, 20 January 2023
|
||||
* U-Boot (for coreboot/cros): commit ID `890233ca5569e5787d8407596a12b9fca80952bf`, 9 January 2023
|
||||
|
||||
In Libreboot 20220710:
|
||||
|
||||
* Coreboot (default): commit ID `b2e8bd83647f664260120fdfc7d07cba694dd89e`, 17 November 2021
|
||||
* Coreboot (cros): **did not exist** (no ARM/U-Boot support in Libreboot 20220710)
|
||||
* Coreboot (fam15h\_udimm): commit ID `ad983eeec76ecdb2aff4fb47baeee95ade012225`, 20 November 2019
|
||||
* GRUB: commit ID `f7564844f82b57078d601befadc438b5bc1fa01b`, 25 October 2021
|
||||
* SeaBIOS: commit ID `1281e340ad1d90c0cc8e8d902bb34f1871eb48cf`, 24 September 2021
|
||||
* U-Boot: **did not exist** (no ARM/U-Boot support in Libreboot 20220710)
|
||||
|
||||
Build system changes
|
||||
--------------------
|
||||
|
||||
The changes are *vast*, and most of them visible directly by viewing the
|
||||
Libreboot git history; for reference, this nonGeNUine Boot release corresponds
|
||||
approximately to `lbmk` (LibreBoot MaKe)
|
||||
revision `8c7774289ca60a1144b3151344eb400a059390e0` from 16 July 2023.
|
||||
|
||||
And now, the changes (summarised, relative to Libreboot 20220710):
|
||||
|
||||
* Coreboot crossgcc downloads: when coreboot downloads `acpica` (for use
|
||||
of `iasl`), the old upstream links to tarballs are no longer online. Newer
|
||||
versions of coreboot pull from github, but nonGeNUine Boot is still using some
|
||||
older coreboot revisions prior to that change. The corresponding tarballs
|
||||
are now hosted on Libreboot rsync, and used by nonGeNUine Boot's build
|
||||
system, [gbmk](../docs/maintain/) (itself a fork of the Libreboot build
|
||||
system, named `lbmk`). (**NOTE: gbmk was renamed to cbmk, when the project
|
||||
became Canoeboot**)
|
||||
* A [HUGE build system audit](https://libreboot.org/news/audit.html) inherited
|
||||
from Libreboot, has been assimilated by nonGeNUine Boot; the entire build system was
|
||||
re-written in a much cleaner coding style, with much stricter error handling
|
||||
and clear separation of logic. A *lot* of bugs were fixed. A *LOT* of bugs.
|
||||
Build system auditing has been the *main* focus, in these past 12 months.
|
||||
* `cros`: Disable coreboot-related BL31 features. This fixes poweroff on gru
|
||||
chromebooks. Patch courtesy of Alper Nebi Yasak.
|
||||
* `u-boot`: Increase EFI variable buffer size. This fixes an error where
|
||||
Debian's signed shim allocates too many EFI variables to fit in the space
|
||||
provided, breaking the boot process in Debian. Patch courtesy Alper Nebi Yasak
|
||||
* Coreboot build system: don't warn about no-payload configuration. nonGeNUine Boot
|
||||
compiles ROM images *without* using coreboot's payload support, instead it
|
||||
builds most payloads by itself and inserts them (via cbfstool) afterwards.
|
||||
This is more flexible, allowing greater configuration; even U-Boot is
|
||||
handled this way, though U-Boot at least still uses coreboot's crossgcc
|
||||
toolchain collection to compile it. Patch courtesy Nicholas Chin.
|
||||
* `util/spkmodem-recv`: New utility, forked from GNU's implementation, then
|
||||
re-written to use OpenBSD style(9) programming style instead of the
|
||||
originally used GNU programming style, and it is uses
|
||||
OpenBSD `pledge()` when compiled on OpenBSD. Generally much cleaner coding
|
||||
style, with better error handling than the original GNU version (it is forked
|
||||
from coreboot, who forked it from GNU GRUB, with few changes made). This
|
||||
is a receiving client for spkmodem, which is a method coreboot provides to
|
||||
get a serial console via pulses on the PC speaker.
|
||||
* download/coreboot: Run `extra.sh` directly from given coreboot tree. Unused
|
||||
by any boards, but could allow expanding upon patching capabilities in lbmk
|
||||
for specific mainboards, e.g. apply coreboot gerrit patches in a specific
|
||||
order that is not easy to otherwise guarantee in more generalised logic of
|
||||
the nonGeNUine Boot build system.
|
||||
* `util/e6400-flash-unlock`: New utility, that disables flashing protections
|
||||
on Dell's own BIOS firmware, for Dell Latitude E6400. This enables nonGeNUine Boot
|
||||
installation *without* disassembling the machine (external flashing equipment
|
||||
is *not required*). Courtesy Nicholas Chin.
|
||||
* Build dependencies scripts updated for more modern distros. As of this day's
|
||||
release, nonGeNUine Boot compiles perfectly in bleeding edge distros e.g. Arch
|
||||
Linux, whereas the previous 20220710 required using old distros e.g.
|
||||
Debian 10.
|
||||
* `cbutils`: New concept, which implements: build coreboot utilities like
|
||||
cbfstool and include the binaries in a directory inside lbmk, to be re-used.
|
||||
Previously, they would be compiled in-place within the coreboot build system,
|
||||
often re-compiled needlessly, and the checks for whether a given util are
|
||||
needed were very ad-hoc: now these checks are much more robust.
|
||||
Very centralised approach, per coreboot tree, rather than selectively
|
||||
compiling specific coreboot utilities, and makes the build system logic in
|
||||
nonGeNUine Boot much cleaner.
|
||||
* GRUB config: 30s timeout by default, which is friendlier on some desktops
|
||||
that have delayed keyboard input in GRUB.
|
||||
* ICH9M/GM45 laptops: 256MB VRAM by default, instead of 352MB. This fixes
|
||||
certain performance issues, for some people, as 352MB can be very unstable.
|
||||
* U-Boot patches: for `gru_bob` and `gru_kevin` chromebooks, U-Boot is used
|
||||
instead of Google's own *depthcharge* bootloader. It has been heavily
|
||||
modified to avoid certain initialisation that is replaced by coreboot, in
|
||||
such a way that U-Boot is mainly used as a bootloader providing UEFI for
|
||||
compliant GNU+Linux distros and BSDs. Courtesy Alper Nebi Yasak.
|
||||
* lbmk: The entire nonGeNUine Boot build system has, for the most part, been made
|
||||
portable; a lot of scripts now work perfectly, on POSIX-only implementations
|
||||
of `sh` (though, many dependencies still use GNU extensions, such as GNU
|
||||
Make, so this portability is not directly useful yet, but a stepping stone.
|
||||
nonGeNUine Boot eventually wants to be buildable on non-GNU, non-GNU/Linux systems,
|
||||
e.g. BSD systems)
|
||||
* nvmutil: Lots of improvements to code quality, features, error handling. This
|
||||
utility was originally its own project, started by Leah Rowe, and later
|
||||
imported into the nonGeNUine Boot build system.
|
||||
* build/boot/roms: Support cross-compiling coreboot toolchains for ARM platforms,
|
||||
in addition to regular x86 that was already supported. This is used for
|
||||
compiling U-boot as a payload, on mainboards.
|
||||
* U-boot integration: at first, it was just downloading U-Boot. Board integration
|
||||
for ARM platforms (from coreboot) came later, e.g. ASUS Chromebook Flip C101
|
||||
as mentioned above. The logic for this is forked largely from the handling
|
||||
of coreboot, because the interface for dealing with their build systems is
|
||||
largely similar, and they are largely similar projects. Courtesy Denis Carikli
|
||||
and Alper Nebi Yasak.
|
||||
* New utility: `nvmutil` - can randomise the MAC address on Intel GbE NICs, for
|
||||
systems that use an Intel Flash Descriptor
|
||||
* General build system fixes: better (and stricter) error handling
|
||||
* Fixed race condition when building SeaBIOS in some setups.
|
||||
* GRUB configs: only scan ATA, AHCI or both, depending on config per board.
|
||||
This mitigates performance issues in GRUB on certain mainboards, when
|
||||
scanning for `grub.cfg` files on the HDD/SSD.
|
||||
* GRUB configs: speed optimisations by avoiding slow device enumeration in
|
||||
GRUB.
|
||||
|
||||
Hardware supported in nonGeNUine Boot 20230717
|
||||
==================================================
|
||||
|
||||
All of the following are believed to *boot*, but if you have any issues,
|
||||
please contact the nonGeNUine Boot project. They are:
|
||||
|
||||
### Servers (AMD, x86)
|
||||
|
||||
- [ASUS KGPE-D16 motherboard](../docs/hardware/kgpe-d16.md)
|
||||
- [ASUS KFSN4-DRE motherboard](../docs/hardware/kfsn4-dre.md)
|
||||
|
||||
### Desktops (AMD, Intel, x86)
|
||||
|
||||
- [ASUS KCMA-D8 motherboard](../docs/hardware/kcma-d8.md)
|
||||
- [Gigabyte GA-G41M-ES2L motherboard](../docs/hardware/ga-g41m-es2l.md)
|
||||
- [Acer G43T-AM3](../docs/hardware/acer_g43t-am3.md)
|
||||
- [Intel D510MO and D410PT motherboards](../docs/hardware/d510mo.md)
|
||||
- [Apple iMac 5,2](../docs/hardware/imac52.md)
|
||||
|
||||
### Laptops (Intel, x86)
|
||||
|
||||
- **[Dell Latitude E6400](../docs/hardware/e6400.md) (easy to flash, no disassembly, similar
|
||||
hardware to X200/T400)**
|
||||
- ThinkPad X60 / X60S / X60 Tablet
|
||||
- ThinkPad T60 (with Intel GPU)
|
||||
- [Lenovo ThinkPad X200 / X200S / X200 Tablet](../docs/hardware/x200.md)
|
||||
- Lenovo ThinkPad X301
|
||||
- [Lenovo ThinkPad R400](../docs/hardware/r400.md)
|
||||
- [Lenovo ThinkPad T400 / T400S](../docs/hardware/t400.md)
|
||||
- [Lenovo ThinkPad T500](../docs/hardware/t500.md)
|
||||
- [Lenovo ThinkPad W500](../docs/hardware/t500.md)
|
||||
- [Lenovo ThinkPad R500](../docs/hardware/r500.md)
|
||||
- [Apple MacBook1,1 and MacBook2,1](../docs/hardware/macbook21.md)
|
||||
|
||||
### Laptops (ARM, with U-Boot payload)
|
||||
|
||||
- [ASUS Chromebook Flip C101 (gru-bob)](../docs/install/chromebooks.md)
|
||||
- [Samsung Chromebook Plus (v1) (gru-kevin)](../docs/install/chromebooks.md)
|
||||
|
||||
UPDATE (21 July 2023)
|
||||
=====================
|
||||
|
||||
This website, that you are reading now, and the nonGeNUine release itself,
|
||||
was originally *named* GNU Boot, but clearly marked as *unofficial*, with the
|
||||
hope that the GNU project would adapt and re-use it for their project. I did
|
||||
this, specifically to help them get up to date. They currently use Libreboot
|
||||
from about 8 months ago (late 2022), and that revision used *coreboot* releases
|
||||
from ~mid 2021.
|
||||
|
||||
Modern Libreboot uses coreboot from early 2023, and contains many bug fixes
|
||||
in its build system, owing to an extensive [build system
|
||||
audit](https://libreboot.org/news/audit.html); GNU Boot still contains all of
|
||||
the bugs that existed, prior to the audit. Bugs such as: errors literally not
|
||||
being handled, in many critical areas of the build system, due to improper use
|
||||
of subshells within shell scripts (Libreboot's build system is implemented with
|
||||
shell scripts), improper handling of git credentials in the coreboot build
|
||||
system, fam15h boards no longer compiling correct on modern Linux distros...
|
||||
the list goes on. All fixed, in newer Libreboot, including the recent release.
|
||||
|
||||
GNU Boot cease and desist email
|
||||
-------------------------------
|
||||
|
||||
The GNU Boot people actually sent me a cease and desist email, citing trademark
|
||||
infringement. Amazing.
|
||||
|
||||
Despite the original site clearly stating that it's unofficial. I literally made
|
||||
it to help them. You know, to help them use newer Libreboot because they use old
|
||||
Libreboot and even older coreboot.
|
||||
|
||||
Anyway, I complied with their polite request and have renamed the project to
|
||||
nonGeNUine Boot. The release archive was re-compiled, under this new brand
|
||||
name and this nonGeNUine website was re-written accordingly.
|
||||
|
||||
Personally, I like the new name better.
|
||||
|
||||
Here is a screenshot of the cease and desist request that I received,
|
||||
from *Adrien ‘neox’ Bourmault* who is a founding member of the GNU Boot
|
||||
project:
|
||||
|
||||
|
||||
|
||||
This, after they themselves tried to steal the name *Libreboot* for their
|
||||
fork, when they first announced themselves on 19 March 2023 at LibrePlanet,
|
||||
only renaming to *GNU Boot* months later (on 11 June 2023). Utter hypocrisy,
|
||||
and a great irony to boot.
|
||||
|
||||
I may very well send patches. *If I want to*.
|
||||
|
||||
Errata
|
||||
======
|
||||
|
||||
The following binary blobs were overlooked, and are still present in the
|
||||
release archive for Canoeboot up to 20231101; this mistake was
|
||||
corrected, in the [Canoeboot 20231103 release](canoeboot20231103.md), so you
|
||||
should use that or newer if you don't want these files. They are, thus:
|
||||
|
||||
* `src/coreboot/default/3rdparty/stm/Test/FrmPkg/Core/Init/Dmar.h`
|
||||
* `src/coreboot/fam15h_rdimm/src/vendorcode/intel/fsp1_0/baytrail/absf/minnowmax_1gb.absf`
|
||||
* `src/coreboot/fam15h_rdimm/src/vendorcode/intel/fsp1_0/baytrail/absf/minnowmax_2gb.absf`
|
||||
* `src/coreboot/fam15h_udimm/src/vendorcode/intel/fsp1_0/baytrail/absf/minnowmax_1gb.absf`
|
||||
* `src/coreboot/fam15h_udimm/src/vendorcode/intel/fsp1_0/baytrail/absf/minnowmax_2gb.absf`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_err.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_gap.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_gatt.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_gattc.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_gatts.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_hci.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_l2cap.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_ranges.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/ble_types.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_error.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_error_sdm.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_error_soc.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_nvic.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_sdm.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_soc.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf_svc.h`
|
||||
* `src/pico-sdk/lib/tinyusb/hw/mcu/nordic/nrf5x/s140_nrf52_6.1.1_API/include/nrf52/nrf_mbr.h`
|
||||
|
||||
Thanks go to Craig Topham, who is the Copyright and Licensing Associate at the
|
||||
Free Software Foundation; you can find his entry on the [FSF staff
|
||||
page](https://www.fsf.org/about/staff-and-board). Craig is the one who reported
|
||||
these.
|
||||
|
||||
The Canoeboot 20231026 and 20231101 release tarballs will not be altered, but
|
||||
errata has now been added to the announcement pages for those releases, to let
|
||||
people know of the above issue.
|
||||
|
||||
You are advised, therefore, to use the [Canoeboot 20231103
|
||||
release](canoeboot20231103.md).
|
||||
|
||||
Update on 12 November 2023:
|
||||
---------------------------
|
||||
|
||||
This file was also overlooked, and is still present in the release tarball:
|
||||
|
||||
* `src/vendorcode/amd/agesa/f12/Proc/GNB/Nb/Family/LN/F12NbSmuFirmware.h`
|
||||
|
||||
This has now been removed, in the Canoeboot git repository (`cbmk.git`), and
|
||||
this file will absent, in the next release after Canoeboot 20231107. Thanks go
|
||||
to Denis Carikli who reported this. The patch to fix it is here:
|
||||
|
||||
<https://codeberg.org/canoeboot/cbmk/commit/70d0dbec733c5552f8cd6fb711809935c8f3d2f3>
|
||||
|
|
@ -68,6 +68,7 @@ $if(date)$
|
|||
$endif$
|
||||
<ul>
|
||||
<li><a href="/index.de.html">Home</a></li>
|
||||
<li><a href="/about.html">About</a></li>
|
||||
<li><a href="/faq.html">FAQ</a></li>
|
||||
<li><strong><a href="/download.html">Download</a></strong></li>
|
||||
<li><a href="/docs/install/">Installation</a></li>
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ $if(date)$
|
|||
$endif$
|
||||
<ul>
|
||||
<li><a href="/">Home</a></li>
|
||||
<li><a href="/about.html">About</a></li>
|
||||
<li><a href="/faq.html">FAQ</a></li>
|
||||
<li><strong><a href="/download.html">Download</a></strong></li>
|
||||
<li><a href="/docs/install/">Install</a></li>
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ $if(date)$
|
|||
$endif$
|
||||
<ul>
|
||||
<li><a href="/index.it.html">Home</a></li>
|
||||
<li><a href="/about.html">About</a></li>
|
||||
<li><a href="/faq.html">FAQ</a></li>
|
||||
<li><strong><a href="/download.html">Download</a></strong></li>
|
||||
<li><a href="/docs/install/">Installazione</a></li>
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ $if(date)$
|
|||
$endif$
|
||||
<ul>
|
||||
<li><a href="/index.uk.html">Домашня</a></li>
|
||||
<li><a href="/about.html">About</a></li>
|
||||
<li><a href="/faq.html">FAQ</a></li>
|
||||
<li><strong><a href="/download.uk.html">Завантаження</a></strong></li>
|
||||
<li><a href="/docs/install/">Встановлення</a></li>
|
||||
|
|
|
|||
|
|
@ -68,6 +68,7 @@ $if(date)$
|
|||
$endif$
|
||||
<ul>
|
||||
<li><a href="/">主页</a></li>
|
||||
<li><a href="/about.html">About</a></li>
|
||||
<li><a href="/faq.html">常见问题</a></li>
|
||||
<li><strong><a href="/download.html">下载</a></strong></li>
|
||||
<li><a href="/docs/install/">安装</a></li>
|
||||
|
|
|
|||
Loading…
Reference in New Issue