NixOS on ARM/UEFI/fr: Difference between revisions

Nicolas-goudry (talk | contribs)
Created page with "{{note|Tout prendra son sens lorsque la section ''Obtenir un micrologiciel de plateforme'' sera terminé...}}"
Nicolas-goudry (talk | contribs)
No edit summary
 
(21 intermediate revisions by the same user not shown)
Line 40: Line 40:


<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 75: Line 75:
{{note|Tout prendra son sens lorsque la section ''Obtenir un micrologiciel de plateforme'' sera terminé...}}
{{note|Tout prendra son sens lorsque la section ''Obtenir un micrologiciel de plateforme'' sera terminé...}}


<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 107: 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 126: 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 142: 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>