Group: Hardware/Software/FSDG distributions
Contents
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: | Stable releases
Rolling releases are also possible |
Guix System | Technical users:
|
Rolling release |
Hyperbola | Everybody?
|
Stable releases |
Parabola | Everybody:
|
Rolling releases |
PureOS | Everybody:
|
Stable releases |
Trisquel | Everybody:
|
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[4] | No[4] | No[4] | No[4] | No[4] | No[4] | i586 | Yes |
Guix System | armhf | Yes | Cross compilation only[5] | Cross compilation only[6] | POWER9, experimental[7] | Cross compilation only[8] | i686 | Yes |
Hyperbola | No | No | No | No | No | No | i686 | Yes |
Parabola | armv7h | experimental, through armv7h only[9] | No, discontinued[10] | No | Unfinished | Unfinished | i686 | Yes |
PureOS 10 (byzantium) | No | Yes, can be installed with debootstrap[11] | No | No | No | No | No | Yes |
Trisquel 9 (etiona) | No | No | No | No | No | No | i686 | Yes |
Trisquel 10 (nabia) | armhf[12] | No | No | No | No | No | No | Yes |
Trisquel 11 (aramo) | armhf[13] | arm64[13] | No | No | ppc64el[13] | No | i386[13] | amd64[13] |
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[14]. | Yes | Incomplete [15] | Yes[14] | |
Hyperbola v0.4.2 (milky-way) | Yes[16] | Yes: supported by Hyperbola[17] | Yes[18] | Difficult[19] | Yes[20] |
Parabola | Yes | Difficult[21] | Difficult[21] | Yes[22] | |
PureOS 10 (byzantium) | Yes [23] | No[24] | Difficult[25] | Yes [26] | |
Trisquel 10 (etiona) | Yes | No[27] | Difficult[28] | Yes | |
Trisquel 11 (aramo) | Yes[29] | No[30] | Difficult[28] | 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"[31].
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.[32]
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[33] 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[34] 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 | Fully support for user-generated keys |
---|---|---|---|
Dragora | Yes | Yes[35] | No documentation[36] |
Guix System | Yes | Yes[37] | No documentation |
Hyperbola v0.4.2 (milky-way) | Yes | Yes[38] | |
Parabola | Yes | Yes[39] | No documentation |
PureOS 10 (byzantium) | Yes | No[40] | No documentation |
Trisquel 10 (nabia) | Yes | Yes[41] | |
Trisquel 11 (aramo) | Yes | Yes[42] |
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.
Small distributions
Distribution or software | Usage | Audience | Release type |
---|---|---|---|
libreCMC |
|
|
Stable releases |
ProteanOS | ? | ? | ? |
Replicant |
|
|
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[43] | No | Yes | No | No | No | No | No | Requires to build from source | Requires to build from source |
ProteanOS | No[44] | No[44] | No[44] | No[44] | No[44] | No[44] | No[44] | No[44] | Yes[44] | Yes[44] |
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 |
|
libreCMC | |
ProteanOS | |
Replicant |
|
See also
References
- ↑ https://dragora.org/manual/en/html_node/pkgmanagement.html
- ↑ http://git.savannah.nongnu.org/cgit/dragora.git/tree/recipes
- ↑ So far the only graphical tools are either very domain specific tools (like a web interface for using Guix to do scientific experiments) or are too experimental to be packaged into Guix.
- ↑ 4.04.14.24.34.44.5 Dragora can also be bootstraped from source, but there is no guarantee that it will work for unsupported architectures.
- ↑ Guix still support cross compiling for mips64el-linux-gnu
- ↑ Guix support cross compiling for powerpc-linux-gnu.
- ↑ The Guix 1.3.0 release blog post (https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released/) states that "POWER9 support is now available as a technology preview"
- ↑ Guix support cross compiling for riscv64-linux-gnu.
-
↑ For it to work:
- You need to install the linux-libre-aarch64 kernel
- You need a processor that also support running 32bit arm code
- ↑ https://www.parabola.nu/news/parabola-support-for-mips64el-discontinued/
- ↑ This can be done in two stages like with debian. The first stage can be done this way: debootstrap --foreign --arch arm64 byzantium ./rootfs https://repo.puri.sm/pureos Amber can probably also be installed but I lacked older hardware that was supported by its kernel. Adding the dtb made it boot on Amber though.
- ↑ If we look at the coreutils package, we can see x86_64 and armhf. There is also many u-boot packages for armhf computers
- ↑ 13.013.113.213.313.4 If we look at the coreutils package, we can see amd64, arm64, armhf, i386, ppc64el. And if we look at https://cdimage.trisquel.info/trisquel-image we don't have i386 anymore.
- ↑ 14.014.1 The graphical installer supports BIOS and UEFI, and there is also support for both in the Bootloader configuration settings
- ↑ We can create images with guix system image -t efi32-raw, and define configurations with 32bit UEFI, but there is no official installer for efi32-raw (though we might be able to create one with "guix system image -t efi32-raw gnu/system/install.scm" with gnu/system/install.scm from the Guix source code) and the installer application probably doesn't support efi32-raw yet.
- ↑ The installer boots on a computers with a BIOS (Toshiba NB550D).
- ↑ https://wiki.hyperbola.info/doku.php?id=en:manual:fde_installation
- ↑ hyperbola-milky-way-v0.4.2-dual.iso was successfully booted in i686 mode on a Dell Venue 8 pro (x86_64 with 32bit UEFI) by selecting "Boot Hyperbola GNU/Linux-libre HyperISO (i686) from HYPER_EFI"
- ↑ Once hyperbola-milky-way-v0.4.2-dual.iso is booted on an x86_64 computer, the grub package has files in /usr/lib/grub/x86_64-efi and /usr/lib/grub/i386-efi. So it's possible to install it on 32bit UEFI with an x86_64 CPU in theory. However booting that ISO and selecting Boot Hyperbola GNU/Linux-libre HyperISO (x86_64) from HYPER_EFI" results in the installer erroring with "Error: Not found while loading vmlinuz". The same ISO works on a Thinkpad X230 (x86_64 with x86_64 UEFI) in UEFI mode with secure boot disabled.
- ↑ Hyperbola installation instruction have specific instructions for UEFI. The installer also boots on computers with UEFI.
- ↑ 21.021.1 The parabola-2021.08.11-dual.iso was tested and it didn't boot on an x86_64 tablet with a 32bit UEFI (dell venue 8 pro). The same ISO boots fine on an x86_64 computer with a BIOS or an x86_64 computer with UEFI. However the Parabola GRUB package supports many GRUB platforms including i386-efi, so there is still a way to do the installation. Since there are no installation instructions for 32bit UEFI and that none of the (iso) installer have support for it, the only way to do it requires another computer. To do the installation someone could install Parabola on another computer and convert the installation to UEFI 32bit and reuse it on 32bit UEFI computer. Another way would be to create a bootable image with commands like dd, udisksctl loop-setup, pacstrap, and chroot inside and install an UEFI 32bit bootloader.
- ↑ Parabola installation instructions have specific instructions for UEFI.
- ↑ The installer image boots fine on a qemu-kvm libvirt virtual machine running SeaBIOS on Parabola x86_64, and the installer (calamares) then detect the BIOS without issue.
- ↑ There is no i686 support in PureOS.
- ↑ The official PureOS installer image doesn't have support for 32bit UEFI (it only has bootx64.efi in /EFI/boot). But we can still install it (for instance with debootstrap, or by installing it on another computer first), because there is a grub-efi-ia32 package that can enable to boot on systems with 32bit UEFI.
- ↑ The installer image boots fine on an UEFI computer, and the installer (calamares) then detect UEFI without issue
- ↑ There is no i686 support yet in Trisquel 10.
- ↑ 28.028.1 Trisquel has a grub-efi-ia32, so there is a way to install it. But there are no installation instructions for 32bit UEFI and that none of the (iso) installer have support for it, so the only way to do it requires another computer. To do the installation someone could install Trisquel on another computer and convert the installation to UEFI 32bit and reuse it on 32bit UEFI computer. Another way would be to create a bootable image with commands like dd, udisksctl loop-setup, debootstrap , and chroot inside and install an UEFI 32bit bootloader.
- ↑ I tested booting the x86_64 installer on a computer with a BIOS. In addition an upgrade from Trisquel 10 to Trisquel 11 on the same computer worked and the computer boots fine.
- ↑ There is no i686 support yet in Trisquel 11. Even if coreutils has an i386 package, most packages are probably missing (like like libreoffice-writer, abiword, etc). And there is also no i386 installer. So maybe the i386 packages are part of some 32bit compatibility feature only, or maybe the work is unfinished, etc.
- ↑ According to the Wikipedia article on Windows 10, "As with Windows 8, all certified devices must ship with UEFI Secure Boot enabled by default. Unlike Windows 8, OEMs are no longer required to make Secure Boot settings user-configurable, meaning that devices may optionally be locked to run only Microsoft-signed operating systems."
- ↑ Some of the computers reach the distribution boot menu (like "Install Trisquel", "Try Trisquel without installing") but have a black screen after that. These computers don't have restricted boot. Some other could have restricted boot but they would need more tests to know if it's the case or not.
- ↑ Example: https://blog.hansenpartnership.com/owning-your-windows-8-uefi-platform/
- ↑ For instance they disable kexec, access to physical memory from programs, etc.
- ↑ Dragora has a grub package no packages for other bootloaders than GRUB. It doesn't have any bootloaders (directly or indirectly) signed by Microsoft.
- ↑ At the time of writing, the Part II - Installation section of the manual is empty so there is no documentation on how to do that
- ↑ Guix doesn't have any bootloaders (directly or indirectly) signed by Microsoft.
- ↑ Hyperbola doesn't have any bootloaders (directly or indirectly) signed by Microsoft. Also booting the hyperbola-milky-way-v0.4.2-dual.iso failed on a Thinkpad X230 with secure boot enforced.
- ↑ Parabola builds GRUB but also reuses some of Arch Linux packages, like the shim bootloader. Parabola and Arch Linux bootloaders aren't signed by Microsoft.
-
↑ PureOS byzantium has some bootloader packages from Debian (like shim-signed) that are signed by Microsoft. Though it also has corresponding unsigned packages like shim-unsigned.
I also tested both the pureos-10~devel-gnome-live-20220602_amd64.iso and pureos-10~devel-plasma-live-20220602_amd64.iso installers on a Thinkpad X230 with the stock boot software (UEFI) with secure boot enforced, and due to some bug (probably in the UEFI) I had to select "debian" to boot on the installer. It then boots normally to PureOS. Without HDD that X230 would also refuse to boot on the PureOS installer. - ↑ Trisquel doesn't have any bootloaders (directly or indirectly) signed by Microsoft.
- ↑ I tested the trisquel_11.0_amd64.iso installer on a Thinkpad X230 with the stock boot software (UEFI) with secure boot enforced, and it didn't boot.
- ↑ https://librecmc.org/librecmc/downloads/snapshots/v1.5.10/targets/mvebu/cortexa9/
- ↑ 44.044.144.244.344.444.544.644.744.844.9 http://proteanos.com/doc/install/pc/
This page was a featured resource in August 2020.