GNU Boot

1.1.1 boot software

When you boot a computer, you can sometimes can see a screen that looks like that:

+--------------------------------------------------------------------+
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|                        [ Some company Logo ]                       |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
|                                                                    |
| Press F2 for BIOS setup, Press F12 for the startup menu.           |
+--------------------------------------------------------------------+

This screen is produced by software that is often called BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface). We refer to this type of software as boot software.

The goal of this software is to initialize the hardware of the computer and load an operating system (like GNU/Linux, Windows, or macOS). GNU Boot can replaces this software on some computers.

Like all software, this boot software has to be stored somewhere.

Unlike the operating system which is typically stored on data storage devices people are familiar with (like SSD (Solid State Drive) or a hard disks, USB keys, etc), the boot software is stored on a very different kind of data storage device.

It is stored inside a chip that is inside the computer mainboard. People and technical documentation often call this chip the boot flash because it is stores the boot software, and also because it is a flash chip which is a chip that stores data and that is built with a semiconductor technology called flash (see the Wikipedia article on flash memory for more details on the technology).

Here is a picture of this boot flash on the mainboard of a ThinkPad X200:

Boot software (like BIOS (Basic Input/Output System), UEFI (Unified Extensible Firmware Interface) or GNU Boot) exist for a variety of technical reasons:

• The operating systems require certain hardware components like the RAM (Random Access Memory) to already work when they are started.
• The operating system is stored on a storage device(s) (like SSD (Solid State Drive), hard disks, etc) and part of it needs to be loaded inside the RAM (Random Access Memory) to work. Something has to do the loading, and this is done in software for flexibility and/or efficiency reasons.
• Finally, certain hardware components cannot be auto-detected and something needs to tell the operating system what drivers to load, which which settings.

GNU Boot provides such software. It enables to replace nonfree boot software (typically nonfree BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface)) on some computers.

1.1.2 distribution

GNU Boot a distribution of boot software: like GNU/Linux distributions (like Trisquel), it reuses various software to produce something that can be installed.

However the scope of GNU Boot is more limited than GNU/Linux distributions as it only reuses boot software like Coreboot or GRUB to produce something that replaces nonfree BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface).

1.3.1 How much free software is GNU Boot?

Being a GNU package, GNU Boot itself has to be 100% free software.

If you find nonfree software in GNU Boot and/or any source code or binaries released by GNU Boot, please contact its maintainers by opening a bug report on its bug tracker at https://savannah.gnu.org/bugs/?group=gnuboot.

But that doesn’t mean that GNU Boot magically makes everything not provided by GNU Boot free software. For instance if you install a nonfree operating system, GNU Boot will try to run it.

In some cases GNU Boot even runs nonfree software not provided by GNU Boot like nonfree GPUs drivers provided by the removable GPU card. See Supported computer parts and peripherals for more details about this issue and how to avoid running such nonfree software.

To address problems like that the Free Software Foundation has created the Respect Your Freedom hardware certification to list hardware that works with only free software (with some very small exceptions for some components, see its criteria for more details).

In addition there is also The Blob Fallacy article or a video of a presentation about the same issue at LibrePlanet 2024 by Alexandre Oliva that explains the related freedom issues with nonfree software provided by the hardware and how they compare with other kind of freedom issues (nonfree driver, nonfree firmware loaded automatically by Linux, etc).

If we dig deeper, hardware supported by GNU Boot is also affected by additional issues. They are less problematic than the rest as the Respect Your Freedom hardware certification makes exception for these until we get free software replacements.

All the (mass) storage devices (Hard disks, SSD (Solid State Drive), USB keys, SD cards, etc) have a builtin nonfree firmware. It is possible to avoid trusting these nonfree firmware by encrypting everything that is on these devices. How to do that will need to be added later on in this manual.

In the case of laptops, there is however something more problematic for which we have no solution yet. The computers have a builtin nonfree firmware which handle the keyboard (which is extremely problematic), and various tasks related to power management (seting up the right voltages at boot, managing the battery, cutting power to the WiFi, the power management beeps, etc).

In that case the way to go would be to find a way to make sure that people do work on addressing the issue by writing a free firmware to replace the nonfree firmware, and by finding a way to upgrade the nonfree firmware to a free one.

The Free Hardware and Free Hardware Designs also has good background on these topics as in some case hardware and firmware is indistinguishable, and so this also has consequences on freedom and/or on how to recognize the most problematic issues, which in turn is a useful tool for organizing the free software movement at large.

1.3.2 Limitations

GNU Boot is fairly recent and doesn’t have an official release yet.

For the release we plan to have at least some install and upgrade instructions for some computers and an easy way for users to use GNU Boot.

Also the latest GNU Boot release candidate was not tested yet with all the computers it’s supposed to support (we badly need help for that).

1.4.1 GNU boot and GNU Guix

The GNU Guix package manager (which GNU Boot also reuses) also provide 100% free boot software for some ARM computers. However the Guix packages are updated all the time and the Guix project doesn’t provide any way for users to report that specific ARM computers work fine with the boot software they provide.

1.4.2 GNU boot and Canoeboot

There is also Canoeboot which is a 100% free software boot distribution similar to GNU Boot. Its goal is to remove nonfree software from Libreboot.

The main difference between both is that GNU Boot has a longer term focus.

This has some wide reaching consequences that affect many areas. Because of that, the next subsubsection will give a few practical examples to show this in practice rather than trying to be exaustive.

Also note that the GNU Boot maintainers don’t know Canoeboot well enough as this would require them to spend a lot of time studying its documentation, source code an testing it and/or using it, to get first hand knowledge about it, to really evaluate the impact of Canoeboot choices and compare them to GNU Boot.

So instead, the GNU Boot maintainers relied on a mix of discussion with Leah Rowe, the Canoeboot maintainer, and their own research, to get information about Canoeboot.

• GNU boot and Canoeboot: features
• GNU boot and Canoeboot: fixes
• GNU boot and Canoeboot: dependence on upstream

1.4.3 How much free software are other distributions

Apart from Parabola for ARM computers that only officially support computers that can boot with free software, all other distributions, which also includes Parabola for x86 computers also support computers that boot with nonfree software: these computers come with nonfree software pre-installed and these distributions reuse that software to boot.

So the fact that a computer is supported by these distributions does not indicate that the computer can boot with fully free software.

Here are some examples for the GNU/Linux distributions. They all provide packages that only work with nonfree software that is already on the computer.

As for Canoeboot, since June 2025, it also supports computers that boot with nonfree software. This nonfree software runs in a separate computer within Intel computers that is called Management Engine.

On supported computers, this nonfree software, has access to the network and can take full control of the computer at any time (even once booted or when the computer seems to be powered off). This is even advertised by the Intel (the CPU manufacturer) as a feature to more easily control computers remotely.

See the The Intel Management Engine: an attack on computer users’ freedom article has more information on this issue.

To limit the damage, Canoeboot kindly asks this nonfree software to not run the most problematic part of code (this includes the code that is responsible for the remote control) but also doesn’t remove any of this code. Since this operating system is nonfree it is hard to really understand the impact of doing that.

You may also be able to completely remove the most problematic part of this code yourself with me_cleaner, but it is not possible to remove all of this nonfree code (otherwise Canoeboot would have done that). Here too it is hard to really understand the impact of running the remaining nonfree code to boot the computer.

Really understanding the impact is extremely complex or impossible, basically because the code is nonfree.

If need more details, there is some documentation on what these settings are supposed to do, like the Disabling Intel ME 11 via undocumented mode article by Positive Technologies, or the source code, documentation, bug reports and contributions of the me_cleaner project. All that shows that some nonfree code still run at boot, and all the affected computers don’t necessarily run the exact same nonfree code, and research often analyze specific versions of this nonfree code, and not necessarily the code that you might be running if you use such computers with Canoeboot. In addition research tend to analyze specific part of the code only and not everything.

Because of that, really knowing the danger of running the nonfree software code that is required to boot the computer is almost impossible, because even if you do a lot of research yourself, this would still need to be somehow reviewed by peers to get a bit more assurance it doesn’t contain huge mistakes.

So given the capabilities that kind of hardware and software has, it is a good idea to be extra cautious. So it would be best to avoid relying on computers with such issues if you can.

Note that this issue is not limited to Intel, as recent CPU made by AMD also have somewhat similar issues. Most smartphones also have a similar issues, and even some ARM computers like the Raspberry PI also have a similar issue. See the What’s wrong with the Raspberry Pi for more details on the Raspberry Pi.

2.1.1 Refurbished and/or modified computers

Note that, while they are very similar, a Lenovo ThinkPad X200 is not the same thing than a Technoethical X200. This is because vendors like Technoethical, Vikings, and others sometime modify the hardware and/or software of the computers they sell. Note that some of these vendors sold different computer models and not just the X200.

At least one of these vendor (Minifree Ltd) is known to have increased the boot flash size, and multiple vendors are also known to have modified the boot software images they shipped to make sure that the builtin Ethernet controller hardware address (also known as MAC address (Medium Access Control address)) was the same than on the sticker below the computer.

Since these modifications are useful but that they can have impacts in multiple areas (installation or repair instructions, flash chip programmer compatibility, etc), we chose to take into account these differences to best support these potentially modified computers, and the way we did it is by considering the Lenovo ThinkPad X200 and the Technoethical X200 to be two distinct computers.

Because of that we also need help from the vendors and/or users of these modified computers to tell us or help us find what was modified on these computers, to better support them.

2.1.2 Experimental support for some computers

The support for the following computers is experimental:

• Asus KCMA-D8
• Asus KFSN4-DRE
• Asus KGPE-D16
• Technoethical D16
• Vikings ASUS KCMA D8 mainboard and workstation
• Vikings ASUS KGPE D16 mainboard

If you don’t have any of these computers, you can simply skip this subsection.

All of these computers use similar chips. Their future is uncertain because of several issues:

• They are no longer supported by Coreboot. This makes it difficult continue supporting it over time. In practice they uses an older Coreboot version and the code doesn’t build on distributions like Parabola because of that. For now the code can still be built on Trisquel 11 (aramo).
• The code that initialize the RAM works accidentally and it is not reliable. In practice this means that the compatibility RAM modules is very difficult to know in advance. For instance going up to the maximum amount of RAM (like 256 GiB of RAM on a KGPE-D16) only works with very specific RAM modules.

  Which modules work and can still be bought at regular prices are also kept secret to prevent companies from buying them all and increasing the prices.

  In addition sometimes rebooting don’t work, and powering the mainboard does not always work (sometimes we need to try several times for that to work). Weather that works or not can also be dependent on the room temperature. In addition once running the computer for very long period of time can result in a crash at some point, which requires rebooting it.

Despite all that, some organizations like the FSF, GNU or Libre en Communs manage to run infrastructure with computers that have these issues. But this requires specific know how or workarounds.

For instance if you want to use these computers as remote servers, you will need to know how to build a system that can reboot the computer remotely even if it is crashed, and also make sure that the system you build doesn’t depend on nonfree software.

In contrast, such knowledge is not required for running GNU Boot on well supported computers like a ThinkPad X200, even if they are used as servers.

Despite all these issues, these computer that are affected by such issues are still (badly) supported by GNU Boot because of historic reasons: in November 2022, Libreboot began to include non-libre code, and because of that GNU Boot was created to continue providing a fully free boot distribution with the same spirit of former Libreboot releases.

Since Libreboot already supported this computer and that people and organization do use them, including key contributors to GNU Boot, it made sense and still makes sense to support these mainboard.

For instance the GNU Boot build server runs on a VM (virtual machine) provided by Libre en Communs which runs on a KGPE-D16 with GNU Boot, and the KGPE-D16 is affected by these issues.

And neox is also involved in running all that on the Libre En Communs side so not supporting that mainboard in GNU Boot would also means that neox would have less time for GNU Boot due to the duplication of work.

All the above makes it really important to fix these issue once for good, and several things can be done to really do that:

• neox reverse engineered the RAM controller hardware of the KGPE-D16 and wrote an academic paper on it that will be published under a free license. People with related skills can help by requesting a copy to neox and reviewing it.
• another way to help is to find people that have the skills and the time to write a proper RAM initialization code and bring back this mainboard in Coreboot. GNU Boot may be able to get funding for that.

In addition fixing these issue will also enable to have RAM initialization code that we have the full control of: most computers out there put unknown values in the RAM controller and have algorithms to then tune the RAM settings until something acceptable is reached.

But the goal of neox’s paper is to really document the hardware, to enable to write extremely reliable initialization code. This can also open the door for other optimizations to improve performance, reliability (make it work with a bigger temperature range), security, etc.

These optimizations are not possible for all the other computers supported by GNU Boot, as it would require to do the same kind of work neox did to also reverse engineer the RAM controller of these other computers.

2.1.3 Asus KGPE-D16 (experimental)

Here are some details on this computer:

This computer can have 32 cores and 256 GiB of RAM, so it is the most powerful x86 computer that can boot with free software. More x86 recent computers require nonfree software to boot.

It also exist more powerful computers that can boot with free software, but the support for fully free distribution is either experimental or non-existent depending on the computer. In addition these more powerful computers are much more expensive, limiting their reach to organizations or individuals with enough money to buy them (some people in the free software community have such computers, but not a lot of people).

The support for this computer is experimental. See Experimental support for some computers for what it means.

• Asus KGPE-D16: How to build a computer with this mainboard.

2.1.4 Lenovo ThinkPad X60

Here are some details on this computer:

• Lenovo ThinkPad X60 builtin card reader

2.1.5 Lenovo ThinkPad X60s

Here are some details on this computer:

• Lenovo ThinkPad X60s builtin card reader

2.1.6 Lenovo ThinkPad X60T

Here are some details on this computer:

• Lenovo ThinkPad X60T builtin card reader

2.1.7 Lenovo ThinkPad X200

Here are some details on this computer:

• Lenovo ThinkPad X200 builtin boot flash
• Lenovo ThinkPad X200 builtin CPU
• Lenovo ThinkPad X200 builtin card reader

2.1.8 Lenovo ThinkPad X200s

Here are some details on this computer:

• Lenovo ThinkPad X200s builtin card reader

2.1.9 Lenovo ThinkPad X200T

Here are some details on this computer:

• Lenovo ThinkPad X200T builtin card reader

2.1.10 Libiquity Taurinus X200

Here are some details on this computer:

• Taurinus X200 builtin card reader

2.1.11 Technoethical X200

Here are some details on this computer:

• Technoethical X200 builtin card reader

2.1.12 Technoethical X200s

Here are some details on this computer:

• Technoethical X200s builtin card reader

2.1.13 Technoethical X200 Tablet (X200T)

Here are some details on this computer:

• Technoethical X200T builtin card reader

2.1.14 Vikings X200

Here are some details on this computer:

• Vikings X200 builtin card reader

2.2.1 PCI and PCIe cards with software

Some PCI or PCI express cards stores software (typically on a flash chip) that is meant to run by the boot software (typically a BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface)).

When using GNU Boot SeaBIOS images, GNU Boot will run that software reguardless of if it’s free or not. Most of the time this software is nonfree. The GNU Boot GRUB images won’t run this software at all, so this is also one of the reasons why SeaBIOS images are reserved for more advanced users. See GNU Boot images types on the various images available.

What this software does depends a lot on the card: GPUs typically contain a BIOS driver that enable to see something on the screen during boot, network cards contain code to use the card to boot the computer from the network, etc.

Sometimes this software is not useful. For instance if you don’t intend to boot from the network, you don’t need to run that code.

And sometimes the functionality provided by this code can even be very dangerous to use. For instance some SATA controllers contain code that can format disks with some vendor-specific format, but if you use that, since code is nonfree, if the card breaks, you end up not being able to read the data on your disks anymore unless the disk format is reimplemented with free software somehow.

Things are not always bad though, as this software can sometimes be replaced with free software like with iPXE or SGABIOS.

Beside doing that there are several ways of avoiding to run that software:

• You can simply use GNU Boot GRUB images and not use GNU Boot SeaBIOS images. This will avoid running such software completely. This is the simpliest solution and it also gives the strongest guarantees as users can’t accidentally run such software.
• You can get computers without PCI /PCIe cards that have builtin nonfree software. All the hardware listed in the Respect Your Freedom hardware certification website should be okay. Another way would be to check the cards yourself, but a tutorial on how to do that needs to be written.
• You can backup and erase the nonfree software present in these cards with flashprog or flashrom. This could be risky to do and it may require to connect a flash chip programmer to these cards and even disassemble them in some cases because flashprog or flashrom only enable to reprogram very few cards from the computer they are connected in. Here we also lack a tutorial on how to do that.
• You can modify the GNU Boot SeaBIOS images to tell it not to run this software. The Free Software Foundation tech team has a wiki. In the disable option roms with cbfstool article, they explains how to do that.

2.2.2 Supported GPUs and graphics

GNU Boot supports the GPUs that are present in the various laptops it supports with 100% free software. Some consideration apply while booting (see GNU Boot images for more details), but so far once booted these GPU are known to works well on tested computers.

In addition for the non-laptop computers, it also supports the builtin AST graphics in the KGPE-D16 and KCMA-D8 with 100% free software, but this also comes with some limitations: in GNU/Linux it’s only possible to display text but not images, so it’s limited to console applications.

In the case of PCIe GPU / graphics cards, we don’t know yet if it is possible to use them without running nonfree software.

If AMD, ATI, and Nvidia cards work under GNU Boot, it’s because GNU Boot loaded and run the nonfree video BIOS that is present on the card.

It’s possible to prevent the nonfree video BIOS from running and you can easily confirm that as the display will not work until the Linux driver is loaded.

The Free Software Foundation tech team has a wiki. In the disable option roms with cbfstool article, they explains how to do that.

And in the graphics cards article they also explain which GPU they tested.

However the Linux driver can also run nonfree software: All the current AMD, ATI, and Nvidia drivers have code to load and run (a different) initialization code provided on the card. For ATI and AMD cards the code that Linux runs is called AtomBIOS.

We don’t know yet if there are cases where this code is not run (this would need to be tested by doing very simple modifications to the drivers, and the GNU Boot project also welcome help in this area).

2.2.3 Supported external card readers

GNU Boot supports some USB card readers that are viewed as mass-storage. With all that you can boot on an SD card a microSD card and it will be viewed like a mass storage USB key.

see Supported computers, inside each computer subsection to see which computers’s internal card readers are supported.

2.2.4 Supported serial ports

While the serial ports are not enabled in the default GNU Boot images, GNU Boot also build debug images with the serial port enabled.

So far only the following computers have debug images with the serial port enabled:

• Asus KGPE-D16
• Lenovo ThinkPad T400
• Lenovo ThinkPad T400S
• Qemu PC (i440FX)
• Technoethical T400
• Technoethical T400s
• Vikings ASUS KGPE D16 mainboard

If you have a computer supported by GNU Boot that isn’t in the list above, and that you are able to test and recover from non-working images (see Practical freedoms with flash programmers for more details), you can ask the GNU Boot maintainers to add a debug image for your computer, and once you tested it we could update the list above.

To get the logs you can for instance get an USB<->serial adapter and a Null modem cable or adapter and after installing the picocom package, you can most of the time use the following command to get the logs:

picocom -b 115200 /dev/ttyUSB0

For USB<->Serial adapters, the serial port will most of the time be on /dev/ttyUSB0, but it can change in some configuration (when there are multiple serial ports, or with some adapters).

2.2.5 Unsupported hardware supported by projects reused by GNU Boot

The following hardware components are supported by software reused by GNU Boot, but support for them hasn’t been enabled yet in GNU Boot:

• Software RAID cards: Some Silicon Image SIL3114 software RAID cards are supported by Coreboot but not enabled in GNU Boot.
• Network interfaces. Projects like iPXE has drivers for many network cards and even some Wifi cards typically used with the computers supported by GNU Boot and free distributions.

The GNU Boot project needs help to evaluate the impact of enabling these and welcome contributions in this area.

2.3.1 GNU/Linux

While GNU Boot should be able to boot almost any GNU/Linux distribution, but in some cases some configuration might be needed by the GNU Boot user. The cases that do and don’t require configuration from the user will be documented in GNU Boot images below.

Even if some cases require some configuration, GNU Boot makes sure to provide at least one way to boot free GNU/Linux distributions (see https://www.gnu.org/distros/ for more information on these distributions) without the need to configure anything in order to make it possible for less technical users to use computers with GNU Boot, and even reinstall the GNU/Linux distribution without needing to do anything too complicated.

To make that possible, the GNU Boot contributors that proposes improvements to the project typically test GNU Boot with free distributions, and the GNU Boot project even runs automatic tests with Trisquel 11 (aramo), one of the free distributions to make sure that it can boot fine without needing any special configuration from the user.

• Non-standard GNU/Linux configurations
• Nonfree distributions

2.3.2 Other operating systems

As for other operating systems, there is some documentation on how to boot some of them (like some BSD operating systems) on the GNU Boot website, but again we need help from voulonteers already running such systems to keep the documentation up to date and inform us of what works and doesn’t work.

Also if you want to do such tests, you can open a bug report on the GNU Boot bug tracker at https://savannah.gnu.org/bugs/?group=gnuboot.

2.4.1 GNU Boot images naming

Images for specific computers can be found on the GNU Boot download area or in the release/roms directory if you built GNU Boot from source yourself.

For a given release (or release candidate) like GNU Boot 0.1-rc3, you can find such files inside the ’roms’ directory like https://ftp.gnu.org/gnu/gnuboot/gnuboot-0.1-rc3/roms/ for GNU Boot 0.1-rc3.

Inside you have archive files like gnuboot-0.1-rc3_x200_8mb.tar.xz that are specific to a specific computer (here the ThinkPad X200 with 8MiB boot flash).

see Installing or upgrading GNU Boot images to understand how to identify which archive file correspond to which computer.

Inside each archive files, there are many smaller files that are flash images. See boot software to understand what a flash image is.

The flash image files correspond to the configurations described in the GNU Boot images types.

So for instance if we have an image named grub_x200_8mb_corebootfb_usqwerty.rom, it is meant for a ThinkPad X200 with 8MiB boot flash, and it uses the GRUB software to boot, and it is configured to use a QWERTY keyboard layout.

If the image contains seabios in its file name instead of grub, it uses the SeaBIOS software to boot.

The corebootfb in the file name correspond to the high resolution graphics described in the previous subsection (GNU Boot images types).

If instead the file has txtmode in its name, this corresponds to the text-only low resolution that was also described in the previous subsection (GNU Boot images types).

2.4.2 GNU Boot images types

For a given computer, GNU Boot provides several images with different software in it. This enable the users to choose between:

• Two boot software: GRUB or SeaBIOS (BIOS (Basic Input/Output System) implementation)
• Various keyboard layouts (colemak, deqwertz, esqwerty, frazerty, frdvbepo, itqwerty, svenska, trqwerty, ukdvorak, ukqwerty, usdvorak, usqwerty).
• Low resolution or high resolution graphics.

If you are a less technical user or helping one, or don’t have much time to configure things, it is a good idea to choose an image with GRUB, and a keyboard layout of your choice (the resolution is not very important, but using high resolution looks nicer) as the image with GRUB doesn’t require to do any configuration in the distributions you want to boot.

Otherwise here are the advantages/disadvantages of each combinaison:

• GRUB with high resolution graphics: Images with GRUB usually don’t require the user to do any configuration of the distribution. More technical users can also use that to customize the way the system boots for more security or to support unsual boot configurations (that are not typically supported by graphical installers of GNU/Linux distributions), however these more advanced configurations also come with their set of limitations.
• SeaBIOS with text-only low resolution: It implements BIOS (Basic Input/Output System) compatibility, so it is very similar to a nonfree BIOS (Basic Input/Output System) but it require users to modify some settings inside the distribution they use, otherwise the distribution still boots but usually has a black screen during the boot (which can be problematic to diagnose a non-booting distribution). The low resolution increase compatibility with various software that are typically run at boot like memtest86+ (a software that detects broken RAM chips).
• GRUB with text-only low resolution: Since these images boot with GRUB, they also don’t require any configuration of the distribution and more technical users can also use them to customize the way the system boots. Compared to GRUB images with high resolution graphics:
  • the text is bigger and that there is no background picture
  • since on most supported computers, GRUB images can also load and run SeaBIOS (there is a menu entry for it), having a text-only low resolution increase the compatibility with various boot software.
• SeaBIOS with high resolution graphics:

  Since these images boot with SeaBIOS they also implement some BIOS (Basic Input/Output System) compatibility, but they also require users to modify some settings inside the distribution they use. Compared with SeaBIOS images with text-only low resolution:

  • they are less compatible with various boot software. This can be useful for testing if you contribute to some boot software.
  • since on most supported computers, SeaBIOS images can also load and run GRUB (there is a menu entry for it when pressing the ’ESC’ key at boot), having high resolution graphics can make GRUB look nicer.

2.5.1 SeaBIOS: Supported filesystems and partitions

SeaBIOS images don’t need to support any filesystems because SeaBIOS is a BIOS interface implementation and BIOSes don’t need to support any filesystem to load an operating system.

It supports the MBR (Master boot record) partition table.

If you use GPT (GUID Partition Table) instead, it may be possible to boot from a BIOS Boot partition instead, but it is untested. Please do report if this works for you.

Wikipedia has more information on why in its Master boot record and BIOS Boot partition articles.

2.5.2 SeaBIOS: Supported bootloaders

• SeaBIOS: GRUB (on MBR or BIOS boot partition)

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux-Libre (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

sudo sed 's/#GRUB_TERMINAL=console/GRUB_TERMINAL=console/' -i /etc/default/grub

grep '^GRUB_TERMINAL=console$' /etc/default/grub

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

sudo sed 's/#GRUB_TERMINAL_OUTPUT=console/GRUB_TERMINAL_OUTPUT=console/' \
-i /etc/default/grub

grep '^GRUB_TERMINAL_OUTPUT=console$' /etc/default/grub

sudo grub-mkconfig -o /boot/grub/grub.cfg

(bootloader (bootloader-configuration
             (bootloader grub-bootloader)
             (targets '(file-system-label "Guix_image"))
             (terminal-outputs '(console))))

sudo guix system reconfigure /etc/config.scm

SeaBIOS (version rel-1.14.0-27-g64f37cc5)


Press ESC for boot menu.

Booting from Hard Disk...

               GNU GRUB  version 2.12
+--------------------------------------------------+
|*Trisquel GNU/Linux                               |
| Advanced options for Trisquel GNU/Linux          |
| Trisquel GNU/Linux 11.0.1, Aramo (11.0.1) (on /d→|
| Advanced options for Trisquel GNU/Linux 11.0.1, →|
+--------------------------------------------------+
      Use the ↑ and ↓ keys to select which
      entry is highlighted.
      Press enter to boot the selected OS, `e'
      to edit the commands before booting or
      `c' for a command-line.

2.6.1 GRUB: Supported configuration files

• grub.cfg

2.6.2 GRUB: Supported partitions

• GRUB: GPT (GUID Partition Table) and MBR (Master boot record)
• GRUB: LVM2
• GRUB: GNU/Linux RAID
• GRUB: RAID formats of RAID card vendors
• other partition types

3.4.1 Wire length

If the length of the wires connecting the programmer to the chip is too long, then there will be signal integrity issues and flashprog or flashrom might not find the boot flash at all.

If that happens, the best fix is to use shorter wires. It is also sometimes possible to workaround by lowering the speed at which the programmer talks to the boot flash.

3.4.2 Programmer SPI speed

On some flash chip programmers, the speed at which it access the flash chip can be configured. In this case using the lowest speed possible can sometimes make a given flash programmer work when there are signal integrity issues (for instance when the wires connecting the programmer to the boot flash are too long). How to do that is documented in the flashrom and flashprog manuals, inside the programmer sections. Such options have names like spispeed, or divisor, depending on the programmer being used.

Note that some programmers don’t have the ability to lower their speed.

3.4.3 Lenovo ThinkPad X200 with the MX25L6405D (8MiB)

For some reasons the signal integrity is bad with the MX25L6405D (8MiB) boot flash on the Lenovo ThinkPad X200. Because of that it is advised to have the shortest cables possibles (see Wire length for more details) but also to check the compatibility of various flash programmers with this boot flash on this laptop. On programmers that are known to work, you might still need to lower the SPI speed (see Programmer SPI speed for more details) to be able to detect, read or write the boot flash.

3.5.1 OpenMoko Neo1973 Debug board (V2+)

The Neo1973 Debug board (V2+) from OpenMoko can be used but it will require to solder some pin headers on the programmer itself.

If you want to use this programmer to reprogram a laptop boot flash, you will need to get Female/Female Jumper Wires and a test clip corresponding to your boot flash (like the Pomona 5252 test clip for SOIC-16 or the Pomona 5250 test clip for SOIC-8).

If instead you want to reprogram a DIP-8 boot flash, you will need to get Female/Female Jumper Wires, some PIN headers and a breadboard.

3.5.2 Vikings CH341a USB Programmer

The CH341a USB Programmer from Vikings can be used without having to solder anything.

If you want to use this programmer to reprogram a laptop boot flash, you will need to get Female/Female Jumper Wires (like the "Jumper Wire F/F, 20pcs" from Vikings) and a test clip corresponding to your flash chip (like the "Pomona 5252 IC TEST CLIP SOIC 16 (2 X 8)" or "Pomona 5250 IC TEST CLIP SOIC 8 (2 X 4)" from Vikings).

If instead you want to reprogram a DIP-8 boot flash, nothing special is needed as this programmer has a builtin socket for them.

3.5.3 Zerocat Chipflasher v2 and its variations

The Chipflasher v2 is shipped with a builtin free firmware that is compatible with flashrom and that can be replaced: Zerocat provides documentation that explains you how to do that and alternative firmwares do exist.

Zerocat also provides documentation that seems sufficient to build a Chipflasher yourself and they even sells kits, though we didn’t test building one ourselves.

The builtin free firmware is capable of controlling various hardware components to adapt to a wide variety of electrical / electronic conditions typically found when programming laptops boot flash.

Building your own slightly different version the Chipflasher and/or installing another firmware that is completely different has real impacts on both the compatibility with laptops boot flash and the way of using the Chipflasher.

All these differences can be useful, otherwise the Chipflasher v2 official documentation on the Zerocat website or the chipflasher git repository would not document all these in depth.

In order to support well the Zerocat Chipflasher v2 and potentially its various variations as well, we chose to take into account these differences by considering Zerocat Chipflasher v2 with hardware and software variations as flash programmers distinct from the Zerocat Chipflasher v2.

So for instance a Zerocat Chipflasher v2 without any builtin firmware, with a different firmware than the one that came with the Chipflasher v2 (like kick2-connect instead of kick2-flashrom), or a Zerocat Chipflasher DevKit (for instance that you built yourself) will be considered as distinct flash programmers.

• Zerocat Chipflasher v2
• Zerocat Chipflasher v2 without builtin firmware

5.1.1 Quick test with QEMU

If you just want to try an image to see how it looks like, after installing QEMU, you can use the following command:

qemu-system-i386 -M pc \
-bios grub_qemu-pc_2mb_corebootfb_usqwerty.rom

Here you need to replace grub_qemu-pc_2mb_corebootfb_usqwerty.rom by the path to the image you want to try.

If you don’t have qemu-system-i386 you can either ask users of your distribution for help, to understand which package you need to install, or use qemu-system-x86_64 instead.

Alternatively, the qemu package from Guix also provides both (qemu-system-i386 and qemu-system-x86_64).

5.1.2 Booting a distribution with QEMU

In the previous section (Quick test with QEMU) we didn’t boot a distribution.

To boot an x86 32bit distribution, you can use the following (QEMU) command:

qemu-system-i386 \
-bios grub_qemu-pc_2mb_corebootfb_usqwerty.rom \
-M pc \
-m 128M \
-cpu kvm32 \
-enable-kvm \
-blockdev \
'{"driver":"file","filename":"rootfs-i686.img","node-name":"libvirt-1-storage"}' \
-blockdev \
'{"node-name":"libvirt-1-format","driver":"raw","file":"libvirt-1-storage"}' \
-device \
'{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.0","addr":"0x4"}' \
-device \
'{"driver":"ahci","id":"sata0","bus":"pci.0","addr":"0x5"}' \
-device \
'{"driver":"ide-hd","bus":"sata0.0","drive":"libvirt-1-format","id":"sata0-0-0"}'

If it fails with the following error:

qemu-system-i386: failed to initialize kvm: Permission denied

You can fix that by removing the -enable-kvm from the command above. It will always work but it will make booting the virtual machine slower.

Alternatively, you can try to fix this by adding the proper permissions to /dev/kvm. To do that you can either consult your distribution documentation / wiki or ask other users of that distribution for help. Also, this will only work if your processor supports KVM (most computer do).

In addition, for the command to work you will also need to provide the rootfs-i686.img file (otherwise it will fail with Could not open ’rootfs-i686.img’: No such file or directory).

If you don’t know how to do that, you can install Guix first (it can be installed on top of another GNU/Linux distribution) and generate it with Guix.

You can consult either the GNU Boot build instructions or the Installation in GNU Guix reference manual for how to install Guix.

Then for distributions (like PureOS or Trisquel) that provide Guix versions older than 1.4.0, or if you don’t know the Guix version you have, you will need to update Guix with the following commands:

guix pull

It could take a long time though (maybe 1 hour or more depending on the speed of the computer and network).

Then make sure you are using the latest Guix with the following command (this needs to be done each time you use a new shell and want to use the latest Guix when Guix is installed on top of another distribution):

hash guix

Then you can copy the following inside the guix-i686-linux.scm file:

;;; This file is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; This file is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with this file.  If not, see <http://www.gnu.org/licenses/>.
(use-modules (gnu) (gnu bootloader) (gnu packages linux))
(operating-system
  (host-name "guix-i686-linux")
  (kernel linux-libre-lts)
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)
               (targets '(file-system-label "Guix_image"))
               (terminal-outputs '(console))))
  (file-systems (append (list (file-system
                                (device (file-system-label "Guix_image"))
                                (mount-point "/")
                                (type "ext4")))
                        %base-file-systems)))

And finally you can generate the rootfs-i686.img file with the following command:

install -m 644 \
    "$(guix time-machine \
       --commit=8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 \
       -- \
       system image --system=i686-linux guix-i686-linux.scm)" \
       rootfs-i686.img

This will create the rootfs-i686.img that you need in the current directory.

You can then boot it with the QEMU command we gave before. You should then see this:

This is the GNU system.  Welcome.
guix-i686-linux login: _

You then can login as the root user with no password (by typing root and then pressing the ENTER key), and once done you can shut it down with the shutdown command.

To use this with another distribution or image, you will have to find a way to download or generate the rootfs-i686.img file that contains the distribution that you want to test yourself and adapt the QEMU command accordingly.

See Booting an x86 64bit distribution with QEMU for an example with a different image.

5.1.3 Booting an x86 64bit distribution with QEMU

In the previous subsection (Booting a distribution with QEMU) we booted a 32bit distribution as it works fast on both 32bit and 64bit x86 computers and it uses less RAM.

In this example we need 256 MiB of RAM (It is set in the command below with -m 256M).

So to boot an x86 64bit distribution, you can use the following command:

qemu-system-x86_64 \
-bios grub_qemu-pc_2mb_corebootfb_usqwerty.rom \
-M pc \
-m 256M \
-cpu kvm64 \
-enable-kvm \
-blockdev \
'{"driver":"file","filename":"rootfs-x86_64.img","node-name":"libvirt-1-storage"}' \
-blockdev \
'{"node-name":"libvirt-1-format","driver":"raw","file":"libvirt-1-storage"}' \
-device \
'{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.0","addr":"0x4"}' \
-device \
'{"driver":"ahci","id":"sata0","bus":"pci.0","addr":"0x5"}' \
-device \
'{"driver":"ide-hd","bus":"sata0.0","drive":"libvirt-1-format","id":"sata0-0-0"}'

Here too, if it fails with the following error:

qemu-system-x86_64: failed to initialize kvm: Permission denied

You can also fix that by removing the -enable-kvm from the command above. It will always work but it will make booting the virtual machine slower. see Booting a distribution with QEMU for pointers on how to make -enable-kvm work to not make the virtual machine boot slower.

Here you will need to provide the rootfs-x86_64.img file.

If you don’t know how to do that, like mentionneed in the previous section (Booting a distribution with QEMU), you can install Guix and update it if necessary.

Once done don’t forget to run this command to use the latest Guix:

hash guix

You can then copy the following inside the guix-x86_64-linux.scm file:

;;; This file is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; This file is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with this file.  If not, see <http://www.gnu.org/licenses/>.
(use-modules (gnu) (gnu bootloader) (gnu packages linux))
(operating-system
  (host-name "guix-x86_64-linux")
  (kernel linux-libre)
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)
               (targets '(file-system-label "Guix_image"))
               (terminal-outputs '(console))))
  (file-systems (append (list (file-system
                                (device (file-system-label "Guix_image"))
                                (mount-point "/")
                                (type "ext4")))
                        %base-file-systems)))

And finally you can generate the rootfs-x86_64.img file with the following command:

install -m 644 \
    "$(guix time-machine \
       --commit=8e2f32cee982d42a79e53fc1e9aa7b8ff0514714 \
       -- \
       system image --system=x86_64-linux guix-x86_64-linux.scm)" \
      rootfs-x86_64.img

Once booted, you should then see this:

This is the GNU system.  Welcome.
guix-x86_64-linux login: _

Here too, you can login as the root user with no password (see Booting a distribution with QEMU for more details), and you can also shut it down with the shutdown command.

5.1.4 Booting more distributions with QEMU

6.1.1 Threat modelling or what security really is about

Security is a process. To really make it work you need to understand various threats and if or how to respond to them (this is called threat modelling). This depends on your life, your use cases, etc. It boils down to what is important to you and what is not.

For instance if a Company that makes nonfree software lose money, this is probably problematic for them but it is likely not your problem, and it could even be a good thing, depending on the details.

In contrast, if your computer is stolen, you could lose your data, and the person or entity that stole it may have access to all your files. You also might have a hard time getting another equivalent computer. Here the damage can depend a lot on how you live your life, on who / what entity stole the computer, or even if your computer has access to any important data at all, or if you can actually be in a situation where you can relatively easy get computer.

All these are security threats but they don’t threaten the same people or organisations in the same ways.

In addition, sometimes there are security features like "encryption with LUKS", or "hard disk encryption" that can be promoted, that protects against some known attack (like someone or some entity stealing your laptop to access your data), but not everything in security can be classified as features and even features are part of bigger processes that respond to specific threats.

For instance if you have "hard disk encryption" but that all your data are backed up in some other computers you don’t trust and that you misunderstood the risks of doing that, then this could be really catastrophic.

In addition some things are hard to fit into features. "Good code quality", or "I can trust the people doing this software because I know them well" or "I don’t want to use this software because the people that do it know me personally and I feel unconfortable because of that even if I trust them" are not things that a given software project can easily advertize.

Not everything is technical and sometimes it can boil down to things like "this project is well known, looks serious and Wikipedia also agrees on that", so it looks safer to use than "another project that advertize 100% security" because "according to my friends, 100% security doesn’t exist" or that "the security features of this software create other security issues that affect you more than what it’s supposed to fix".

Also note that in general some security features also have downsides, such as making it harder to use the computer, making it harder to fix issues, etc, so not everybody might want these security features.

For instance "disk encryption" when it is really secure, makes the computer slower when copying very big files, makes recovering from data corruption harder, and you even need to remember a passphrase (that you could forget and so lose access to your data).

Making sure that nobody else gets the passphrase is hard (you need to not be seen, recorded, filmed, etc when you type it, it needs to be random enough and long enough not to be guessed, etc). And finally all that can complicate backups as well depending on if you also want the backups to be encrypted as well or not.

So not everybody wants to encrypt their disk, this is why GNU/Linux installers give users the choice of doing it or not doing it.

Security is also not everything, for instance you might care more if a given software has features that you want, or if it fits you better, or has better long term availability guarantees or better support than a more secure one, etc.

A big part of threat modelling is also, when you have things to protect, to also understand who or what to protect these things from.

For instance a state doesn’t have the same capabilities, goals, or even risk than an individual. So there are things states are willing to do that individuals are not and vice-versa. Attacks can also have costs for the attacker, so that also limit their use to situation where the gain outweighs the costs. But that is only useful if you first understand what is important for you.

6.1.2 Impact of malware

People running 100% free software distributions usually don’t end up with malware on their computers if they apply (security) updates.

But this can happen to other people that run other GNU/Linux distributions with (very) bad luck and bad practices.

If someone that runs GNU/Linux installs random software from places like Aur or Pip that don’t do any checks on the software being provided through them, that software is sometimes malware, though this is quite rare and Aur or Pip typically communicate on such incidents and the specialized press talks about it.

Places like Aur or Pip also provide nonfree software, and this is by design, so people runing 100% free software distributions try to avoid such places anyway.

The consequences of installing malware is quite bad as the computer cannot be trusted anymore and the advertized solution is usually to reinstall completely the GNU/Linux distribution, which is relatively easy to do.

This however brings additional problems that are much more complex to deal with:

• When restoring backups, people need to make sure they don’t contain code that, once restored, will re-infect the computer. Restoring a backup of before the infection should be safe, but sometimes malware take time (months) before being detected. And making sure that backups made after the infection are safe is too complex for most computer users.
• Such advice (reinstalling GNU/Linux) also assumes that the malware didn’t infect the computer firmwares or boot software. Usually there are also many security features in places to make that a lot harder but they don’t always work, especially with software that is installed from untrusted sources when such sources don’t limit what the software can do through security mechanisms.

6.2.1 Secure boot and restricted boot

A very common security feature typically found in other boot software that is part of many computers is called secure boot.

When it cannot be turned off, it becomes an anti-feature and the Free Software Foundation calls it restricted boot.

In 2012, the Free Software Foundation wrote a whitepaper, on the topic and advised that:

The best solution currently available for operating system distributions
includes:
1. fully supporting user-generated keys, including providing tools and full
documentation for booting and installing both modified and official
versions of the distribution using this method;
2. using a GPLv3-covered bootloader to help protect users against the
dangers of Restricted Boot;
3. avoiding requiring or encouraging users to trust Microsoft or any com-
pany which makes proprietary software; and
4. joining the FSF and the broader free software movement in pressuring
computer distributors to facilitate easy and independent installation of
free software operating systems on any computer.

GNU Boot supports various security mechanism: GRUB is a GPLv3-covered bootloader that GNU Boot reuses, and it supports user-generated keys or other security mechanism that that don’t require any signing keys.

GNU Boot also obviously doesn’t Trust keys from companies that make proprietary software.

At the end when used correctly, the security features provided by GNU Boot thanks to the software it reuses (like GRUB) can provide similar or stronger security guarantees than the UEFI secure boot with different security features that you may or may not want want to use depending on your threat model.

The GNU Boot Website contains various information on how to use such security features, but they are also documented in the GNU GRUB manual as well in more details. Since the GRUB version GNU Boot uses might be older than the online GRUB manual, you can use Guix to install the manual of older GRUB versions (see GNU Guix reference manual for more details).

All the security mechanism described in the GRUB manual or GNU Boot website are compatible with users freedom.

6.3.1 Checking the signatures of GNU Boot images

To verify the signatures of an image, you first need to copy the following inside the neox.asc file:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEZm2YmxYJKwYBBAHaRw8BAQdAWDcG3nLKPosKY1A7DABOYkWN3B2Hq4lhrIJx
NnlQVie0KEFkcmllbiAnbmVveCcgQm91cm1hdWx0IDxuZW94QGEtbGVjLm9yZz6I
lgQTFggAPhYhBOI8JqXe7sX6nN3Vele8JqNocRb2BQJmbZzfAhsDBQkDwmcABQsJ
CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEFe8JqNocRb2248BAOIQBGj4/2doph2Q
sfYLyQOzMREaX5P9C2zmDZiaoXBVAQDsh1dvMsLfHpkRdYbRqo6uTU4QTlmL5qOH
Cz2s0QyWC7QmQWRyaWVuICduZW94JyBCb3VybWF1bHQgPG5lb3hAZ251Lm9yZz6I
mQQTFggAQQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBOI8JqXe
7sX6nN3Vele8JqNocRb2BQJmbZzsAhkBAAoJEFe8JqNocRb2D+IA/iYlSD/npaG8
zlDIjjr7XUREFCB6fELSEYR0NKGT+wmGAP0dLdP4xG70anliz+76ik/pndHRZdof
qQKQROEbXe/vCrgzBGZtmJsWCSsGAQQB2kcPAQEHQDZQd7U/DRPK5/qk35dzeG5d
pnS/0FesbRrgZTSMHEsviH4EGBYIACYWIQTiPCal3u7F+pzd1XpXvCajaHEW9gUC
Zm2YmwIbIAUJA8JnAAAKCRBXvCajaHEW9o68AP9VQXiDp5BWXSE6N2rz2+b/Dpck
Ho0MMww2awmBvfU6xgD+OpkDEgo/in+m5PcbOXa8IqDC1fZZbGsLKEfBSiZhawG4
OARmbZibEgorBgEEAZdVAQUBAQdA7nIe/ImvNJ8WZbA+ZcvxrwLbXLwu3XuCPiOc
aIJw9zoDAQgHiH4EGBYIACYWIQTiPCal3u7F+pzd1XpXvCajaHEW9gUCZm2YmwIb
DAUJA8JnAAAKCRBXvCajaHEW9gZBAQDJFP0bkwf3j3YuZROGGEsgwATfohbh8GYB
y35gwjcaigD/fjDVjNnxjpqGFOLvEkSMZgjNpejar69Msf1sRH8tGAg=
=Zqad
-----END PGP PUBLIC KEY BLOCK-----

You will then need to import the key into the GPG keyring. This can be done with the following command:

gpg --import neox.asc

Once done you will be able to verify images signed by neox, one of the two GNU Boot maintainers who until now signed all the releases.

To do that you will first need to download the images and their signature. For QEMU

• gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz
• gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz.sig

wget https://ftp.gnu.org/gnu/gnuboot/gnuboot-0.1-rc6/roms/gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz
wget https://ftp.gnu.org/gnu/gnuboot/gnuboot-0.1-rc6/roms/gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz.sig

gpg --verify gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz.sig

gpg: assuming signed data in 'gnuboot-0.1-rc6_debug_qemu-pc_2mb.tar.xz'
gpg: Signature made Mon 24 Mar 2025 10:54:59 AM CET
gpg:                using EDDSA key E23C26A5DEEEC5FA9CDDD57A57BC26A3687116F6
gpg: Good signature from "Adrien 'neox' Bourmault <neox@gnu.org>" [unknown]
gpg:                 aka "Adrien 'neox' Bourmault <neox@a-lec.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: E23C 26A5 DEEE C5FA 9CDD  D57A 57BC 26A3 6871 16F6

6.4.1 Installing from a computer with a nonfree BIOS

To install GNU Boot on a given computer, you will simply run some software that does the installation for you.

This software will replace the nonfree BIOS that is on the boot flash (See boot software for more information on what is a boot flash).

The main issue with this approach is that the existing BIOS could be malicious and because of that there is no way to know if your computer was already compromised at the time of the installation.

In practice it means that you will need another computer and a flash chip programmer to either check that the GNU Boot image you installed was not modified and/or to simply reinstall GNU Boot.

Once done, you will also need to not boot anymmore your previous GNU/Linux installation and reinstall GNU/Linux as well. See Impact of malware for more details on the difficulties of doing that properly.

6.4.2 Installing from a computer with another boot software distribution

The security consideration here will depend a lot on the exact image you used. If it is fully free and that the computer was never compromised, the same condsideration than Security considerations when updating GNU Boot do apply.

Else it is mostly similar to Installing from a computer with a nonfree BIOS.

See How much free software are other distributions for information on the freedom of various boot software distributions. In addition, if the distribution you use is not listed there it most likely means that it either ships nonfree software and/or that it has no commitment to only include free software.

6.4.3 Installing with a 100% hardware flash chip programmer

To do the installation you will need:

• A computer to install GNU Boot on.
• A 100% hardware flash chip programmer
• Another computer that runs the flashrom program

The setup should look more or less like that:

+------------+        +-------------------+       +---------------------+
| Boot flash | <----> | Flash programmer  | <---> | Flashrom running    |
|            |        |                   |       | on another computer |
|            |        |                   |       |                     |
+------------+        +-------------------+       +---------------------+
 Hardware              Hardware                    Hardware + Software

The previous subsections already explain how to deal with the computer that you are about to install GNU Boot on. For instance they explain the risk with the firmware that controls the keyboard on laptops.

They also explain the risk of running untrusted code reguardless of if it comes from the Boot flash or the operating system that is installed on the laptop.

The flash programmer being only hardware doesn’t need special considerations.

So the main concern here is to make sure that the computer running flashrom is trustworthy.

How to bootstrap this trust will need to be added later on in this manual, but it boils down to adapting what is known as a key ceremony (especially how it was done for Let’s Encrypt) to GNU Boot.

In addition, if the boot flash or operating system of the computer that you install GNU Boot on is compromised, overwriting its content with a new GNU Boot image will get rid of the compromise.

And if the operating system of that computer is also compromised, you will need to first (re)install GNU Boot, and then make sure reinstall the operating system without ever running the code from the previous installation. A way to do that could be to erase the disk on another computer, for instance with the wipe command which comes from the wipe package in Guix.

6.4.4 Installing with a flash chip programmer that has a firmware

Compared to Installing with a 100% hardware flash chip programmer, here we have one more complication: we need to trust the code that runs inside the flash chip programmer.

In the case of the Zerocat Chipflasher v2 (See Zerocat Chipflasher v2 for more details on this flash chip programmer), the builtin firmware is on a flash chip that uses the I2C protocol. This chip can simply be removed and the firmware can be loaded through the serial port instead. If you do that you then are in the same case than Installing with a 100% hardware flash chip programmer which is way more simple.

In other cases, like with a flash chip programmer made with an Arduino, things are more complex.

The frser-duino firmware is free and it can easily be (re)built and installed into an Arduino to make it become a flashrom compatible flash chip programmer. Note that some Arduinos do require level shifter to be able to safely program the boot flash found on the computers supported by GNU Boot.

However if you build a flash chip programmer with an Arduino, you also implicitely trust the bootloader of the Arduino you use. If you don’t want to trust this bootloader, you will either need to completely get rid of the bootloader or build and install one yourself.

Both solutions do require to use an FTDI chip to program the arduino processor directly without needing to run the bootloader code. This is for instance described in the FTDI Breakout with additional ISP connector thread on stackoverflow. On an Arduino duemillanove this requires to solder 1 connector and to use 4 female<->female jump wire cables and to use the avrdude software.

It is also possible to use another Arduino and software to do these, but then it only shift the issue to the other Arduino that also has a bootloader that you might not want to trust.