GNU Boot participated in the FSF40 hackathon, which lasted from November 21, 2025, 10:00 a.m. (EST) to November 23, 2025, 10:00 a.m. (EST).
This page remains an archive of this event, and the present tense should be understood as past tense.
When the FSF40 Hackathon started, the GNU Boot repository was at commit 39c70840617d2fd849284919232b0cc09384a96c. You can see it as a reference commit for every patch listed in the tasks summary.
As part of this hackathon GNU Boot has worked on defining some tasks that you might be interested in contributing to.
If you don’t know which tasks to pick, try to maximize the chance of your work getting into GNU Boot as-is by picking tasks that are easy for you, and that you have a chance to finish, and to polish for inclusion into GNU Boot.
You could also be interested in tasks that are not below, for instance to make GNU Boot better suit your needs and/or because you care about issues we may not even thought of or that we didn’t add below because it would make the list too long. Doing all that is also fine: The GNU Boot maintainers are available during the FSF40 hackathon, so it can be a good occasion to get some help to contribute to GNU Boot, even for tasks not listed below.
If you want to work on tasks that are not defined below, if you’re not already familiar with the GNU Boot contribution instructions, it is strongly advised to read them and/or to consult with the GNU Boot maintainers before starting working on your task because in the past we had contributions that were out of scope for GNU Boot, and because of that we could not really use them, and we don’t want to waste anybody’s time (this obviously includes your time as well).
Here if you know a bit Markdown or CommonMark and git, you can easily contribute without even having to build the website.
However if you still want to do that (to test your changes), you can see the Building the website section below.
The bug tracker used by GNU Boot has several report of computers having been tested with GNU Boot.
This task would consist in making patches to add that information to the GNU Boot website status page.
The patches should also contain a link to the bug reports like that:
Bug-report: https://savannah.gnu.org/bugs/?12345This could be extremely useful if there are computers that weren’t tested before with GNU Boot, or if the latest version of GNU Boot was tested.
The GNU Boot website is a mess:
It still contains reference to Libreboot
A lot of the content in the pages is outdated or wrong.
So you can simply read the website until you find sometihng that is easy to fix.
To fix it, you can simply download GNU Boot from git, read the documentation on how to contribute, and send a patch to the GNU Boot mailing list.
While this is probably the easiest task in the list, it’s also hard to know in advance how useful the contributions will be: it basically depend on what issue you found and fix.
Also note that the Website: improve “DiffieHellman”’s patches task touches the following files:
website/pages/docs/hardware/index.html
website/pages/docs/hardware/r400.html
website/pages/docs/hardware/t500.html
website/pages/docs/hardware/x200.html
So it might be easier if you don’t touch these to avoid conflicting changes in case someone else wants to work on this other task.
In GNU Boot, reviewing patches from non-maintainers is done in a similar time frame than other free software projects (around 1 or 2 weeks to get some feedback). However maintainers also make patches, and reviewing them takes way more time.
This has led to a huge backlog of patches. Here you can help by reviewing some patches that are in the gnuboot-next branch.
In GNU Boot anybody is welcome for reviewing patches, and here the idea is to do that and try to find any mistakes in the patches, test them, ask questions related to the patches to their author(s), etc.
You will most likely be mentioned in one way or another in the patch if you reviewed it:
You can just test patches thoroughly, in that case we usually add
“Tested-by:
If you also review the patch thoroughly, we can add “Reviewed-by:
If you reviewed partially a patch and just found an error, you’ll most likely be thanked for reporting the issue in the patch in one way or another.
While every change that made it in the GNU Boot manual were reviewed by the GNU Boot maintainers, we feel that the manual is extremely important and we want it to be of very high quality and to also meet users needs.
This task would require to respond to some questions. You can skip some questions if you wish:
Does the manual contain mistakes?
What are your computer skills? Do you use GNU Boot? And is the manual easy to understand or are there parts that you didn’t understand?
We plan to add installation instructions in the manual, as well as information on how to do maintenance and potentially reparations as well on computers supported by GNU Boot. Once that would be done, would the manual meet your expectations? Are there other things missing in the manual? And here too, what are your computer skills? Do you use GNU Boot?
The idea behind asking “What are your computer skills? Do you use GNU Boot?” is to understand what kind of users to target in the manual and/or where to put the efforts.
We also welcome suggestions and/or feedback on the manual in general.
We have some pages that are translated in Spanish, and the top priority here is to synchronize the English and the Spanish translations.
The following pages are currently out of sync:
pages/git.es.html
pages/contribute.es.html
The pages/status.es.html is also out of sync on the website, and in git in the main or fsf40 branches, but there was work done in the 05b294076ac3a388f9bc2c170c9e199ee3ce9aee patch (“website: sync pages/status.html and pages/status.es.html.”) which is also in the gnuboot-next branch) to bring it back in sync. Here what is important is to review that work and correct it if it is wrong.
To do this work you will have to first coordinate with Jordán ‘iShareFreedom’ / isf for that work as isf should soon become the person responsible for Spanish translations in GNU Boot (isf is currently reviewing the patch that clarifies that).
And isf is also available in #gnuboot during the FSF 40 Hackathon and is also available by email.
Once the modifications are validated by isf, they will still need to go through the GNU Boot maintainers only the maintainers can push modifications to the GNU Boot source code and/or website.
Once the Spanish and English translations are in synchronized, you could try to identify what are the most important things left to translate (it could be some specific pages, the manual, etc).
In May 2025, there were patches (“Replace proprietary EC installation recommendation […]”) sent by “DiffieHellman” on the gnuboot-patches mailing list but they need to be split (more information on how to do that can be found on the thread about this patch on the GNU Boot mailing list).
The task here would be to do this split and send the resulting patches to the mailing list.
The patches were extracted from the mailing list and are listed below for convenience:
At the time of writing they can be applied on top of the commit 39c70840617d2fd849284919232b0cc09384a96c (“configure.ac, website/configure.ac: unify guix revision declaration.”).
This requires to know git well enough to split patches. It would enable us to finally merge the modifications and not to have to keep them in mind.
The bug tracker has at least this bug:
This task would consist in making patches to fix the issues being reported.
The patches should also contain a link to the bug reports like that:
Bug-report: https://savannah.gnu.org/bugs/?12345Having broken links isn’t nice and so this should be fixed.
In this case the following patch has been applied, as we also need to properly integrate the SVG source code of the logos we have in GNU Boot:
At the time of writing the Guix package will be removed from Debian very soon, so this complicates things as it might also be dropped from PureOS and Trisquel as well as from all other distributions based on Debian.
The reason is related to security: Guix had several security issues (September 2025, June 2025, October 2024, March 2024) that enabled an attacker that already executed code on a machine, to get root access on this machine.
Here the task would be to backport all the required patches and try to convince the Trisquel maintainer to keep the guix package.
This is extremely important for GNU Boot as Guix for several reasons:
Guix is required to really trust GNU Boot. GNU Boot isn’t really reproducible yet, so we encourage users that care about certain security attacks to build from source. To do that we encourage users to use Guix to verify the signature of the GNU Boot source code downloaded with git.
Nowadays, guix is a non-optional dependency for GNU Boot and the plan is to convert more and more scripts to Guix packages. Having Guix being easy to install is important as it also enables to more easily contribute to GNU Boot, and maybe to download GNU Boot in a far future.
This would also benefit Replicant as well as its blog is being migrated to Haunt which is only packaged in Guix.
We found nonfree software in vboot, and we removed it from GNU Boot. We also contacted many distributions about the issue and even managed to contact the upstream of this software through Coreboot.
However we’re not sure if the issue is fixed in all free GNU/Linux distribution or not.
This task would be to make sure of that. Note that Replicant is also affected but nobody had the time to look into it yet for Replicant.
The Bug #66246 has more details on that.
GNU Boot plans to use Guix more and more. However we found nonfree software in the Coreboot source shipped by Guix, but due to the lack of reviewers familiar with Coreboot our patches were never merged.
The bug #67403 has more details on the issue.
The task would consist in taking these patches, updating them if needed and upstreaming them in Guix.
“DiffieHellman” sent a patch for adding the workman keyboard:
0001-Added-workman-keymap.patch.
Unfortunately nobody tested it so it was never included.
The following patches were applied to help with testing:
On the GNU Boot status page, very few computers are tested.
We need help for testing computers. So if you have the knowledge and hardware to recover from non-working GNU Boot image, this is probably the most useful contribution you can do.
This would be especially useful with computers that were never tested before in any GNU Boot revisions.
We don’t have any good installation instructions. The only one we have are on our website and come with a scary warning.
This guide needs to be made for one of these computers:
Lenovo, ThinkPad R400, R500, T400, T400s, T500, W500
Lenovo, ThinkPad X200, X200s, X200 Tablet, X301
These ThinkPad models are well supported by GNU Boot, don’t have a glossy display that can be more dangerous for the health, especially when working a lot on the computer, and it is relatively easy to install a free GNU/Linux distribution on them.
You will need to use the ChipFlasher v2 in the instructions as this makes it much easier to install GNU Boot safely (basically not making things worse). You will also need to care about static electricity to not reduce the computer lifespan.
The ChipFlasher v2 will need to use the stock flashrom compatible firmware to make things easier.
Your guide will need to be added in the manual, but if you are more comfortable with another format like markdown and/or the website, we could convert your work to the format used by the manual later on.
You don’t need to care about improving the computer (like Changing the WiFi card, the battery, applying thermal paste and so on) because there is already a section meant for that in the manual, and this could be added later on, and it’s better to concentrate on having something basic that works, rather than having unfinished work, and this can also be done later on.
You will also instruct users to backup and restore what is on the computer flash chip. At this point we also assume that the computer comes with a nonfree BIOS, so you don’t need to do anything special for saving and restoring the MAC address, though users will have to keep backups of the nonfree BIOS anyway, so the MAC address should be in there, and could be reused for a later guide.
It would be good to either be able to take pictures or to be able to reuse pictures under a free license with a clear copyright situation. The pictures that we have already on the GNU Boot website should be pretty safe to use.
The following patches were applied so that you know how the Chipflasher v2 will be added in the list of flash programmers inside the manual:
0010-manual-security-add-section-about-updating-GNU-Boot.patch
0011-manual-security-add-information-about-installing-GNU.patch
0013-manual-security-add-instruction-to-check-images-sign.patch
To build the manual, see the Building the manual section below.
This requires to contribute to the ChipFlasher v2 directly.
The ChipFlasher v2 comes with a builtin free firmware. However the stock firmware might need to be built from source for security reasons and/or users might need to upgrade the ChipFlasher firmware at some point. The firmware that is compatible with the ‘connect’ utility provided by the ChipFlasher can also provide speed improvements that are always useful.
However both these speed improvements and the loading of a different free firmware can bring compatibility issues with some USB<->Serial adapter.
Here the task would be to test as many USB<->Serial adapter, especially those with a PL2303 chip. Some of these adapters produce the following kernel log when they are connected to a computer (it can be seen with the ‘dmesg’ command):
[ 123.456789] ftdi_sio ttyUSB0: Unable to read latency timer: -32So this task would be to help the ChipFlasher creator to fix these issues and also test adapters at bigger speed.
For more background here are some applied patches that shows how the ChipFlasher v2 might be integrated in the GNU Boot manual:
0010-manual-security-add-section-about-updating-GNU-Boot.patch
0011-manual-security-add-information-about-installing-GNU.patch
0013-manual-security-add-instruction-to-check-images-sign.patch
The description of the task was the following:
Leah Rowe found a nonfree hdcp.bin in GNU Boot.
This issue has long been fixed in GNU Boot, but it’s not fixed in GNU/Linux distributions.
This task would consist in removing this nonfree software in Guix, and all free GNU/Linux distributions, but also to notify other distributions like Debian that have a policy against the inclusion of nonfree software in some of their repositories.
The Bug #66246 is an example of how we dealt with a similar issue after finding nonfree software in vboot.
This is also important for GNU Boot because we can’t add ARM support by shipping nonfree software.
This would also benefit Replicant as well that needs a free bootloader and will probably use Guix and/or GNU Boot to go forward with the port of Replicant to the Pinephone.
Jiyu (info@jiyu.dev) completed the task and wrote a report about it and also answered questions about it on #gnuboot in Libera.Chat.
While Jiyu found that Fedora is affected, Jiyu also found out that the binary was not present (anymore) in Guix, Debian, and probably not in Dynebolic, Trisquel and PureOS either as according to Jiyu they “seem to be using the DSFG version indeed”.
The arm-trusted-firmware was absent from Dragora, Hyperbola, Parabola, LibreCMC and ProteanOS.
GNUtoo also confirmed that the nonfree binary was gone in both Guix (with guix build –source) and The git version of the Debian package.
So GNU Boot has now one blob less to worry about. Thanks a lot for the work.
The description of the task was the following:
Recent u-boot probably have nonfree software. So these would require to investigate the following:
The Debian Copyrights file for u-boot doesn’t seems to list nonfree software in u-boot, however there is clearly nonfree code.
Recent u-boot still have the drivers/usb/host/xhci-rcar-r8a779x_usb3_v3.h which nonfree code in it and a nonfree license. The arch/x86/dts/microcode/ directory is also still present. See the blobs.list file from GNU Boot source codefor more details.
In addition there is also the GNU Boot Bug #64904 that raises additional concerns about u-boot.
Here this task consist in investigating what happened in Debian to make sure we are on the right track, and contacting all free GNU/Linux distribution and other distributions as well that have a policy against the inclusion of nonfree software in some of their repositories.
It might also require to contribute to common-distros in case some nonfree distributions changed policies.
Once the investigation is done, the task would consist in fixing this issue in free GNU/Linux distribution, especially Guix as GNU Boot wants to reuse Guix to add ARM support.
This would also benefit Replicant as well that needs a free bootloader and will probably use Guix and/or GNU Boot to go forward with the port of Replicant to the Pinephone.
Jiyu (info@jiyu.dev) completed the task: 3 nonfree files were found in the Guix u-boot package and a fix was sent to Guix. The fix was tested and validated by a GNU Boot maintainer.
Jiyu also managed to report the issue to Debian: this way Trisquel will have an easier time fixing the issue if it is affected.
Normally Debian should fix it as in the past, a GNU Boot maintainer reported freedom issues in the vboot-utils Debian package and it ended up being fixed in the package.
Jiyu also updated the GNU Boot bug that tracks issues within u-boot.
Some of the tasks above require to build the manual, and some may require to build the website. Below are instructions on how to do that with Guix.
To build the manual you will need Guix in one way or another, so let’s use it to build the manual as well.
To do that first download GNU Boot and create a Guix shell with all the required dependencies:
$ git clone https://git.savannah.gnu.org/git/gnuboot.git
$ cd guix/websiteOnce this is done you should be inside a Guix shell, and you can build the manual with these commands:
[env]$ ./autogen.sh
[env]$ ./configure
[env]$ make pages/manual/gnuboot.pdfTo build the website, first download the GNU Boot source code and go inside the website directory:
$ git clone https://git.savannah.gnu.org/git/gnuboot.git
$ cd guix/website
$ icecat http://localhost:8086/software/gnuboot/Once done you can either use the following commands to build and test the website Guix:
$ ./autogen.sh
$ ./configure
$ make serveOr read the documentation in the README file which explains how to build and test the website on Trisquel without Guix.
Markdown file for this page: https://gnu.org/software/gnuboot/events/fsf40/index.md