NixOS on ARM/UEFI/fr: Difference between revisions

From NixOS Wiki
Nicolas-goudry (talk | contribs)
Created page with "Choisissez l'une des images suivantes (par ordre de préférence):"
Tags: Mobile edit Mobile web edit
Nicolas-goudry (talk | contribs)
No edit summary
 
(40 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages/>
{{ARM/breadcrumb}}
{{ARM/breadcrumb}}


Line 20: Line 21:
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 <tt>x86_64</tt>, 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.
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 <tt>x86_64</tt>, 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 ordinateurs à carte unique, '''''[[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.
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 ===
=== UEFI ===
Line 34: Line 35:


<span id="UEFI,_on_my_SBC???"></span>
<span id="UEFI,_on_my_SBC???"></span>
== UEFI, sur mon ordinateur à carte unique ??? ==
== UEFI, sur mon SBC ??? ==


Croyez-le ou non, c'est bien plus probable que vous ne le pensez si votre ordinateur à carte unique 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 <tt>AArch64</tt> UEFI de NixOS. Et ceci avec quasiment aucune différence par rapport au guide <tt>x86_64</tt>. Suivez simplement les instructions pour démarrer sur un système installé.
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 <tt>AArch64</tt> UEFI de NixOS. Et ceci avec quasiment aucune différence par rapport au guide <tt>x86_64</tt>. Suivez simplement les instructions pour démarrer sur un système installé.


<span id="Getting_a_Platform_Firmware"></span>
<span id="Getting_a_Platform_Firmware"></span>
=== Obtenir un ''micrologiciel de plateforme'' ===
== Obtenir un ''micrologiciel de plateforme'' ==


{{expansion|D'avantage de détails et des solutions alternatives seraient appréciés}}
{{expansion|D'avantage de détails et des solutions alternatives seraient appréciés}}
Line 54: Line 55:
Choisissez l'une des images suivantes (par ordre de préférence):
Choisissez l'une des images suivantes (par ordre de préférence):


<div lang="en" dir="ltr" class="mw-content-ltr">
* [https://hydra.nixos.org/job/nixos/trunk-combined/nixos.iso_minimal_new_kernel_no_zfs.aarch64-linux NixOS instable, nouveau noyau] – publication continue, dernier noyau, n'inclut pas ZFS étant donné qu'il est souvent en retard.
* [https://hydra.nixos.org/job/nixos/trunk-combined/nixos.iso_minimal_new_kernel_no_zfs.aarch64-linux NixOS unstable, new kernel] – rolling release, latest mainline kernel, does not build with ZFS as it would often lag behind.
* [https://hydra.nixos.org/job/nixos/trunk-combined/nixos.iso_minimal.aarch64-linux NixOS instable, noyau LTS] – compatibilité avec du matériel spécifique amoindrit, mais utilise une version plus récente de Nixpkgs
* [https://hydra.nixos.org/job/nixos/trunk-combined/nixos.iso_minimal.aarch64-linux NixOS unstable, LTS kernel] – may be less compatible with specific hardware, but tracks a more recent Nixpkgs
* [https://nixos.org/download.html#download-nixos NixOS stable] – branche stable, noyau LTS, généralement non recommandé à moins d'être certain que votre matériel soit bien supporté
* [https://nixos.org/download.html#download-nixos NixOS stable] – release branch, LTS kernel, generally not recommended unless you are confident your hardware is well-supported upstream
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Des images disque avec environnement graphique GNOME ou KDE sont également disponibles.
Graphical ISOs are also available in the GNOME and KDE flavors.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
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.
This installer image should be written to a USB drive, like usual. In a pinch, it may also be written to an SD image, if your target's platform firmware does not need to be written to that same SD image.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Installing"></span>
=== Installing ===
=== Installation ===
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Il suffit de suivre [https://nixos.org/manual/nixos/stable/index.html#sec-installation les instructions habituelles d'installation pour UEFI] en tenant compte des points d'attention suivants.
Following [https://nixos.org/manual/nixos/stable/index.html#sec-installation the usual installation steps for UEFI] is almost enough. Here's what you need to be mindful about.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{aside|title=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.}}
{{aside|title=Sidenote:|As the introduction stated, this guide '''assumes''' that the kernel in use '''fully supports''' your target board. If there are issues that comes from lack of hardware support, it is not a bug in this documentation.}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Shared_Firmware_Storage"></span>
==== Shared Firmware Storage ====
==== Stockage partagé du micrologiciel ====
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{note|Tout prendra son sens lorsque la section ''Obtenir un micrologiciel de plateforme'' sera terminé...}}
{{note|This will make more sense when ''Getting a Platform Firmware'' is finished...}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
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:
If your ''Platform Firmware'' lives on the target installation storage, e.g. written to an SD card and you install to the same SD card, you will need need to make sure that:
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
* Vous n'écrasez pas le micrologiciel s'il ne se trouve pas sur une partition.
* You are not overwriting the firmware, if it is not protected by a partition.
* La table de partition n'est pas réécrite depuis zéro.
* The partition table is not rewritten from scratch / zero.
* Vous ne supprimez pas les partitions existantes du micrologiciel.
* To not delete required existing firmware partitions.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{note|Si votre ''micrologiciel de plateforme'' n'est pas protégé par une partition, préférez utiliser une méthode d'installation différente pour votre ''micrologiciel de plateforme'' ou une distribution qui le protège.}}
{{note|If your ''Platform Firmware'' is not protected by a partition, consider choosing an alternative ''Platform Firmware'' installation method or distribution that protects it.}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
En dehors de ces points, vous pouvez procéder comme vous le feriez d'habitude en créant une partition ESP, FAT32, monter sur <code>/boot/</code>, votre partition rootfs préférée, le swap si vous le souhaitez, etc.
Otherwise, you can do as you would usually, create an ESP partition, FAT32, to be mounted at <code>/boot/</code>, your preferred rootfs partition, swap if desired, etc.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Bootloader_configuration"></span>
==== Bootloader configuration ====
==== Configuration du chargeur de démarrage ====
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Vérifiez que l'implémentation UEFI de votre ''micrologiciel de plateforme'' dispose de variables EFI inscriptible. Toutes les implémentations UEFI ne le permettent pas sur ARM, c'est donc un élément à prendre en compte. Si ce n'est pas le cas, {{Nixos:option|boot.loader.efi.canTouchEfiVariables}} doit être définit sur '''<code>false</code>'''.
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, {{Nixos:option|boot.loader.efi.canTouchEfiVariables}} has to be set to '''<code>false</code>'''.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{
{
Line 120: Line 95:
}
}
</nowiki>}}
</nowiki>}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{tip|Tout comme sur <tt>x86_64</tt>, installer [[REFInd|rEFInd]] à l'emplacement de secours (<code>/EFI/BOOT/BOOTAA64.EFI</code>) pourrait s'avérer utile.}}
{{tip|Just like on <tt>x86_64</tt> [[REFInd|rEFInd]] installed to the fallback location (<code>/EFI/BOOT/BOOTAA64.EFI</code>) may be helpful.}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Cette extrait utilise GRUB2, mais systemd-boot fonctionne également. Comme les variables EFI ne peuvent pas être manipulées, utiliser <code>efiInstallAsRemovable</code> permet l'installation de GRUB2 à l'emplacement de secours.
This sample uses GRUB2, but systemd-boot was also verified to work. Since EFI variables cannot be manipulated, using <code>efiInstallAsRemovable</code> handles installing GRUB2 to the default fallback location.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{
{
Line 139: Line 108:
}
}
</nowiki>}}
</nowiki>}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="General_Tips"></span>
=== General Tips ===
=== Astuces générales ===
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Utiliser le dernier noyau disponible est une bonne idée. Le support matériel pour les plateformes ARM étant en constante amélioration, utiliser le dernier noyau plutôt que la "dernière LTS" pourrait être bénéfique… ou pas.
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.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{{file|/etc/nixos/configuration.nix|nix|<nowiki>
{
{
Line 155: Line 119:
}
}
</nowiki>}}
</nowiki>}}
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Known_Issues"></span>
== Known Issues ==
== Problèmes connus ==
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="Device_Trees"></span>
=== Device Trees ===
=== Arborescence de périphériques ===
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
À ce jour, il n'y a pas de consensus parmi les distributions Linux à propos de la gestion de l'arborescence des périphériques lors de processus de démarrage UEFI.
As of right now, there is no consensus within Linux distros about the topic of managing device trees for the boot process with UEFI.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
La configuration actuelle s'appuie sur le micrologiciel de plateforme pour fournir une arborescence de périphériques appropriée pour le noyau à exécuter.
This current setup relies on the platform firmware providing an appropriate device tree for the kernel that will run.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Il est possible de faire charger une arborescence de périphériques par ''U-Boot'', plus récente par exemple, en plaçaant le dossier dtb d'une construction de noyau à l'emplacement <code>/dtb</code> de l'ESP. ''U-Boot'' chargera automatiquement une arborescence de périphériques selon l'heuristique, qui devrait être la bonne.
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 <code>/dtb</code> location in the ESP. ''U-Boot'' will automatically load a device tree according to heuristics, which should be the right one.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
En pratique, on ne sait pas dans quelle mesure cela constituerait un réel problème.
It is unknown how much of an actual issue this is in practice.
</div>

Latest revision as of 21:04, 12 July 2024

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

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: Si votre micrologiciel de plateforme n'est pas protégé par une partition, préférez utiliser une méthode d'installation différente pour votre micrologiciel de plateforme ou une distribution qui le protège.

En dehors de ces points, vous pouvez procéder comme vous le feriez d'habitude en créant une partition ESP, FAT32, monter sur /boot/, votre partition rootfs préférée, le swap si vous le souhaitez, etc.

Configuration du chargeur de démarrage

Vérifiez que l'implémentation UEFI de votre micrologiciel de plateforme dispose de variables EFI inscriptible. Toutes les implémentations UEFI ne le permettent pas sur ARM, c'est donc un élément à prendre en compte. Si ce n'est pas le cas, boot.loader.efi.canTouchEfiVariables doit être définit sur false.

/etc/nixos/configuration.nix
{
  boot.loader.efi.canTouchEfiVariables = false;
}

Cette extrait utilise GRUB2, mais systemd-boot fonctionne également. Comme les variables EFI ne peuvent pas être manipulées, utiliser efiInstallAsRemovable permet l'installation de GRUB2 à l'emplacement de secours.

/etc/nixos/configuration.nix
{
  boot.loader.grub.enable = true;
  boot.loader.grub.efiSupport = true;
  boot.loader.grub.efiInstallAsRemovable = true;
  boot.loader.grub.device = "nodev";
}

Astuces générales

Utiliser le dernier noyau disponible est une bonne idée. Le support matériel pour les plateformes ARM étant en constante amélioration, utiliser le dernier noyau plutôt que la "dernière LTS" pourrait être bénéfique… ou pas.

/etc/nixos/configuration.nix
{
  boot.kernelPackages = pkgs.linuxPackages_latest;
}

Problèmes connus

Arborescence de périphériques

À ce jour, il n'y a pas de consensus parmi les distributions Linux à propos de la gestion de l'arborescence des périphériques lors de processus de démarrage UEFI.

La configuration actuelle s'appuie sur le micrologiciel de plateforme pour fournir une arborescence de périphériques appropriée pour le noyau à exécuter.

Il est possible de faire charger une arborescence de périphériques par U-Boot, plus récente par exemple, en plaçaant le dossier dtb d'une construction de noyau à l'emplacement /dtb de l'ESP. U-Boot chargera automatiquement une arborescence de périphériques selon l'heuristique, qui devrait être la bonne.

En pratique, on ne sait pas dans quelle mesure cela constituerait un réel problème.