12.15 Invoquer guix system

Une fois que vous avez écrit une déclaration de système d’exploitation comme nous l’avons vu dans les sections précédentes, elle peut être instanciée avec la commande guix system. Voici le résumé de la commande :

guix system options… action file

file doit être le nom d’un fichier contenant une déclaration operating-system. action spécifie comment le système d’exploitation est instancié. Actuellement les valeurs suivantes sont supportées :

search

Affiche les définitions des types de services disponibles qui correspondent aux expressions régulières données, triées par pertinence :

$ guix system search console
name: console-fonts
location: gnu/services/base.scm:806:2
extends: shepherd-root
description: Install the given fonts on the specified ttys (fonts are per
+ virtual console on GNU/Linux).  The value of this service is a list of
+ tty/font pairs.  The font can be the name of a font provided by the `kbd'
+ package or any valid argument to `setfont', as in this example:
+
+      '(("tty1" . "LatGrkCyr-8x16")
+        ("tty2" . (file-append
+                      font-tamzen
+                      "/share/kbd/consolefonts/TamzenForPowerline10x20.psf"))
+        ("tty3" . (file-append
+                      font-terminus
+                      "/share/consolefonts/ter-132n"))) ; for HDPI
relevance: 9

name: mingetty
location: gnu/services/base.scm:1190:2
extends: shepherd-root
description: Provide console login using the `mingetty' program.
relevance: 2

name: login
location: gnu/services/base.scm:860:2
extends: pam
description: Provide a console log-in service as specified by its
+ configuration value, a `login-configuration' object.
relevance: 2

…

Comme pour guix package --search, le résultat est écrit au format recutils, ce qui rend facile le filtrage de la sortie (voir GNU recutils databases dans GNU recutils manual).

edit

Modifier ou visualiser la définition d’un type de service donné.

Par exemple, la commande plus bas ouvre votre éditeur, spécifié par la variable d’environnement EDITOR, sur la définition du type de service openssh :

guix system edit openssh

reconfigure

Construit le système d’exploitation décrit dans file, l’active et passe dessus³⁶.

Remarque : Il est grandement recommandé de lancer guix pull une fois avant de lancer guix system reconfigure pour la première fois (voir Invoquer guix pull). Sans cela, vous verriez une version plus ancienne de Guix une fois reconfigure terminé.

Cela met en application toute la configuration spécifiée dans file : les comptes utilisateurs, les services du système, la liste globale des paquets, les programmes setuid, etc. La commande démarre les services systèmes spécifiés dans file qui ne sont pas actuellement lancés ; si un service est actuellement exécuté cette commande s’arrange pour qu’il soit mis à jour la prochaine fois qu’il est stoppé (p. ex par herd stop X ou herd restart X).

Cette commande crée une nouvelle génération dont le numéro est un de plus que la génération actuelle (rapportée par guix system list-generations). Si cette génération existe déjà, elle sera réécrite. Ce comportement correspond à celui de guix package (voir Invoquer guix package).

Elle ajoute aussi une entrée de menu du chargeur d’amorçage pour la nouvelle configuration, à moins que --no-bootloader ne soit passé. Pour GRUB, elle déplace les entrées pour les anciennes configurations dans un sous-menu, ce qui vous permet de choisir une ancienne génération au démarrage si vous en avez besoin.

À la fin, le nouveau système d’exploitation est déployé dans /run/current-system. Ce répertoire contient les métadonnées de provenance : la liste des canaux utilisés (voir Canaux) et fichier lui-même, s’il est disponible. Vous pouvez les voir avec :

guix system describe

Cette information est utile si vous voulez plus tard inspecter comment une génération particulière a été construite. En fait, en supposant que file est auto-contenu, vous pouvez reconstruire la génération n de votre système d’exploitation avec :

guix time-machine \
  -C /var/guix/profiles/system-n-link/channels.scm -- \
  system reconfigure \
  /var/guix/profiles/system-n-link/configuration.scm

Vous pouvez considérer cela comme une sorte de contrôle de version intégré ! Votre système n’est pas seulement un artéfact binaire : il contient ses propres sources. Voir provenance-service-type, pour plus d’informations sur le suivi de provenance.

Par défaut, reconfigure vous empêche de faire revenir en arrière votre système, ce qui pourrait (ré)introduire des vulnérabilités de sécurité et cause des problèmes avec les services « avec état » comme les systèmes de gestion de bases de données. Vous pouvez contrôler ce comportement en passant --allow-downgrades.

switch-generation ¶

Passe à une génération existante du système. Cette action change automatiquement le profil système vers la génération spécifiée. Elle réarrange aussi les entrées existantes du menu du chargeur d’amorçage du système. Elle fait de l’entrée du menu pour la génération spécifiée l’entrée par défaut et déplace les entrées pour les autres générations dans un sous-menu, si cela est pris en charge par le chargeur d’amorçage utilisé. Lors du prochain démarrage du système, la génération du système spécifiée sera utilisée.

Le chargeur d’amorçage lui-même n’est pas réinstallé avec cette commande. Ainsi, le chargeur d’amorçage est utilisé avec un fichier de configuration plus à jour.

La génération cible peut être spécifiée explicitement par son numéro de génération. Par exemple, l’invocation suivante passerait à la génération 7 du système :

guix system switch-generation 7

La génération cible peut aussi être spécifiée relativement à la génération actuelle avec la forme +N ou -N, où +3 signifie « trois générations après la génération actuelle » et -1 signifie « une génération précédent la génération actuelle ». Lorsque vous spécifiez un nombre négatif comme -1, il doit être précédé de -- pour éviter qu’il ne soit compris comme une option. Par exemple :

guix system switch-generation -- -1

Actuellement, l’effet de l’invocation de cette action est uniquement de passer au profil du système vers une autre génération existante et de réarranger le menu du chargeur d’amorçage. Pour vraiment commencer à utiliser la génération spécifiée, vous devez redémarrer après avoir lancé cette action. Dans le futur, elle sera corrigée pour faire la même chose que reconfigure, comme réactiver et désactiver les services.

Cette action échouera si la génération spécifiée n’existe pas.

roll-back ¶

Passe à la génération précédente du système. Au prochain démarrage, la génération précédente sera utilisée. C’est le contraire de reconfigure, et c’est exactement comme invoquer switch-generation avec pour argument -1.

Actuellement, comme pour switch-generation, vous devez redémarrer après avoir lancé cette action pour vraiment démarrer sur la génération précédente du système.

delete-generations ¶

Supprimer des générations du système, ce qui les rend disponibles pour le ramasse-miettes (voir Invoquer guix gc, pour des informations sur la manière de lancer le « ramasse-miettes »).

Cela fonctionne comme pour ‘guix package --delete-generations’ (voir --delete-generations). Avec aucun argument, toutes les générations du système sauf la génération actuelle sont supprimées :

guix system delete-generations

Vous pouvez aussi choisir les générations que vous voulez supprimer. L’exemple plus bas supprime toutes les génération du système plus vieilles que deux mois :

guix system delete-generations 2m

Lancer cette commande réinstalle automatiquement le chargeur d’amorçage avec une liste à jour d’entrées de menu — p. ex. le sous-menu « anciennes générations » dans GRUB ne liste plus les générations qui ont été supprimées.

build

Construit la dérivation du système d’exploitation, ce qui comprend tous les fichiers de configuration et les programmes requis pour démarrer et lancer le système. Cette action n’installe rien.

init

Rempli le répertoire donné avec tous les fichiers nécessaires à lancer le système d’exploitation spécifié dans file. C’est utile pour la première installation de Guix System. Par exemple :

guix system init my-os-config.scm /mnt

copie tous les éléments du dépôt requis par la configuration spécifiée dans my-os-config.scm dans /mnt. Cela comprend les fichiers de configuration, les paquets, etc. Elle crée aussi d’autres fichiers essentiels requis pour que le système fonctionne correctement — p. ex. les répertoires /etc, /var et /run et le fichier /bin/sh.

Cette commande installe aussi le chargeur d’amorçage sur les cibles spécifiées dans my-os-config, à moins que l’option --no-bootloader ne soit passée.

vm ¶

Construit une machine virtuelle (VM) qui contient le système d’exploitation déclaré dans file et renvoie un script pour lancer cette VM.

Remarque : Les actions vm et les autres plus bas peuvent utiliser la prise en charge KVM du noyau Linux-libre. Plus spécifiquement, si la machine prend en charge la virtualisation matérielle, le module noyau KVM correspondant devrait être chargé, et le nœud de périphérique /dev/kvm devrait exister et être lisible et inscriptible pour l’utilisateur et pour les utilisateurs de construction du démon (voir Réglages de l’environnement de construction).

Les arguments passés au script sont passés à QEMU comme dans l’exemple ci-dessous, qui active le réseau et demande 1 Go de RAM pour la machine émulée :

$ /gnu/store/…-run-vm.sh -m 1024 -smp 2 -nic user,model=virtio-net-pci

Il est possible de combiner les deux étapes en une :

$ $(guix system vm my-config.scm) -m 1024 -smp 2 -nic user,model=virtio-net-pci

La VM partage sont dépôt avec le système hôte.

Par défaut, le système de fichiers racine de la VM sera monté de manière volatile ; l’option --persistent peut être fournie pour le rendre persistent à la place. Dans ce cas, le fichier d’image disque VM sera copiée à partir du dépôt vert le répertoire TMPDIR pour le rendre inscriptible.

Vous pouvez partager des fichiers supplémentaires entre l’hôte et la VM avec les options en ligne de commande --share et --expose : la première spécifie un répertoire à partager avec accès en écriture, tandis que le deuxième fournit un accès en lecture-seule au répertoire partagé.

L’exemple ci-dessous crée une VM dans laquelle le répertoire personnel de l’utilisateur est accessible en lecture-seule, et où le répertoire /exchange est une correspondance en lecture-écriture à $HOME/tmp sur l’hôte :

guix system vm my-config.scm \
   --expose=$HOME --share=$HOME/tmp=/exchange

Sur GNU/Linux, le comportement par défaut consiste à démarrer directement sur le noyau ; cela a l’avantage de n’avoir besoin que d’une toute petite image disque puisque le dépôt de l’hôte peut ensuite être monté.

L’option --full-boot force une séquence de démarrage complète, en commençant par le chargeur d’amorçage. Cela requiert plus d’espace disque puisqu’une image racine contenant au moins le noyau, l’initrd et les fichiers de données du chargeur d’amorçage doit être créé.

On peut utiliser l’option --image-size pour spécifier la taille de l’image.

L’option --no-graphic demandera à guix system de créer une VM sans interface qui utilisera le tty qui l’invoque pour ses entrées-sorties. Entre autres, cela active le copier-coller et le défilement. Utilisez le préfixe ctrl-a pour lancer des commandes QEMU ; p. ex. ctrl-a h affiche l’aide, ctrl-a x quitte la VM et ctrl-a c alterne entre le moniteur QEMU et la VM.

image ¶

La commande image peut produire divers types d’images. Vous pouvez choisir le type d’image en utilisant l’option --image-type. Sa valeur par défaut est efi-raw. Lorsque sa valeur est iso9660, vous pouvez utiliser l’option --label pour spécifier un identifiant de volume avec image. Par défaut, le système de fichiers racine d’une image disque est montée en non-volatile ; vous pouvez fournir l’option --volatile pour la rendre volatile. Si vous utilisez image, le chargeur d’amorçage installé sur l’image générée est celui de la définition operating-system fournie. L’exemple suivant montre comment générer une image qui utilise le chargeur d’amorçage grub-efi-bootloader et la démarrer avec QEMU :

image=$(guix system image --image-type=qcow2 \
        gnu/system/examples/lightweight-desktop.tmpl)
cp $image /tmp/my-image.qcow2
chmod +w /tmp/my-image.qcow2
qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000 \
                   -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin

Lorsque vous utilisez le type d’image efi-raw, une image disque brute est produite ; elle peut être copiée telle quelle sur un périphérique USB par exemple. En supposant que /dev/sdc est le périphérique correspondant à une clé USB, on peut copier l’image dessus avec la commande suivante :

# dd if=$(guix system image my-os.scm) of=/dev/sdc status=progress

La commande --list-image-types liste tous les types d’images disponibles.

Lorsque vous utilisez le type d’image qcow2, l’image renvoyée est au format qcow2, que l’émulateur QEMU peut utiliser efficacement. Voir Exécuter Guix sur une machine virtuelle, pour plus d’information sur la manière de lancer l’image dans une machine virtuelle. Le chargeur d’amorçage grub-bootloader est toujours utilisé quelque soit celui déclaré dans le fichier operating-system passé en argument. Cela facilite l’utilisation de QEMU, qui utilise le BIOS SeaBIOS par défaut, et s’attend à un chargeur d’amorçage installé dans le Master Boot Record (MBR).

En utilisant le type d’image docker, on produit une image Docker. Guix construit l’image de zéro, et non à partir d’une image Docker de base pré-existante. En conséquence, elle contient exactly ce que vous avez défini dans le fichier de configuration du système. Vous pouvez ensuite charger l’image et lancer un conteneur Docker avec des commande comme :

image_id="$(docker load < guix-system-docker-image.tar.gz)"
container_id="$(docker create $image_id)"
docker start $container_id

Cette commande démarre un nouveau conteneur Docker à partir de l’image spécifiée. Il démarrera le système Guix de la manière habituelle, ce qui signifie qu’il démarrera tous les services que vous avez définis dans la configuration du système d’exploitation. Vous pouvez obtenir un shell interactif dans le conteneur en utilisant docker exec :

docker exec -ti $container_id /run/current-system/profile/bin/bash --login

En fonction de ce que vous lancez dans le conteneur Docker, il peut être nécessaire de donner des permissions supplémentaires au conteneur. Par exemple, si vous voulez construire des paquets avec Guix dans le conteneur Docker, vous devriez passer --privileged à docker create.

Enfin, l’option --network s’applique à guix system docker-image : elle produit une image où le réseau est partagé avec l’hôte, et donc sans services comme nscd ou NetworkManager.

conteneur

Renvoie un script qui lance le système d’exploitation déclaré dans file dans un conteneur. Les conteneurs sont un ensemble de mécanismes d’isolation légers fournis par le noyau Linux-libre. Les conteneurs sont substantiellement moins gourmands en ressources que les machines virtuelles complètes car le noyau, les objets partagés et d’autres ressources peuvent être partagés avec le système hôte ; cela signifie aussi une isolation moins complète.

Actuellement, le script doit être lancé en root pour pouvoir supporter plus d’un utilisateur et d’un groupe. Le conteneur partage son dépôt avec le système hôte.

Comme avec l’action vm (voir guix system vm), des systèmes de fichiers supplémentaires peuvent être partagés entre l’hôte et le conteneur avec les options --share et --expose :

guix system container my-config.scm \
   --expose=$HOME --share=$HOME/tmp=/exchange

Les options --share et --expose peuvent aussi être passées au script généré pour effectuer un montage lié de répertoires supplémentaires dans le conteneur.

Remarque : Cette option requiert Linux-libre ou supérieur.

options peut contenir n’importe quelle option commune de construction (voir Options de construction communes). En plus, options peut contenir l’une de ces options :

--expression=expr

-e expr

Considère le système d’exploitation en lequel s’évalue expr. C’est une alternative à la spécification d’un fichier qui s’évalue en un système d’exploitation. C’est utilisé pour générer l’installateur du système Guix (voir Construire l’image d’installation).

--system=système

-s système

Essaye de construire pour system au lieu du type du système hôte. Cela fonction comme pour guix build (voir Invoquer guix build).

--target=triplet

Effectuer une compilation croisée pour triplet qui doit être un triplet GNU valide, comme ""aarch64-linux-gnu"" (voir GNU configuration triplets dans Autoconf).

--derivation

-d

Renvoie le nom du fichier de dérivation du système d’exploitation donné sans rien construire.

--save-provenance

Comme nous en avons parlé précédemment, guix system init et guix system reconfigure enregistrent toujours les informations de provenance via un service dédié (voir provenance-service-type). Cependant, d’autres commande ne le font pas par défaut. Si vous voulez, disons, créer une image de machine virtuelle contenant les informations de provenance, vous pouvez lancer :

guix system image -t qcow2 --save-provenance config.scm

De cette façon, l’image qui en résulte va effectivement « intégrer sa propre source » sous la forme de méta-données dans /run/current-system. Avec cette information, on peut reconstruire l’image pour s’assurer qu’elle contient vraiment ce qu’elle prétend contenir ; ou on peut utiliser ça pour dériver une variante de l’image.

--image-type=type

-t type

Pour l’action image, crée une image du type donné.

Lorsque cette option est omise, guix system utilise le type d’image efi-raw.

--image-type=iso9660 produit une image ISO-9660, qu’il est possible de graver sur un CD ou un DVD.

--image-size=size

Pour l’action image, crée une image de la taille donnée size. size peut être un nombre d’octets ou contenir un suffixe d’unité (voir size specifications dans GNU Coreutils).

Lorsque cette option est omise, guix system calcule une estimation de la taille de l’image en fonction de la taille du système déclaré dans file.

--network

-N

Pour l’action container, permet aux conteneurs d’accéder au réseau de l’hôte, c’est-à-dire, ne crée pas d’espace de nom réseau.

--root=fichier

-r fichier

Fait de fichier un lien symbolique vers le résultat, et l’enregistre en tant que racine du ramasse-miettes.

--skip-checks

Passe les vérifications de sécurité avant l’installation.

Par défaut, guix system init et guix system reconfigure effectuent des vérifications de sécurité : ils s’assurent que les systèmes de fichiers qui apparaissent dans la déclaration operating-system existent vraiment (voir Systèmes de fichiers) et que les modules de noyau Linux qui peuvent être requis au démarrage sont listés dans initrd-modules (voir Disque de RAM initial). Passer cette option saute ces vérifications complètement.

--allow-downgrades

Dit à guix system reconfigure de permettre le retour en arrière du système.

Par défaut, reconfigure vous empêche de faire revenir votre système en arrière. Il fait cela en comparant les informations de provenance de votre système (décrites par guix system describe) avec celles de la commande guix (décrites par guix describe). Si les commits de guix ne descendent pas de ceux utilisés pour votre système, guix system reconfigure renvoie une erreur. Passer --allow-downgrades vous permet de passer ces tests.

Remarque : Assurez-vous de comprendre les implications de sa sécurité avant d’utiliser --allow-downgrades.

--on-error=strategy

Applique strategy lorsqu’une erreur arrive lors de la lecture de file. strategy peut être l’une des valeurs suivantes :

nothing-special

Rapporte l’erreur de manière concise et quitte. C’est la stratégie par défaut.

backtrace

Pareil, mais affiche aussi une trace de débogage.

debug

Rapporte l’erreur et entre dans le débogueur Guile. À partir de là, vous pouvez lancer des commandes comme ,bt pour obtenir une trace de débogage, ,locals pour afficher les valeurs des variables locales et plus généralement inspecter l’état du programme. Voir Debug Commands dans GNU Guile Reference Manual, pour une liste de commandes de débogage disponibles.

Une fois que vous avez construit, re-configuré et re-re-configuré votre installation Guix, vous pourriez trouver utile de lister les générations du système disponibles sur le disque — et que vous pouvez choisir dans le menu du chargeur d’amorçage :

describe

Décrit la génération du système lancé : son nom de fichier, son noyau et chargeur d’amorçage utilisé, etc, ainsi que les informations de provenance si elles sont disponibles.

le drapeau --list-intalled est disponible, avec la même syntaxe que celui utilisé dans guix package --list-installed (voir Invoquer guix package). Lorsque le drapeau est utilisé, la description incluera une liste des paquets qui sont actuellement installés dans le profil du système, avec un filtre facultatif sur une expression régulière.

Remarque : La génération du système en cours — référencé par /run/current-system — n’est pas nécessairement la génération actuelle du système — référencée par /var/guix/profiles/system : elles sont différentes si par exemple, vous choisissez dans le menu du chargeur d’amorçage de démarrer une ancienne génération.

Elles peuvent aussi être différentes de la génération du système démarrée — référencée par /run/booted-system — par exemple parce que vous avez reconfiguré le système entre temps.

list-generations

Affiche un résumé de chaque génération du système d’exploitation disponible sur le disque, dans un format lisible pour un humain. C’est similaire à l’option --list-generations de guix package (voir Invoquer guix package).

Éventuellement, on peut spécifier un motif, avec la même syntaxe utilisée pour guix package --list-generations, pour restreindre la liste des générations affichées. Par exemple, la commande suivante affiche les générations de moins de 10 jours :

$ guix system list-generations 10d

Le drapeau --list-installed peut aussi être spécifié, avec la même syntaxe que celle utilisée dans guix package --list-installed. Cela peut être utile si vous essayez de déterminer si un paquet a été ajouté au système.

La commande guix system a même plus à proposer ! Les sous-commandes suivantes vous permettent de visualiser comme vos services systèmes sont liés les uns aux autres :

extension-graph

Émettre vers la sortie standard le graphe d’extension de service du système d’exploitation défini dans file (voir Composition de services, pour plus d’informations sur les extensions de service). Par défaut, le format de sortie est le format Dot/Graphviz, mais vous pouvez choisir un autre format avec --graph-backend, comme avec guix graph (voir --backend) :

La commande :

$ guix system extension-graph file | xdot -

montre les relations d’extension entre les services.

Remarque : Le programme dot est fournit par le paquet graphviz.

shepherd-graph

Affiche le graphe de dépendance des services shepherd du système d’exploitation défini dans file sur la sortie standard. Voir Services Shepherd, pour plus d’informations et un exemple de graphe.

Encore une fois, le format de sortie par défaut est Dot/Graphviz, mais vous pouvez passer --graph-backend pour en choisir un autre.