Group: Hardware/Software/FSDG distributions

Introduction

This page is meant to document what type of hardware FSDG compliant can and/or want to support.

For instance having FSDG compliant distributions that support many architecture is interesting for several reasons:

• To get the RYF certification for a computer, being able to use all the components of that computer with free software is not enough as that computer also needs run an FSDG compliant distribution on that computer. See the RYF endorsement criteria for more details on that certification.
• Users that want fully free system can also build systems similar to the ones that got the RYF certification themselves and/or get some help to do it, and here they also need FSDG compliant distributions to run on their computers.
• As some computers can run fully free software, with some of the hardware components not working, it's also very interesting to be able to have a distribution to support such hardware. See the article on single-board-computers on the FSF website for more details.

So it is very interesting to document that.

It is also interesting to combine that information with information about what type of users is able to use the FSDG distributions. For instance if an architecture is supported only by FSDG compliant distributions that are for technical users with good command line knowledge, it would then dramatically limit the amount of people able to use that computers with that architecture with fully free software.

The release type (Rolling release, stable releases) and the release frequency is also important to take into account:

• For users, there are various advantages and disadvantages of using distributions that have rolling releases or stable releases. Less technical users seem to prefer LTS as less (frequent) maintenance is required.
• For adding support for devices in distributions, rolling releases gets the job done faster, but many users might prefer to use stable releases.

General purpose GNU/Linux distributions

General information

Distribution	Audience	Release type
Dragora	Technical users: Graphical installation No graphical package manager Very few packages	Stable releases Rolling releases are also possible
Guix System	Technical users: Mostly graphical installation The knowledge of the scheme guile programing language is required to administrate the system No integrated graphical package manager yet.	Rolling release
Hyperbola	Everybody? Can the installation be done graphically? It has a graphical package manager (octopi). Is it installed during the graphical installation? Does the user needs to mess up with configuration files?	Stable releases
Parabola	Everybody: The installation can be done graphically A graphical package manager (octopi) is installed during the graphical installation Users typically need to mess up with configuration files only for command line and server software	Rolling releases
PureOS	Everybody: The installation can be done graphically There is a graphical package manager installed during the graphical installation	Stable releases
Trisquel	Everybody: The installation can be done graphically There is a graphical package manager installed during the graphical installation	Stable releases

Architectures support

Distribution or software	ARM 32bit	ARM 64bit	MIPS 64bit little endian	PowerPC 32bit big endian	PowerPC 64bit little endian	Riscv 64bit	x86 32bit	x86 64bit
Dragora	No	No	No	No	No	No	i586	Yes
Guix System	armhf	Yes	Cross compilation only	Cross compilation only	POWER9, experimental	Cross compilation only	i686	Yes
Hyperbola	No	No	No	No	No	No	i686	Yes
Parabola	armv7h	experimental, through armv7h only	No, discontinued	No	Unfinished	Unfinished	i686	Yes
PureOS 10 (byzantium)	No	Yes, can be installed with debootstrap	No	No	No	No	No	Yes
Trisquel 10 (nabia)	armhf	No	No	No	No	No	No	Yes
Trisquel 11 (aramo)	armhf	arm64	No	No	ppc64el	No	i386	amd64

Boot software interfaces support

Many ARM single board computers contains a boot ROM (usually called bootrom) that is small and read-only and that loads the bootloader from an external peripheral like a microSD or the internal memory (like an eMMC for instance). There the bootloader replaces something like GRUB and the BIOS on x86. This situation usually puts the distributions in control as they can ship the bootloaders they want for these computers, so it's up to them to choose the details of how the computer boots (though the downside is that they might need to build and package a bootloader for each devices they want to support).

In contrast, on most x86 computers and on some ARM computers it doesn't work like that. There is a boot software like a BIOS or UEFI on a memory chip that is soldered on the mainboard, and it's a lot more difficult for users to replace that software with free software or to recover from code that doesn't boot.

This makes it interesting to document what boot software interfaces FSDG distributions supports, because if a distribution doesn't support the BIOS interface anymore, then it won't work on computers with that Interface (like laptops with Libreboot and SeaBIOS instead of GRUB).

And even if users have Libreboot and can change the way the computer boots, they are often afraid to try to change how things work by themselves: if something goes wrong, most users don't know how to recover form it (it requires advanced hardware tools like flash programmer, to disassemble the computer, etc).

And in case of computers with nonfree BIOS and UEFI users don't even have the option of changing the way it boots, and can't try to contribute to projects like Libreboot to add more options and get that tested by the community.

Distribution or software	BIOS	Libreboot with GRUB	UEFI 32bit on 32bit CPU	UEFI 32bit on 64bit CPU	UEFI 64bit on 64bit CPU
Dragora
Guix System	Yes.	Possible	Yes	Incomplete	Yes
Hyperbola v0.4.2 (milky-way)	Yes	Yes: supported by Hyperbola	Yes	Difficult	Yes
Parabola	Yes	Supported by Parabola	Difficult	Difficult	Yes
PureOS 10 (byzantium)	Yes		No	Difficult	Yes
Trisquel 10 (etiona)	Yes		No	Difficult	Yes
Trisquel 11 (aramo)	Yes		No	Difficult	Yes

UEFI secure/restricted boot

Some computers vendor sell computers with what they call "secure boot". When it cannot be turned off, it becomes an anti-feature and the FSF calls it "restricted boot".

In 2012, the FSF 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.

And they also pointed to community resources where to report computers with restricted boot:

We will help provide information about which computers and compo-
nents are most compatible with free software, including making people
aware of which machines have Restricted Boot. Much of this informa-
tion will be found at http://h-node.org.

Since the release of Windows 10, Windows 10 certified computer are not required anymore to enable users to disable "secure boot".

At the time of writing, h-node list 23 computers that cannot run free distros for some reasons, but there is no way to explicitly filter for computers with restricted boot. It's also not clear if that list contains one or more computers that use restricted boot.

In case there is no menu to disable restricted boot, some workaround might still exist, for instance if some keys are removed, the computer is expected not to check signatures anymore. There is also free software source code and documentation exist to do that but we don't know if it still requires signed tools to be able to replace the keys in the first place, or if some UEFI can simply allow users to replace the keys easily in their menu. Better documentation is needed.

Finally distributions could also for instance try to ship a set of public and private keys in packages (and ideally use the same keys in all distributions to be able to boot all of them), and provide installation instructions or configuration to use these keys to disable the boot security and enable users and contributors to not have to deal with complicated configuration and handling of security keys or not be able to run modified bootloaders. Since the distributions typically enforce some restriction when secure boot is on the signed programs could also report secure boot as off to avoid the distribution automatically enforcing these extra restrictions.

Distribution or software	Booting with secure boot disabled	Avoiding trusting Microsoft key	Full support for user-generated keys
Dragora	Yes	Yes	No documentation
Guix System	Yes	Yes	No documentation
Hyperbola v0.4.2 (milky-way)	Yes	Yes
Parabola	Yes	Yes	No documentation
PureOS 10 (byzantium)	Yes	No	No documentation
Trisquel 10 (nabia)	Yes	Yes
Trisquel 11 (aramo)	Yes	Yes

Alternatives to UEFI secure/restricted boot

There are other ways to implement secure boot than the way it's done in UEFI. For instance:

• With Libreboot+GRUB or Coreboot (which may include nonfree software) + GRUB, we can set a password in GRUB. If we add some seals (for instance with nail polish) to know if the computer was disassembled, we can get better security guarantees than with UEFI secure boot.
• With Libreboot+GRUB / Coreboot+GRUB we can check gpg signatures. So it is possible to use that to check the signature of a kernel and initramfs, and that is much more simple to integrate in GNU/Linux distributions than UEFI secure boot, as doing that is just a matter of configuration. There is even a tutorial that was tested with older versions of Trisquel.
• On Puri.sm computers, PureBoot is a way to check if the boot has been tempered with while still leaving users in control. It has been widely tested with PureOS. Though in practice it still somehow depends on nonfree software since part of it is implemented in the boot software which uses some nonfree software (Intel FSP, a stripped down Management engine firmware), to make the computer boot.

Partitioning

These factors have an impact on how it is possible to boot a given computer:

• The CPU architecture or the specific computer
• The partitioning scheme, if LVM or LUKS are used, etc
• The distribution

For instance if you have an ARM 64bit computer with Guix, you might not be able to use full boot encryption because:

• You cannot have a separate /boot partition
• What is in /boot partition needs to be loaded by the bootloader, so if it's encrypted the bootloader needs to open that partition
• You don't have GRUB for ARM yet in Guix and u-boot doesn't support opening encrypted partitions

For some reasons (a Mediawiki or syntax bug?) the partitioning table ends up in the next section, but it should be in this section.

Small distributions

Distribution	Bootloader	Architectures	Separate /boot	encrypted /	LVM	Filesystems supported for /
Guix	GRUB	i686-linux x86_64-linux	No	Yes	?	Only: btrfs ext4 F2FS JFS XFS
	u-boot	aarch64-linux		No		Only: ext4
Parabola	GRUB	i686 x86_64	Yes	Yes	Yes	See Group:Software/FSDG_distributions/Filesystems.
	u-boot	armv7h	Yes	yes but with a separate unencrypted /boot

Distribution or software	Usage	Audience	Release type
libreCMC	WiFi access point and small network equipements Ben Nanonote (tiny portable device)	LibreCMC can probably be used without any command line knowledge, but it requires some networking knowledge (like what is 'DHCP', what is an IP address, etc). See also DistroConfiguration for more details. The installation might be more or less complex depending on the device. Some compatible devices are RYF compliant so they can just be bought with LibreCMC already installed.	Stable releases
ProteanOS	?	?	?
Replicant	Android distribution for smartphones and tablets	No need to know the command line to use it. Users need to have extremely basic command line knowledge for the installation. Devices can also be bought with Replicant already installed. Though these devices are not RYF certified.	Stable releases

Target architectures support

This section mentions which architecture the small distributions can run on. For instance Replicant runs on ARM (smartphones and tablets).

Distribution or software	ARM 32bit	ARM 64bit	MIPS 32bit big endian	MIPS 64bit little endian	PowerPC 32bit big endian	PowerPC 64bit little endian	Riscv 32bit	Riscv 64bit	x86 32bit	x86 64bit
libreCMC	built for cortexa9	No	Yes	No	No	No	No	No	Requires to build from source	Requires to build from source
ProteanOS	No	No	No	No	No	No	No	No	Yes	Yes
Replicant	Probably requires ARMv7	No	No	No	No	No	No	No	No	No

Host architectures support

This section mentions which architecture can be used to build the small distributions. For instance Replicant can only be built on x86_64 GNU/Linux computers.

Distribution or software	x86 32bit	x86 64bit
libreCMC	?	Yes
ProteanOS
Replicant	No	Yes

Adding support for a device

Distribution or software	Adding support for a device
General purpose GNU/Linux distributions	You may need to package device specific software like bootloaders for non-x86 devices You may need to update or write installation instructions for the device if the existing ones do not support the device You need to upstream the code that makes the hardware work if it's not already done
libreCMC
ProteanOS
Replicant	You need to add a vendor/device/the-vendor/the-device repository with the hardware configuration You may need to package the code that makes the hardware work if it's not already done

See also

• Group:Software/FSDG distributions

References

This page was a featured resource in August 2020.