NixOS on ARM/UEFI/fr

← Back to NixOS on ARM

Note: Cette page présume d'une architecture AArch64. La plupart des instructions fonctionneront également pour une architecture armv7l (à date du 19/07/2022), néanmoins l'état actuel du support d'armv7l dans NixOS ne donnera pas une très bonne expérience.

Cette section de la documentation NixOS sur ARM a pour but de documenter le plus d'éléments possibles pour démarrer n'importe quelle carte ARM utilisant l'UEFI. Ce document se concentre particulièrement sur les ordinateurs à carte unique (aussi appelés SBCs), étant donné que c'est pour ceux-ci que le démarrage est le plus compliqué, voir carrément impossible.

Les bases

Support cible

Certains points ne seront pas spécifiques à UEFI. Pour exemple, le support en fonction du noyau utilisé. Ce document présume que les distributions Linux standard fonctionnent sur le système cible afin d'envisager l'installation depuis une image disque (ISO) générique.

Tout comme il est possible de le faire sur x86_64, vous pouvez construire une image disque personnalisée. Les détails sur une telle opération sortent du cadre de cet article. Les mêmes pièges sont à prévoir et éviter. Par exemple, la configuration générée ne prendra pas en compte la personnalisation de la configuration du noyau.

Micrologiciel de plateforme

Définissons d'abord ce qu'est un micrologiciel de plateforme. C'est un terme générique utilisé pour décrire la première chose démarrée par le processeur lors du démarrage. Sur un système x86_64, il s'agit de ce qu'on appelait autrefois le BIOS. Aujourd'hui souvent appelé EFI. C'est ce qui initialise suffisamment de matériel pour que le système d'exploitation puisse démarrer. De plus, il offre souvent à l'utilisateur d'effectuer une configuration basique ainsi que la gestion des options de démarrage.

Dans le monde ARM des SBC, U-Boot est la solution de facto pour le micrologiciel de plateforme. Bien que U-Boot soit souvent appelé à confusion, mais à juste titre, Boot Loader, il joue souvent un double rôle. Il est chargé d'initialiser le matériel mais est également utilisé pour gérer le chargement et le démarrage du système d'exploitation.

UEFI

Le standard UEFI n'est pas quelque chose de tangible par lui-même. Mal résumé, il s'agit d'une spécification fournissant une interface qui décrit le processus de démarrage standard et comprend un environnement avant le démarrage du système ainsi que des protocoles pour les systèmes d'exploitation.

Il existe plusieurs implémentation de l'UEFI. Des constructeurs tels que American Megatrends, Phoenix Technologies et Insyde Software ont probablement produit celui présent sur votre machine x86_64. TianoCore est la référence open source des implémentations UEFI. Heureusement, U-Boot implémente suffisamment (et même un peu plus que) la spécification UEFI.

SBBR ? EBBR ?

Bien que barbares, ces sigles signifient respectivement en anglais Server Base Boot Requirements et Embedded Base Boot Requirements, qu'on pourrait traduire par Exigences de démarrage de base du serveur et Exigences de démarrage de base intégrée. Ce sont deux spécifications pour ARM. Si votre système cible est en conformité avec l'une d'entre elles, le démarrage UEFI devrait être pris en charge. Avec la prise en charge minimale présente dans U-Boot, les systèmes cibles qui ne sont pas conforme avec la spécification EBBR peuvent être rendues conformes, ou presque, en supportant le strict minimum.

UEFI, sur mon SBC ???

Croyez-le ou non, c'est bien plus probable que vous ne le pensez si votre SBC est bien pris en charge par U-Boot. U-Boot fournit suffisamment d'UEFI pour se conformer à EBBR, qui à son tour est suffisant pour démarrer l'image disque AArch64 UEFI de NixOS. Et ceci avec quasiment aucune différence par rapport au guide x86_64. Suivez simplement les instructions pour démarrer sur un système installé.

Obtenir un micrologiciel de plateforme

☶︎

This article or section needs to be expanded. Further information may be found in the related discussion page. Please consult the pedia article metapage for guidelines on contributing.

As an opinionated example, you can get started with Tow-Boot, a U-Boot distribution, which is intended to make the initial setup a bit easier by abstracting the platform differences so that they do not matter.

N'importe quel autre micrologiciel de plateforme conforme UEFI peut être utilisé.

Obtenir l'image disque d'installation

Choisissez l'une des images suivantes (par ordre de préférence):

• NixOS instable, nouveau noyau – publication continue, dernier noyau, n'inclut pas ZFS étant donné qu'il est souvent en retard.
• NixOS instable, noyau LTS – compatibilité avec du matériel spécifique amoindrit, mais utilise une version plus récente de Nixpkgs
• NixOS stable – branche stable, noyau LTS, généralement non recommandé à moins d'être certain que votre matériel soit bien supporté

Des images disque avec environnement graphique GNOME ou KDE sont également disponibles.

Cette image disque d'installation devrait être écrite sur une clé USB, comme d'habitude. Elle peut à la rigueur être écrite sur une carte SD si le micrologiciel de votre plateforme n'a pas besoin d'être écrit sur cette même carte.

Installation

Il suffit de suivre les instructions habituelles d'installation pour UEFI en tenant compte des points d'attention suivants.

Note de marge: Comme indiqué en introduction, ce guide présume que votre SBC est entièrement supporté par le noyau. Si des problèmes surviennent dû au manque de support de votre matériel, ce n'est pas à cause de cette documentation.

Stockage partagé du micrologiciel

Note: Tout prendra son sens lorsque la section Obtenir un micrologiciel de plateforme sera terminé...

Si votre micrologiciel de plateforme se trouve sur le même média que l'image disque d'installation, e.g. écrit sur une carte SD depuis laquelle vous effectuez l'installation, vous devez vous assurer que:

• Vous n'écrasez pas le micrologiciel s'il ne se trouve pas sur une partition.
• La table de partition n'est pas réécrite depuis zéro.
• Vous ne supprimez pas les partitions existantes du micrologiciel.

Note: If your Platform Firmware is not protected by a partition, consider choosing an alternative Platform Firmware installation method or distribution that protects it.

Otherwise, you can do as you would usually, create an ESP partition, FAT32, to be mounted at /boot/, your preferred rootfs partition, swap if desired, etc.

Bootloader configuration

Know if your Platform Firmware's UEFI implementation has writable EFI vars. This is not true for all UEFI implementations on ARM, but is something to be mindful about. If it does not, boot.loader.efi.canTouchEfiVariables has to be set to false.

❄︎ /etc/nixos/configuration.nix

{
  boot.loader.efi.canTouchEfiVariables = false;
}

🟆︎

Tip: Just like on x86_64 rEFInd installed to the fallback location (/EFI/BOOT/BOOTAA64.EFI) may be helpful.

This sample uses GRUB2, but systemd-boot was also verified to work. Since EFI variables cannot be manipulated, using efiInstallAsRemovable handles installing GRUB2 to the default fallback location.

❄︎ /etc/nixos/configuration.nix

{
  boot.loader.grub.enable = true;
  boot.loader.grub.efiSupport = true;
  boot.loader.grub.efiInstallAsRemovable = true;
  boot.loader.grub.device = "nodev";
}

General Tips

Using the latest kernel is probably a good idea. Hardware support for ARM platforms is always improving, and using the latest kernel, rather than the "latest LTS", might be enough to break it or make it.

❄︎ /etc/nixos/configuration.nix

{
  boot.kernelPackages = pkgs.linuxPackages_latest;
}

Known Issues

Device Trees

As of right now, there is no consensus within Linux distros about the topic of managing device trees for the boot process with UEFI.

This current setup relies on the platform firmware providing an appropriate device tree for the kernel that will run.

With U-Boot, it is possible to make it load a device tree, for example a more up-to-date one, by placing the dtb folder from a kernel build output at the /dtb location in the ESP. U-Boot will automatically load a device tree according to heuristics, which should be the right one.

It is unknown how much of an actual issue this is in practice.