Découverte de GNU GuixSD

Dans un précédent article, j’avais expliqué (et tenté de justifier) ma migration vers la distribution GNU GuixSD sur mon ordinateur personnel.

Dans cet article, je vais tenter de décrire comment j’ai installé cette distribution, comment je l’ai configurée et quelles ont été mes impressions.

Mon ordinateur personnel est un Dell Precision M4400.

Installation

J’ai suivi les instructions données dans le manuel. La procédure n’est pas trop compliquée pour peu qu’on ait une connaissance minimale de la ligne de commande.

J’ai opté pour la version 0.15 (dernière version en date au moment de mon installation) en 64 bits (x86_64).

Comme je m’y attendais, mon adaptateur Wifi n’est pas supporté. J’ai donc dû tirer un câble Ethernet pour avoir accès à Internet.

Ce qui était moins prévisible, c’est que je suis tombé au moment où le dépôt principal des paquets binaires (appelés substituts dans Guix), hydra.gnu.org, était indisponible pour maintenance et que le seul miroir disponible, berlin.guixsd.org, était instable. Cela a pas mal compliqué l’installation et j’ai dû m’armer de patience avant de pouvoir aller jusqu’à la fin de la procédure.

C’est pourquoi je suis parti sur la configuration système la plus simple, dite bare bones, dont le modèle est fourni sur le support d’installation. Cette version du système ne contient pas d’environnement graphique.

Au redémarrage, nous arrivons sur un menu de GNU GRUB avec le logo Guix (une tête de gnou stylisée) en fond. C’est plutôt propre.

Le démarrage du système se fait par contre en mode texte. C’est moins beau mais on voit ce qui s’y passe. Cela ne me dérange pas.

Configuration post-installation

Une fois avoir démarré sur le système fraîchement installé, j’ai commis une grave erreur en voulant immédiatement lancer une reconfiguration du système (guix system reconfigure) afin d’améliorer quelques aspects. C’est une erreur car cela a pour conséquence d’appliquer un downgrade du système ! Le manuel consielle pourtant fortement de mettre à jour GNU Guix en fin d’installation et GNU Guix m’a bien donné un avertissement mais j’ai passé outre. Le pire, c’est que j’ai lancé la re-configuration plusieurs fois, appliquant à chaque fois un downgrade ! Pourquoi ce comportement ? J’ai trouvé une réponse sur la liste de diffusion du projet mais je dois avouer ne pas trop la comprendre.

Quoi qu’il en soit, il est important de suivre jusqu’au bout les instructions du manuel et de lancer une mise à jour de GNU Guix (guix pull) avant toute autre chose.

À partir de là, j’ai pu amélioré correctement ma configuration petit à petit et la peaufiner jusqu’à l’obtention d’un système entièrement fonctionnel.

Dans la suite de cet article, je vais détailler comment j’ai obtenu cette configuration.

Adaptateur Wifi

Matériel : Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b]

Comme le microcode (firmware) disponible pour cette puce n’est pas libre, il n’est pas inclus dans le noyau Linux-libre. De toute façon, la documentation officielle du noyau Linux indique que le support pour cette puce est partielle et les différents essais que j’avais faits sous Salix n’avaient pas été concluants.

Je me suis donc rabattu, une fois de plus, sur le pilote propriétaire, appelé Linux STA driver et matérialisé par un module noyau nommé wl.

Je me suis, pour cela, lancé dans la création d’un paquet Guix pour ce pilote (disponible ici).
Pour l’intégrer au noyau, j’ai également dû créer un autre paquet Guix qui regroupe le noyau Linux-libre et le pilote (disponible ici).

Ce paquet de noyau modifié doit être référencé dans la configuration du système :

  (operating-system
    (kernel linux-libre+broadcom-sta-x86_64)

Je dois dire que j’ai pas mal galéré pour faire ces deux paquets mais le résultat est que je ne dois (presque) plus me soucier des mises à jour de noyau. À la mise à jour du système, le pilote propriétaire ainsi que le noyau modifié sont ré-empaquetés puis installés automatiquement. Et, avec GNU Guix, si quelque chose échoue lors de ce processus, rien n’est modifié sur le système. Si le résultat n’est pas satisfaisant, la version précédente du système est disponible dans GNU GRUB.

Environnement graphique

Afin de profiter d’un environnement graphique, j’ai d’abord changé la configuration du système en prenant le modèle d’une configuration dite desktop. Celle-ci active plusieurs services de base, dont le gestionnaire de connexions SLiM. Une fois cette configuration appliquée, le gestionnaire de connexions est apparu automatiquement, avec, encore une fois, une tête de gnou stylisée. Je trouve que c’est du plus bel effet.

Ensuite, j’ai créé un paquet avec la dernière version le gestionnaire de fenêtres Notion, que j’utilise depuis de nombreuses années déjà. Le paquet est disponible ici. Il est fondé sur l’excellent paquet créé par Jeff Mickey.
Après avoir installé Notion en tant que simple utilisateur, je l’ai référencé dans mon fichier ~/.xsession :

  exec notion

J’ai eu quelques soucis à récupérer ma configuration de Notion, dûs aux chemins non standard des logiciels installés, mais j’ai finalement obtenu un environnement graphique dans lequel je me sentais à l’aise.

Disposition de clavier BÉPO

Je suis habitué à la disposition de clavier BÉPO. L’activer a été une de mes premières tâches.

Comme presque toujours dans GNU Guix, cela passe par le fichier de configuration du système :

(define bepo-evdev
  "Section \\"InputClass\\"
          Identifier \\"evdev keyboard catchall\\"
          Driver \\"evdev\\"
          MatchIsKeyboard \\"on\\"
          Option \\"xkb_layout\\" \\"fr\\"
          Option \\"xkb_variant\\" \\"bepo\\"
  EndSection")

...

(operating-system

  ...

  (services (cons (console-keymap-service "fr-bepo")
    (modify-services %desktop-services
      (slim-service-type config =>
        (slim-configuration
          (inherit config)
          (startx (xorg-start-command
            #:configuration-file
              (xorg-configuration-file
                #:extra-config
                (list bepo-evdev)))))))))

...)

L’entrée console-keymap-service permet de charger une disposition de clavier pour la console.
Tout le reste permet de changer la disposition de clavier dès le démarrage du gestionnaire de connexions SLiM.

Je trouve un peu dommage qu’une chose basique comme la disposition de clavier ne puisse pas être changée plus facilement.

Gestion des paquets

Au fur et à mesure de ma découverte du système, j’ai installé quelques paquets en tant qu’utilisateur régulier.

J’essaie de limiter le nombre de paquets installés au niveau système à son strict minimum. Pour les programmes que j’utilise régulièrement, j’installe les paquets en tant qu’utilisateur régulier.

Pour installer un paquet, il suffit de taper :

  guix package -i <nom du paquet>

Le paquet ainsi que tous les paquets dépendants sont automatiquement téléchargés et installés dans le profil de l’utilisateur. Si un paquet binaire (appelé substitut) n’est pas disponible (cela peut arriver), les sources sont téléchargées et le paquet binaire est construit puis installé. À ce propos, il faut noter l’option -n (–dry-run), qui permet de voir préalablement ce qui sera téléchargé et ce qui sera construit. Ainsi, cela donne une idée de l’effort à fournir pour installer le paquet.

Chaque opération (ajout, suppression, mise à jour) peut prendre du temps car une nouvelle version du profil est créée à chaque fois.

Pour voir tous les paquets installés dans un profil, il suffit de taper :

  guix package -I

Ceci ne liste que les paquets qui ont été explicitement installés, et pas les paquets dépendants.

Si on désinstalle un paquet (guix package -r <nom du paquet>), les paquets dépendants seront également supprimés du profil.

Comme pour les paquets au niveau système, j’essaie de limiter les paquets installés au niveau utilisateur en gardant les paquets que j’utilise quotidiennement.

Lorsque je souhaite tester un logiciel ou que j’ai besoin d’un paquet ou d’un ensemble de paquets pour une tâche ponctuelle, j’ai pris l’habitude d’utiliser guix environment. Par exemple, si je veux travailler sur un projet de développement en OCaml qui utilise Mercurial, je vais lancer la commande suivante :

  guix environment --ad-hoc ocaml mercurial

Ceci lance un shell avec un profil Guix dans lequel les commandes ocaml (du paquet du même nom) et hg (du paquet mercurial) sont disponibles. À la fin de ma session de travail, je quitte simplement ce shell. Ainsi, mon profil principal n’est pas touché et je n’y accumule pas des dizaines d’outils.

En ajoutant le fait que les opérations se font de manière transactionnelle, je trouve que GNU Guix propose à l’utilisateur une façon assez propre de gérer les paquets.

Mise à jour du système

Afin de mettre de mettre à jour le système et les logiciels qui y sont installés, il est nécessaire de mettre à jour GNU Guix lui-même ainsi que la définition des paquets. Cela se fait par la commande suivante :

  guix pull

Ici, j’ai pu noter deux écueils :

• même si je sais que les développeurs ont travaillé sur ce point lors des derniers mois, cette opération peut être assez longue (plusieurs minutes) ;
• cette opération doit être effectuée pour chaque utilisateur du système.

Une fois cette opération terminée, une re-configuration du système peut être effectuée (guix systeme reconfigure) ou tous les paquets installés peuvent être mis à jour (guix package -u).

Ainsi, pour mettre à jour un système (somme toute classique de nos jours) utilisé par un seul utilisateur, il faut lancer 5 commandes :

• en tant qu’administrateur (root) :

      guix pull
      guix system reconfigure
      guix package -u

• en tant qu’utilisateur régulier :

      guix pull
      guix package -u

C’est un peu lourd (chacune de ces opérations pouvant prendre un certain temps). Néanmoins, c’est, d’une certaine manière, le prix à payer pour tous les avantages apportés par GNU Guix (transaction, gestion de paquets par utilisateur…).

Nettoyage du système

Toutes ces mises à jour et créations de profil laissent des paquets (ou des anciennes versions de paquets) présents sur le système, sans qu’ils soient utilisés. Cela peut prendre pas mal de place sur le système de fichiers. Et cela peut même finir par saturer l’espace disponible. C’est ce qui m’est arrivé.

Pour cela, il y a la possibilité de lancer un ramasse-mièttes via la commande guix gc.

Malheureusement, cette commande, lancée sans paramètre particulier, échoue sur mon système avec le message d’erreur suivant :

  guix gc: error: build failed: executing SQLite statement: FOREIGN KEY constraint failed

Si vous avez également cette erreur, il y a une bonne et une mauvaise nouvelles.

La mauvaise nouvelle, c’est que, sur la liste de diffusion d’assistance aux utilisateurs, les experts de GNU Guix sont formels : une manipulation manuelle a été faite dans le dépôt de paquets, ce qui l’a rendu incohérent. Et, pour résoudre cette erreur, il n’y a pas d’autres choix que de réinstaller le système… Pourtant, je suis presque sûr de ne pas avoir touché quoique ce soit dans ce dépôt de paquets…

La bonne nouvelle, c’est qu’il existe une solution de contournement à ce problème (la seule que j’ai trouvée). Elle consiste à supprimer un paquet en particulier. En choisissant un paquet volumineux (par exemple, le noyau Linux) ou sur lequel il y a beaucoup de dépendances (par exemple, une librairie comme glib), l’espace gagné peut être assez conséquent.
Pour cela, je lance d’abord la commande suivante :

  guix gc --list-dead

Ceci liste les paquets inutilisés.

Il suffit alors de choisir judicieusement un paquet dans la liste puis de lancer la commande suivante :

  guix gc -D <chemin du paquet>

Par exemple :

  guix gc -D /gnu/store/yrq6wh410fabc4jsvg7rzpm3jp39myj8-gtk+-3.24.0

On peut facilement gagner des centaines de Mio.

Mozilla Firefox et Thunderbird

Je suis habitué à Mozilla Firefox et Thunderbird. Ces deux logiciels sont malheureusement absents des paquets disponibles. C’est un point qui m’a fait longtemps hésiter à passer sur cette distribution.

En remplacement de Mozilla Firefox, l’équipe Guix fait la promotion de GNU Icecat. Je l’ai essayé mais je n’ai pas aimé le simple fait qu’il soit fourni avec tout un tas d’extensions par défaut, certaines étant spécifiques à certains sites Web. J’ai donc assez rapidement passé mon chemin, même si j’essaie de le garder au cas où j’en aurais besoin.

Devant l’absence de paquets Guix pour Mozilla Firefox et Thunderbird, j’ai décidé d’en créer moi-même. Celui pour Mozilla Firefox est disponible ici. Celui pour Thunderbird est disponible là. Ce sont pour l’instant des anciennes versions ESR (versions 52) mais je compte migrer vers les dernières versions ESR dans un futur proche.

N’ayant ni les capacités matérielles ni le temps pour compiler ces logiciels, j’ai choisi de créer des paquets à partir des versions binaires officielles, telles que fournies par Mozilla. Pour réaliser ces paquets, je me suis fondé sur l’astuce donnée par Solène Rapenne sur son blog. Elle consiste à lancer un binaire pré-compilé via l’éditeur de lien (ld-linux-x86-64.so.2) en prenant soin de préciser toutes les dépendances logicielles dans une variable d’environnement LD_LIBRARY_PATH.

Le résultat fonctionne plutôt bien, y compris le son (via pulseaudio) et la vidéo (via ffmpeg).

Le seul problème rencontré est que Mozilla Firefox ne fonctionne pas en mode multi-processus. Il faut donc le désactiver en mettant les propriétés browser.tabs.remote.autostart et browser.tabs.remote.autostart.2 à false dans about:config. Je n’ai pas trouvé d’alternative mais j’espère que le problème disparaîtra en passant à une version supérieure.

Numérisation de documents

Matériel : Canon Pixma MP450

Je souhaitais numériser des documents avec mon imprimante-scanner, connectée au port USB.

J’ai d’abord installé le paquet sane-backends en tant qu’utilisateur mais le scanner n’était pas reconnu.

Le problème était l’accumulation de trois causes :

1. Le fichier périphérique (/dev/…) pas n’était créé. Le paquet contient bien des règles udev qui rend le scanner disponible pour les applications. Cependant, il est impératif (et assez logique) d’installer le paquet au niveau système afin que ces règles udev soient utilisables.
2. Étrangement, le paquet officiel ne supporte pas le protocole USB. J’ai dû créer mon propre paquet afin d’activer le support USB.
3. Le groupe lp était manquant au niveau de mon compte utilisateur afin de donner accès au fichier périphérique créé par les règles udev. Ceci doit être fait au niveau de la configuration système.

Une fois toutes les actions prises, le scanner a fonctionné comme attendu.

Son

Matériel : Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e]

Le contrôleur est bien reconnu et la gestion du son fonctionne de base avec une configuration dite desktop (liste de services %desktop-services dans la configuration système). C’est le couple ALSA + PulseAudio qui fait fonctionner le tout.

Pour régler le volume, le paquet pavucontrol peut être installé. De base, de nombreuses icônes sont absentes. Ceci peut être réglé en installant le paquet gnome-icon-theme.

C’est aussi avec pavucontrol qu’on peut activer le microphone (dans l’onglet Configuration, choisir le profil Duplex stéréo analogique).

Batterie et gestion de l’énergie

Lorsqu’on utilise un ordinateur portable, avoir le niveau de la batterie est quasiment indispensable. J’avais l’habitude d’utiliser une extension Notion appelée linuxbatt. Cependant, j’ai remarqué que celle-ci ne fonctionnait plus sous GNU GuixSD car l’interface /proc/acpi/battery n’existe plus.

Ceci est probablement lié à la version du noyau mais c’est maintenant l’interface /sys/class/power_supply qui fournit les informations sur le niveau de la batterie. J’ai adapté l’extension linuxbatt en conséquence et je l’ai proposée au mainteneur de Notion, qui l’a acceptée. La nouvelle version est disponible ici.

Cette nouvelle interface me paraît plus précise. Lorsque la batterie est totalement chargée, elle me présente un niveau de 100 % alors que l’ancienne interface me donnait un niveau de 139 %…

La mise en veille (appelée aussi suspend-to-ram) fonctionne généralement bien, aussi bien que sous Salix en tout cas. Sans que je n’ai eu besoin de configurer quoi que ce soit, l’appui sur la touche Lune (Fn + F1) provoque la mise en veille. Il en est de même lorsque je rabats l’écran de l’ordinateur (bouton lid).

Comme attendu, l’appui sur le bouton d’alimentation (On/Off) provoque l’arrêt du système.

Tout ceci est principalement dû à l’utilisation de elogind, qui est un service extrait de systemd pour les besoins de GNU Guix.

Par contre, j’ai découvert avec grande déception que GNU GuixSD ne supporte pas l’hibernation (appelée aussi suspend-to-disk) pour l’instant. Sur Salix, je l’utilisais tout le temps. Je me suis fait à l’absence d’hibernation et ce ce n’est, en fin de compte, pas plus mal car j’avais tendance à accumuler des terminaux de console, des onglets dans Mozilla Firefox, etc.

Démarrage et arrêt du système

Le système met environ 1 minute à démarrer, du programme d’amorçage (GNU GRUB) jusqu’à l’affichage du gestionnaire de connexions (SLiM). Je pense que c’est plutôt long. Cela ne me dérange pas trop mais je sais que c’est un critère important pour d’autres.

Une fois que le système a démarré et que je me connecte, la quantité de mémoire utilisée est de moins de 200 Mo.

L’extinction du système est assez rapide (quelques secondes).

GnuPG et password-store

J’ai eu quelques soucis avec GnuPG et password-store, comme je l’expliquais dans un précédent article.

En fait, le principal problème que j’ai eu est dû au fait que le chemin par défaut du pinentry défini dans le paquet Guix de GnuPG n’existe pas et ne peut pas exister. Je suis arrivé à la conclusion qu’il n’y a pas d’autres choix que de spécifier le chemin d’un pinentry dans ~/.gnupg/gpg-agent.conf. Voici le contenu de ma configuration :

  pinentry-program /home/julien/.guix-profile/bin/pinentry

Ceci fait référence à un pinentry (paquet pinentry-gtk2) que j’ai installé en tant qu’utilisateur.

Clés USB, cartes SD et autre media amovibles

Mes media amovibles ont été reconnus par le système. De ce point de vue, je n’ai pas eu de problème particulier.

Par contre, j’ai voulu autorisé un utilisateur régulier à monter ces media amovibles et c’est là que les choses se sont compliquées.

J’ai d’abord déclaré le système de fichiers des media dans la configuration du système avec des entrées comme celle-ci :

  (file-system
     (mount-point "/media/inkpad")
     (device (file-system-label "PB840"))
     (type "auto")
     (options "noatime,noauto,user")
     (mount? #f) ;; pas de montage au démarrage du système
     (create-mount-point? #t))

Ici, je déclare un point de montage (/media/inkpad) associé à un système de fichiers d’un medium via son étiquette (PB840). Je laisse le système détecter le type de système de fichiers (option auto). Je m’assure que le système n’essayera pas de monter le système de fichiers automatiquement (option noauto et entrée mount désactivée). Enfin je précise que n’importe quel utilisateur régulier est autorisé à monter et démonter ce système de fichiers (option user).

D’après la documentation, l’entrée create-mount-point permet de créer le point de montage si il n’existe pas. Or, lorsque j’ai appliqué cette configuration, le point de montage n’a pas été créé. Pourquoi ? Est-ce un bug dans GNU Guix ? Je ne sais pas. Dans tous les cas, j’ai trouvé cela un peu dommage et je me suis résigné à créer ce point de montage par moi-même (ce qui n’est pas insurmontable, il faut le dire).

Ensuite, j’ai tenté de monter le système de fichiers en tant qu’utilisateur régulier :

  mount /media/inkpad

La commande a échoué avec le message suivant :

  seul le superutilisateur peut utiliser mount

J’ai beaucoup cherché une solution à ce problème. La seule solution trouvée a été de rendre l’exécutable mount (ainsi que umount) setuid (ajout du bit « Set user id) afin de permettre son exécution avec les permissions de l’utilisateur root. J’ai, pour cela, ajouté ceci dans la configuration du système :

  (setuid-programs (cons* #~(string-append #$util-linux "/bin/mount")
                          #~(string-append #$util-linux "/bin/umount")
                          %setuid-programs))

Je n’avais pas besoin de rendre ces utilitaires setuid dans Salix. Était-ce par défaut le cas ?
Y a-t-il une solution à la fois plus simple et plus sûr pour permettre un utilisateur régulier de monter un système de fichiers d’un medium amovible ? Je n’en ai pas vraiment trouvé.

Lecteur de cartes à puce et carte eID belge

Mon ordinateur portable est équipé d’un lecteur intégré de cartes à puce et je suis le détenteur d’une carte d’identité électronique belge (eID). J’ai souhaité utiliser cette carte pour me connecter à un service public belge.

Pour cela, j’ai installé les paquets pcsc-lite (integiciel ou middleware du lecteur de cartes à puce), ccid (pilote ou driver du lecteur de cartes à puces) et eid-mw (integiciel ou middleware de la carte eID) au niveau système, via le fichier de configuration du système.

Le démon pcscd n’était pas disponible en tant que service système (il semble que cela soit le cas maintenant). Je dois donc le lancer manuellement en tant que root.

Le démon cherche les pilotes dans le chemin /var/lib/pcsc. Bizarrement, ce chemin n’existe pas et le lecteur n’est pas reconnu. J’ai été contraint de créer ce chemin en créant un lien symbolique vers /run/current-system/profile/pcsc. Était-ce la bonne façon de faire ? Je crains que non car l’idée de GNU GuixSD est de toujours passer par le fichier de configuration du système.

Toujours est-il que, une fois ce lien symbolique créé, le démon pcscd a pu être exécuté sans erreur particulière.

Le paquet eid-mw contient également eID Viewer. Il s’agit d’un logiciel qui permet de lire le contenu de la carte eID. C’est généralement un bon point de départ pour vérifier que le système reconnait le lecteur de cartes et la carte elle-même, ce qui a été le cas pour moi.

Je n’ai pas réussi à utiliser la carte eID avec mon installation de Mozilla Firefox 52. Par contre, j’ai réussi à l’utiliser avec GNU Icecat, après avoir installé l’extension et après avoir chargé le module PKCS#11 Belgium eID (comme indiqué dans la rubrique Questions et Réponses).

Paquets personnels

J’ai créé quelques paquets pour un certain nombre de logiciels. En plus de ceux déjà indiqués plus haut, il y a notamment :

• Qalculate!, une calculatrice disponible en ligne de commandes et en interface graphique (paquets disponibles ici) ;
• asciidoctor, un outil de conversion de documents au format asciidoc (paquet disponible ici) ;
• RPhoto, un excellent logiciel de traitement de photos numériques (paquet disponible ici) ;
• pulseaudio-ctl un outil de contrôle du volume du son avec notifications (paquet disponible ici) ;
• Textadept, un éditeur de texte configurable (paquet disponible ici).
• txt2tags, un générateur de documents à partir d’un langage de balisage léger et simple (paquet disponible ici).

Les définitions des paquets sont écrites en Scheme, un dialecte du Lisp. Pour moi, cela a été l’occasion de découvrir cette famille de langages. La syntaxe (connue pour l’utilisation massive de parenthèses) est un peu déroutante. Même si je suis plutôt adepte des langages fonctionnels, je reste un peu mitigé.

Une section du manuel est consacrée à la création de paquets. Un très bon tutoriel existe également. En consultant avec attention ces deux ressources, mais aussi en parcourant les définitions des paquets officiels, on peut arriver à créer ses propres paquets.

Conclusion

Je n’ai pas tout testé (je pense en particulier à l’impression) mais je suis arrivé à un système fonctionnel et c’est ce qui est le plus important pour moi. La configuration de mon système est disponible sur mon compte Bitbucket.

Ce qui est bien, c’est que, si j’étais amené à réinstaller le système, je pourrais théoriquement repartir de cette configuration dès l’installation et je devrais obtenir un système identique.

Je suis globalement satisfait de cette distribution. Certains aspects sont un peu déroutants et peut causer quelques soucis (chemins non standard dans le système de fichiers, lourdeur des opérations Guix) mais je crois, pour l’instant, que les bénéfices apportés (mise à jour transactionnelle, gestion souple des paquets…) surpassent ces contraintes.

J’ai aussi l’impression d’utiliser la « distribution du futur » ou, en tout cas, l’embryon de ce que pourrait être l’avenir d’une distribution Linux.

Dans un prochain article, je résumerai la compatibilité de mon ordinateur avec le système GNU GuixSD.