Mots-Clés ‘Linux’

GNU GuixSD 0.16 sur Dell Precision M4400

Jeudi 21 mars 2019

Dans un précédent article, j’ai décrit ma découverte de la distribution GNU GuixSD.

Dans cet article, je vais résumer, comme je l’avais fait avec la distribution Salix, la compatibilité de la distribution GNU GuixSD, en version 0.16, avec mon ordinateur, un Dell Precision M4400 :

Photo de l’ordinateur portable Dell Precision M4400
Affichage
Matériel : WUXGA 39 cm (15,4″) 2CCFL (résolution de 1920 x 1200 pixels) + NVIDIA Corporation G96GLM [Quadro FX 770M] [10de:065c]
Compatibilité : OK, avec le pilote nouveau.
Interface Ethernet
Matériel: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5]
Compatibilité : OK.
Inferface Wifi
Matériel : Broadcom Limited BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b]
Compatibilité : OK, avec le pilote propriétaire (module noyau wl), après installation du paquet linux-libre+broadcom-sta-x86_64 (combinant le pilote propriétaire avec le noyau Linux-libre).
Interface Bluetooth
Compatibilité : non testée.
Interface 3G (UMTS)
Compatibilité : non testée.
Clavier
Matériel : AT Translated Set 2 keyboard
Compatibilité : OK, avec les trois touches de contrôle du volume reconnues comme des touches multimédia standard dans X.org (XF86AudioLowerVolume, XF86AudioRaiseVolume, XF86AudioMute).
Pavé tactile
Matériel : AlpsPS/2 ALPS DualPoint TouchPad
Compatibilité : OK, sauf tap (problème qui semble assez fréquent) et défilement horizontal.
Bouton de pointage (trackpoint)
Matériel : AlpsPS/2 ALPS DualPoint Stick
Compatibilité : OK.
Son
Matériel : Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e]
Compatibilité : OK pour haut-parleurs et micro intégré ; non testée pour sortie casque et entrée micro.
Caméra
Matériel : Microdia Integrated Webcam [0c45:63f1]
Compatibilité : OK.
Batterie
Compatibilité : OK (pleine charge bien indiquée à 100 %).
CD/DVD
Compatibilité : non testée.
Interface avec cartes mémoire
Matériel : Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822]
Compatibilité : OK (testée seulement avec une carte SD, seulement en lecture).
Interface USB
Compatibilité : OK (testée avec une souris USB, une clé USB et un lecteur de livres électroniques).
Interface eSATA
Compatibilité : non testée.
Interface Firewire
Matériel : Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832]
Compatibilité : non testée.
Lecteur d’empreintes digitales
Matériel : Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor [0a5c:5801]
Compatibilité : non testée.
Lecteur de cartes à puce (PC/SC)
Matériel : Ricoh Co Ltd RL5c476 II [1180:0476]
Compatibilité : OK, après installation des paquets pcsc-lite et ccid.
Lecteur de cartes sans contact
Compatibilité : non testée.
Boutons de gestion d’alimentation
Compatibilité : OK pour touche Lune (Fn + F1), ouverture et fermeture du couvercle (bouton lid) et bouton d’alimentation (On/Off).
Lecteur de cartes d’extension (ExpressCard 54, PCMCIA)
Compatibilité : non testée.
Interface pour station d’accueil
Compatibilité : non testée.
Interface avec moniteur (VGA, DisplayPort)
Compatibilité : non testée.

Comme vous pouvez le constater, je n’ai pas eu l’occasion de tout tester, mais les fonctionnalités essentielles sont opérationnelles, et la plupart le sont dès l’installation de la distribution. Si vous avez une question concernant cet ordinateur et sa compatibilité avec Linux, n’hésitez pas me contacter via les commentaires.

Découverte de GNU GuixSD

Mercredi 20 mars 2019

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.

Logo de GuixSD

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 . 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.

Passage à GNU GuixSD

Mardi 19 mars 2019

Il y a quelques semaines, j’ai décidé d’installer GNU GuixSD sur mon ordinateur personnel, en remplacement de Salix.

Dans cet article, je vais tenter de présenter cette distribution atypique et expliquer mes motivations à l’installer.

Logo de GuixSD

Abandon de Salix

Avant tout, j’aimerais indiquer les raisons qui m’ont poussé à abandonner Salix.

J’ai installé Salix en 2012, il y a donc plus de 6 ans (le système s’appelait Salix OS initialement). J’avais décrit mes impressions dans un article. À l’époque, c’était la version 13.37. J’ai ensuite migré vers la version 14.0, puis vers la version 14.1 et enfin vers la version 14.2.

Logo de Salix

J’ai eu quelques surprises ici et lors de migrations mais le système était globalement très stable. J’ai apprécié la base Slackware Linux et la possibilité de migrer à son rythme.

Seulement voilà, au bout des années, je commençais à avoir quelques reproches :

  • Mozilla Firefox était devenu instable (c’était encore la version ESR 52). Il prenait beaucoup de mémoire et plantait très souvent. Ce n’est pas sûr que ce problème soit vraiment lié à la distribution mais je devais changer de distribution pour le vérifier.
  • L’installation d’un paquet était un peu laborieuse. Il faut d’abord lancer slapt-get pour chercher si un paquet binaire existe. S’il n’existe pas, il faut ensuite lancer slapt-src pour chercher si un SlackBuild (la recette de construction d’un paquet binaire) existe. Si il existe, la construction est lancée mais les dépendances peuvent manquer. On installe alors les dépendances puis on relance la construction. Si le SlackBuild n’est pas disponible, ce qui était devenu pour moi assez fréquent, on doit chercher un SlackBuild sur Internet ou prendre son courage à deux mains et construire un SlackBuild ou un SLKBUILD (une recette simplifiée de construction de paquets binaires) soi-même.
  • Les mises à jour de noyau Linux étaient toujours un peu galère car je me retrouvais sans connexion Wifi et avec la nécessité de réappliquer la procédure de réinstallation du pilote propriétaire de l’adapatateur Wifi.

Mais toutes ces raisons ne sont en réalité que des fausses excuses. En vérité, j’avais surtout envie de voir autre chose. J’avais découvert les gestionnaires de paquets Nix et GNU Guix. Je les avais installés sur le système Salix, en complément du gestionnaire de paquets du système (et pour palier le manque de paquets). J’ai adhéré au concept et je souhaitais aller un pas plus loin en installant un système fondé sur ce type de gestionnaire de paquets.

Présentation de GNU Guix et GuixSD

Mais qu’est-ce que GNU Guix et GuixSD ?

GNU Guix est un gestionnaire de paquets avancé qui ne se limite pas à la simple maintenance de logiciels installés sur un système.

Logo de GNU Guix

Tout d’abord, il permet à un utilisateur ordinaire d’installer des logiciels sans être administrateur. L’intérêt est limité pour moi puisque j’ai naturellement accès au compte root mais je trouve que la fonctionnalité est assez sympathique. Et puis, si on peut éviter de se connecter en tant qu’administrateur, c’est toujours préférable.

Ensuite, GNU Guix permet de se créer des environnements personnalisés, dans lequel on peut installer un ensemble de logiciels dans des versions précises, sans toucher aux logiciels installés sur le système. C’est particulièrement intéressant lorsqu’on fait du développement logiciel et qu’on a besoin de bibliothèques dans des versions spécifiques ou dans plusieurs versions (pour tester). Ludovic Courtès, un des développeurs principaux de GNU Guix, explique très bien cet aspect dans deux articles publiés dans GNU/Linux Magazine (disponibles ici et ).

Enfin, GNU Guix est utilisé comme base de la distribution GNU GuixSD dans le sens où il permet la construction d’un système d’exploitation. La configuration du système (noyau à utiliser, systèmes de fichier, services disponibles, logiciels installés de base…) est décrite dans un seul fichier élémentaire, que GNU Guix utilise pour construire ou mettre à jour un système d’exploitation, et tout ceci de manière transactionnelle (si une mise à jour échoue en plein milieu, aucun changement n’est appliqué sur le système) et versionnée (si la nouvelle configuration ne fonctionne pas, ou moins bien, on peut revenir à la version précédente du système).

N’est-ce pas impressionnant tout cela ?

Plus concrètement, GNU GuixSD est une distribution qui permet d’installer un système d’exploitation i686 (32 bits) et x86_64 (64 bits) avec une base GNU et le noyau Linux-libre. Elle présente plus de 9000 paquets logiciels. Ils sont tous entièrement libres et ne présentent en particulier aucun microcode (firmware), ce qui explique le choix du noyau Linux-libre. Ce dernier point est un peu contraignant car il limite assez fort le nombre d’adaptateurs Wifi pouvant fonctionner avec la distribution fournie. Il est cependant possible, moyennant quelques efforts, de passer outre cette limitation, comme je l’expliquerai dans un prochain article. Il est à noter que c’est le gestionnaire de services GNU Shepherd qui est utilisé (donc pas de systemd ici).

Motivations du choix de GNU GuixSD

Alors, pourquoi avoir choisi GNU GuixSD ? Eh bien pour les raisons suivantes :

  • les possibilités offertes par le gestionnaire de paquets GNU Guix et, en particulier, la possibilité de se créer des environnements personnalisés ;
  • la garantie d’avoir une base entièrement libre ;
  • l’absence de systemd (dont je n’apprécie pas la conception) ;
  • l’aspect innovant de la distribution et du gestionnaire de paquets.

Dans un prochain article, je détaillerai ma découverte de cette distribution.

Numérisation de documents sous Linux : résoudre le problème du fond grisé

Samedi 8 septembre 2018

Depuis quelques années, je peaufine un script shell qui me permet de faire des numérisations de documents administratifs (formulaires à renvoyer, documents reçus par la poste…) au format A4. Ce script utilise scanimage, un outil en ligne de commande du projet SANE.

Le script permet de lancer une numérisation en noir et blanc par lot, avec contrôle de la numérisation de chacune des pages avec les boutons du scanner, puis de convertir et fusionner tous les documents numérisés dans un fichier PDF.

J’en suis assez content. Seulement voilà, avec le scanner que j’utilise (Canon Pixma MP450, une imprimante-scanner), le résultat de la numérisation est décevant.

Voici un exemple avec la commande suivante :
scanimage –device pixma –resolution 150 –mode Gray -l 0 -t 0 -x 210 -y 297 >image.pnm

J’ai alors ce résultat (après conversion en PNG) :
Numérisation de documents sous Linux : résoudre le problème du fond grisé dans Planet Libre page_scanimage_options_defaut-723x1024

Comme on peut le voir, le fond est grisé (alors que le document papier a bien un fond blanc). Selon la qualité du papier, il arrive même que le verso du document soit visible.

J’avais déjà essayé de changer certains réglages mais sans succès.

Je me suis donc décidé à prendre le problème au sérieux et de lui trouver une solution.

Après quelques recherches, je comprends qu’il me faudrait régler la luminosité utilisée lors de la numérisation. Cela se fait généralement avec l’option –brightness dans scanimage. Le problème est que cette option n’est pas disponible pour le scanner Canon Pixma MP450, comme le montre le résultat de la commande scanimage -d pixma -h :

Options specific to device `pixma’:
Scan mode:
–resolution auto||75|150|300|600|1200dpi [75]
Sets the resolution of the scanned image.
–mode auto|Color|Gray|Lineart [Color]
Selects the scan mode (e.g., lineart, monochrome, or color).
–source Flatbed [Flatbed]
Selects the scan source (such as a document-feeder). Set source before
mode and resolution. Resets mode and resolution to auto values.
–button-controlled[=(yes|no)] [no]
When enabled, scan process will not start immediately. To proceed,
press « SCAN » button (for MP150) or « COLOR » button (for other models).
To cancel, press « GRAY » button.
Gamma:
–custom-gamma[=(auto|yes|no)] [yes]
Determines whether a builtin or a custom gamma-table should be used.
–gamma-table auto|0..255,…
Gamma-correction table.  In color mode this option equally affects the
red, green, and blue channels simultaneously (i.e., it is an intensity
gamma table).
–gamma auto|0.299988..5 [2.2]
Changes intensity of midtones
Geometry:
-l auto|0..216.069mm [0]
Top-left x position of scan area.
-t auto|0..297.011mm [0]
Top-left y position of scan area.
-x auto|0..216.069mm [216.069]
Width of scan-area.
-y auto|0..297.011mm [297.011]
Height of scan-area.
Buttons:
–button-update
Update button state
Extras:
–threshold auto|0..100% (in steps of 1) [inactive]
Select minimum-brightness to get a white point
–threshold-curve auto|0..127 (in steps of 1) [inactive]
Dynamic threshold curve, from light to dark, normally 50-65

Après plusieurs tâtonnements et investigations, je comprends que je dois jouer avec le gamma. Le gros problème, c’est que je ne sais pas ce qu’est un gamma et encore moins une table de gamma. Je crois comprendre qu’il permet d’indiquer comment l’intensité d’un point numérisé doit être traduit en niveau de gris (ou en couleur) mais cela reste assez obscur pour moi. Je remercie par avance celui ou celle qui pourra m’éclairer sur le sujet en commentaires.

J’essaie les différents modes auto mais cela ne donne pas ou peu de changements. Puis j’essaie les différentes valeurs de l’option –gamma. Cela a bien une influence mais le résultat n’est toujours pas satisfaisant.

Mon dernier recours est alors de spécifier une table de gamma personnalisée (avec l’option –gamma-table). L’outil scanimage attend, pour cela, une suite de nombres. C’est plutôt abscons pour moi.

Heureusement, le projet SANE fournit un outil permettant de générer cette suite de nombres : gamma4scanimage.

L’outil attend cinq paramètres : gamma, shadow, highlight, maxin et maxout. Voilà ce que j’ai compris :

  • gamma prend les mêmes valeurs que l’option –gamma de scanimage; plus la valeur est grande, plus il y a de la luminosité ;
  • maxin doit être spécifiée avec une valeur fixe dépendant du nombre de bits supportés par le scanner ; dans mon cas, il s’agit de 12 bits; je renseigne donc la valeur 4095 (cf. man).
  • maxout doit être spécifiée avec la valeur la plus grande acceptée par l’option –gamma-table de scanimage (255 dans mon cas) ;
  • shadow peut garder la valeur 0 ;
  • enfin, highlight peut garder la même valeur que maxin mais c’est en abaissant cette valeur de 15% que j’ai finalement résolu mon problème.

Une fois les valeurs déterminées, je combine l’outil gamma4scanimage avec scanimage de la manière suivante :
scanimage –device pixma –mode Gray -l 0 -t 0 -x 210 -y 297 –custom-gamma=yes –gamma-table `gamma4scanimage 1.8 0 3500 4095 255` >image.pnm

J’ai alors ce résultat (après conversion en PNG) :
page_scanimage_option_gamma-table-723x1024 gamma dans Planet Libre
Le fond est bien blanc. Le verso n’apparaît pas.

Autre avantage : le fichier qui en résulte est plus petit (presque deux fois plus petit dans mon exemple). Ceci est particulièrement pratique lorsque les documents sont destinés à être envoyés par courriel.

Ce résultat me permet maintenant d’envisager d’appliquer une phase de reconnaissance de caractères (OCR) afin de faciliter des recherches éventuelles dans mes documents numérisés.

Avis et éclairage sont les bienvenus en commentaires.

Linux : résoudre le problème de carte SD non reconnue après hibernation

Lundi 14 août 2017

Je continue sur mes résolutions de problèmes liés à la migration de mon système Salix OS. Je vais encore parler d’hibernation mais en lien avec mon lecteur de cartes SD.

Comme expliqué dans un précédent article, mon ordinateur possède un lecteur de cartes mémoire, qui fonctionnait bien pour mon utilisation (lecture de cartes SD, pas d’écriture) sous Salix OS 13.37.

Acte 1 : Salix OS 14.1 et la solution du rechargement de module

Suite au passage à la version 14.1 de Salix OS, j’ai constaté que le lecteur de cartes SD ne fonctionnait plus lors d’un retour d’hibernation. Lorsque j’insérais la carte SD, elle n’était pas reconnue.

J’avais trouvé la solution sur le forum Slackware de LinuxQuestions.org. Il suffisait de recharger le module sdhci_pci :

$ rmmod sdhci_pci
$ modprobe sdhci_pci

L’insertion de la carte SD était alors reconnue.

Acte 2 : Salix OS 14.2 et la solution du déchargement de module avant hibernation

Malheureusement, la situation s’est empirée avec la migration vers la version 14.2 de Salix OS. Le même problème persistait lors du retour d’hibernation mais la solution de rechargement du module sdhci_pci ne résolvait plus le problème.

Dans /var/log/syslog, je constatais des messages de ce genre lorsque j’insérais la carte SD :

Aug  5 00:19:14 darkstar kernel: [432740.383264] mmc0: Timeout waiting for hardware interrupt.
Aug  5 00:19:14 darkstar kernel: [432740.385457] mmc0: error -110 whilst initialising SD card

Après quelques recherches, j’ai finalement trouvé une solution dans cette page de documentation consacrée à la compatibilité de Linux avec les ordinateurs portables de type IBM/Lenovo ThinkPad.

La solution consiste à créer un fichier /etc/pm/config.d/00sleep_module dans lequel la ligne suivante est présente :

SUSPEND_MODULES="$SUSPEND_MODULES sdhci"

Cette ligne a pour effet de décharger le module sdhci avant l’hibernation. Le module est alors proprement rechargé lors du retour d’hibernation, et le lecteur de carte SD devient utilisable.

Cette solution ne fonctionne qu’avec les outils pm-utils (pm-suspend et pm-hibernate), le fichier créé étant un fichier de configuration pour ces outils.

Fin

Il reste à voir quelle nouvelle surprise me réservera la prochaine version de Slackware/Salix OS.

En tout cas, sous Linux, je constate qu’il y a (presque) toujours une solution aux problèmes.

Linux : résoudre le problème de double mise en veille

Dimanche 30 juillet 2017

J’ai récemment mis à jour mon système Salix OS de la version 14.1 vers la version 14.2. Il s’agit de la troisième mise à jour que je fais et cela se passe toujours sans gros problème, si ce n’est que je dois, à chaque fois, renouveler la procédure d’installation du pilote pour le Wifi.

Cependant, il arrive de temps en temps des petites surprises, en particulier avec la gestion des boutons liés à l’énergie.

Il y d’abord la fermeture de l’écran de mon ordinateur portable pour laquelle je souhaite qu’une hibernation (appelée aussi « mise en veille prolongée » dans Microsoft Windows, ou suspend-to-disk) soit effectuée.

Et il y a ensuite la mise en veille (appelée aussi suspend-to-ram) que je souhaite déclencher lors de l’appui de la touche Lune de mon ordinateur (Fn + F1).

Pour faire tout cela, sous Slackware (pour rappel, Salix OS utilise Slackware comme base), cela se passe dans le fichier de script shell /etc/acpi/acpi_handler.sh :
#!/bin/sh
# Default acpi script that takes an entry for all actions

IFS=${IFS}/
set $@

case « $1″ in
  button)
    case « $2″ in
      power) /sbin/init 0
         ;;
      *) logger « ACPI action $2 is not defined »
         ;;
    esac
    ;;
  *)
    logger « ACPI group $1 / action $2 is not defined »
    ;;
esac

Pour déclencher l’hibernation, j’avais simplement ajouté la branche suivante dans le case :
     lid) pm-hibernate
         ;;

« lid » (qui veut dire en anglais « couvercle ») correspond au bouton (plutôt virtuel dans le cas mon ordinateur) lié à la manipulation de l’écran d’un ordinateur portable. Je l’ai donc associé à la commande pm-hibernate, qui s’occupe de mettre l’ordinateur dans l’état d’hibernation de manière correcte.

Et pour déclencher une mise en veille, j’avais simplement ajouté la branche suivante :
     sleep) pm-suspend
         ;;

« sleep » correspond à la touche Lune de mon ordinateur. Je l’ai donc associé à la commande pm-suspend, qui s’occupe de mettre l’ordinateur dans l’état de veille.

Tout cela fonctionnait plutôt bien jusqu’à une première mise à jour, suite à laquelle il est apparu que le retour d’hibernation déclenchait automatiquement une nouvelle hibernation.

L’astuce que j’avais trouvée à l’époque était d’appliquer un contrôle sur l’état effectif du bouton lid :
     lid) grep -q closed /proc/acpi/button/lid/*/state && pm-hibernate

Suite à ma récente mise à jour vers Salix OS 14.2, un problème similaire est apparu avec la mise en veille déclenchée par la touche Lune. Suite au retour de veille, une deuxième mise en veille était effectuée immédiatement.

Lors de ma recherche d’une solution sur le Web, j’ai découvert, via cet article, l’existence de l’outil acpi_listen. Cet outil permet de voir les événements ACPI exacts déclenchés. Il suffit de le lancer puis de déclencher les boutons/touches :
# acpi_listen
button/lid LID close
button/lid LID open
button/sleep SBTN 00000080 00000000
button/sleep PNP0C0E:00 00000080 00000008

Ici, le résultat montre que la fermeture et l’ouverture de l’écran déclenchent deux événements. Il montre aussi que l’appui de la touche Lune déclenche deux événements.

Il m’est donc apparu clairement qu’utiliser les deux premiers composants de l’événement ACPI ($1 et $2 dans le fichier acpi_handler.sh) n’était pas suffisant. J’ai donc adapté le script de la façon suivante :
      lid) test $4 = « close » && pm-hibernate
         ;;
      sleep) test $3 = « SBTN » && pm-suspend
         ;;

Cela a réglé le problème… jusqu’à la prochaine mise à jour en tout cas. Car les composants supplémentaires ($3 et $4 dans le script) sont-ils suffisamment stables pour être utilisés ? Qui me dit que leurs valeurs ne changera pas lors d’une prochaine mise à jour ? L’avenir nous le dira…

Ci-dessous, le script complet du fichier /etc/acpi/acpi_handler.sh, après modification :
#!/bin/sh
# Default acpi script that takes an entry for all actions

IFS=${IFS}/
set $@

case « $1″ in
  button)
    case « $2″ in
      power) /sbin/init 0
         ;;
      lid) test $4 = « close » && pm-hibernate
         ;;
      sleep) test $3 = « SBTN » && pm-suspend
         ;;
      *) logger « ACPI action $2 is not defined »
         ;;
    esac
    ;;
  *)
    logger « ACPI group $1 / action $2 is not defined »
    ;;
esac

Salix OS 13.37 sur Dell Precision M4400

Dimanche 9 mars 2014

Comme je l’indiquais dans un précédent article, j’ai récemment acquis un ordinateur portable Dell Precision M4400, sur lequel j’ai installé la distribution Linux Salix OS 13.37.

Le modèle Precision M4400 fait partie des modèles d’ordinateurs portables de la gamme professionnelle du constructeur Dell. Il est vraisemblablement sorti en 2008, et ne semble plus disponible neuf. Il était disponible dans différentes configurations, avec de nombreuses options.

Voici les caractéristiques de mon ordinateur (en gras, les caractéristiques qui m’ont poussé à l’achat) :

  • Processeur : Intel Core 2 Duo T9600 (2,8 GHz/1 066 MHz/6 Mo)
  • Mémoire vive : 4 Go DDR2 800 MHz
  • Écran : WUXGA 39 cm (15,4″) 2CCFL (résolution de 1920 x 1200 pixels)
  • Contrôleur graphique : nVidia Quadro FX 770M (512 Mo dédiés)
  • Disque dur : SATA de 200 Go à 7200 tr/min
  • Interface pour disques optiques : graveur CD/DVD double couche 8x
  • Interface pour cartes mémoire : lecteur de cartes 5 en 1 (SD, SDIO, MMC, MS, MSPro)
  • Clavier : AZERTY belge, rétro-éclairé, 84 touches, 3 touches de contrôle du volume
  • Pavé tactile : simple point, zones de défilement vertical et horizontal, 3 boutons
  • Bouton de pointage (trackpoint) : 3 boutons
  • Interfaces d’entrée : micro intégré, caméra (2 mégapixels), prise jack micro, lecteur d’empreintes digitales, lecteur de cartes à puce (smartcards), lecteur de cartes sans contact
  • Interfaces de sortie : haut-parleurs, prise jack casque, VGA, DisplayPort
  • Interfaces réseau : Ethernet (Gigabit), Wifi (802.11a/b/g/n), Bluetooth (2.1) et 3G (UMTS)
  • Interfaces multimédia : USB 2.0 (3), USB 2.0/eSATA, Firewire (IEEE 1394)
  • Interface de station d’accueil : E-Port
  • Extension : lecteur de cartes ExpressCard 54 et lecteur de cartes PCMCIA
  • Batterie : 6 cellules, lithium-ion
  • Châssis : base et couvercle en alliage de magnésium
  • Poids :  2,69 kg
  • Dimensions : 358 mm (largeur) x 257 mm (profondeur) x 27 à 33 mm (hauteur)

Un article du site LaptopSpirit.fr (que je trouve être une excellente source d’informations sur les ordinateurs portables) donne les prix pour les différentes configurations. Grâce à ces prix, je peux estimer que mon ordinateur valait environ 1600 euros neuf.

J’ai donc installé la distribution Salix OS 13.37 (version 32 bits) sur cet ordinateur. L’installation s’est déroulée sans aucun problème. Au premier démarrage, le système est fonctionnel et utilisable, à l’exception de quelques pilotes à installer (Wifi en particulier).

 

Dell Precision M4400 faisant tourner Salix OS

Dell Precision M4400 faisant tourner Salix OS

Les points suivants résument la compatibilité de l’ordinateur avec Salix OS 13.37 :

Affichage : OK, avec le pilote nouveau. En particulier, la résolution 1920 x 1200 est automatiquement reconnue (à la fois dans la console et dans X.org).
Connexion Ethernet : OK.
Connexion Wifi : OK, après installation du pilote wl (voir mon article précédent à ce sujet).
Connexion Bluetooth : non testée.
Connexion 3G : non testée.
Clavier : OK ; en particulier, les trois touches de contrôle du volume sont reconnues comme des touches multimédia standard dans X.org (XF86AudioLowerVolume, XF86AudioRaiseVolume, XF86AudioMute).
Pavé tactile : OK, sauf défilement horizontal.
Bouton de pointage (trackpoint) : OK.
Son : OK (haut-parleurs, sortie casque, micro interne, entrée micro).
Caméra : OK
État de charge de la batterie : NOK ; à charge pleine, la capacité restante (remaining capacity) est supérieure de 26 % à la capacité totale (last full capacity), ce qui donne un état de charge maximale de 126 %…
Lecture CD/DVD : OK (testée avec DVD vidéo, CD audio et CD de données).
Gravure CD/DVD : non testée.
Accès à une carte mémoire : OK (avec une carte SD, seulement testée en lecture).
Ports USB : OK (testée avec une souris USB, une clé USB et un appareil photo).
Port eSATA : non testée.
Port Firewire : non testée.
Lecture d’empreintes digitales : non testée.
Lecture de cartes à puce (smartcards) : OK, après installation des paquets pcsc-lite et ccid.
Lecture de cartes sans contact : non testée.
Boutons ACPI : OK ; le symbole Lune (Fn + F1) est reconnu avec l’événement ACPI « button/sleep » ; l’ouverture et la fermeture du couvercle sont reconnues avec l’événement ACPI « button/lid ».
Mise en veille (suspend-to-RAM) : OK, avec pm-suspend.
Hibernation (suspend-to-disk) : OK, avec pm-hibernate, après avoir ajouté « append= »resume=/dev/sda1″ » à l’entrée « Salix » de LILO.
Connexion d’une carte d’extension (ExpressCard 54, PCMCIA) : non testée.
Connexion à une station d’accueil : non testée.
Connexion d’un moniteur (VGA, DisplayPort) : non testée.

Comme vous pouvez le constater, je n’ai pas eu l’occasion de tout tester, mais les fonctionnalités essentielles sont opérationnelles, et la plupart le sont dès l’installation de Salix OS 13.37. Si vous avez une question concernant cet ordinateur et sa compatibilité avec Linux, n’hésitez pas me contacter via les commentaires.

Informations complémentaires :
- Compatibilité générale du Dell Precision M4400 avec Linux ;
- Compatibilité du Dell Precision M4400 avec Linux Mint.

 

Configuration de l’adaptateur Wifi Broadcom BCM4322 sous Linux/Slackware/Salix OS

Samedi 4 janvier 2014

J’ai récemment acquis l’ordinateur portable Dell Precision M4400, sur lequel j’ai installé une distribution Linux. J’évoquerai en détail cette installation dans un prochain article, mais je souhaitais d’abord m’attarder sur un des seuls (pour ne pas dire le seul) points qui n’a pas été pris en charge par défaut : l’adaptateur Wifi Broadcom BCM4322.

C’est malheureusement un problème récurrent lorsqu’on installe Linux sur un ordinateur pourvu d’un adaptateur Wifi. Ce n’est d’ailleurs pas un hasard si mes articles précédents sur le même thème (un premier consacré à la clé Hercules Wireless N USB mini, et un deuxième consacré à la clé Amarina 54Mbps Wireless USB Adapter) font partie des articles les plus lus de mon blog.

L’ordinateur portable Dell Precision M4400 présente donc l’adaptateur Wifi Broadcom BCM4322, comme j’ai pu le constater clairement avec l’outil en ligne de commandes lspci :

# lspci -nn
…
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)

Avec ma distribution Linux courante, Salix OS 13.37 (fondée sur Slacware Linux 13.37), l’adaptateur Wifi était par défaut détecté par le module b43, inclus dans le noyau Linux. Malheureusement, l’interface réseau n’était pas créée, et un outil comme iwconfig n’affichait aucune interface Wifi.

Par ailleurs, j’ai observé les messages suivants dans dmesg:

[   11.473082] b43-phy0: Broadcom 4322 WLAN found (core revision 16)
[   11.488189] b43-phy0 ERROR: FOUND UNSUPPORTED PHY (Analog 8, Type 4, Revision 4)
[   11.488733] b43: probe of ssb0:0 failed with error -95
[   11.489014] Broadcom 43xx driver loaded [ Features: PMLS, Firmware-ID: FW13 ]

La documentation officielle du pilote b43 est assez claire. Elle donne l’état des lieux de la prise en charge des puces Broadcom.

Pour le contrôleur avec l’identifiant 14e4:432b, la documentation indique que le module b43 a une prise en charge partielle à partir du noyau Linux 2.6.39. Salix OS 13.37 présentant le noyau Linux en version 2.6.37, j’ai dû me retourner vers l’alternative (malheureusement propriétaire) indiquée par la documentation : le module wl, fourni indépendamment du noyau par Broadcom dans un paquet nommé « 802.11 Linux STA driver ».

Ce module est disponible dans le paquet broadcom-sta, mis à disposition par le dépôt SlackBuilds.org :

# slapt-src --search broadcom
broadcom-sta:5.100.82.112 - broadcom-sta (Broadcom wireless drivers)

Malheureusement, l’installation de ce paquet avec slapt-src échoue, le paquet source ne pouvant être téléchargé :

# slapt-src -i broadcom-sta
The following packages will be installés:
broadcom-sta
Voulez-vous continuer ? [y (oui) / N (non)] y
Récupération de README...Réalisé
Récupération de broadcom-sta.SlackBuild...Réalisé
Récupération de broadcom-sta.info...Réalisé
Récupération de doinst.sh...Réalisé
Récupération de slack-desc...Réalisé
Récupération de http://www.broadcom.com/docs/linux_sta/hybrid-portsrc_x86_32-v5_100_82_112.tar.gz...Raté

Un article du blog « rog notes » donne les instructions à suivre pour contourner ce problème. Je les reprends ici en les adaptant à Slackware 13.37 et en les complétant :
1) Télécharger le paquet source (hybrid-portsrc_x86_…tar.gz) correspondant au système requis (32 ou 64 bits), ainsi que le paquet slackbuild (broadcom-sta.tar.gz), sur la page SlackBuilds.org.
2) Se déplacer dans le répertoire où ont été sauvés les fichiers téléchargés, puis extraire le paquet slackbuild.

# tar xvfz broadcom-sta.tar.gz

3) Se déplacer dans le répertoire broadcom-sta créé puis y copier le paquet source.

# cd broadcom-sta
# cp -a ../hybrid-portsrc_x86_…tar.gz

4) Se connecter en tant qu’administrateur (root) puis générer le paquet Slacware. Attention : ceci nécessite que des outils de développement (compilateurs, bibliothèques, …) soient installés sur le système.

$ su
$ ./broadcom-sta.SlackBuild

5) Copier le paquet Slackware généré dans /tmp et nommé broadcom-sta…_Sb0.tgz (mieux vaut garder ce paquet quelque part en cas de besoin).

$ cp -a /tmp/broadcom-sta…_Sb0.tgz ./

6) Installer le paquet Slackware.

$ installpkg broadcom-sta..._Sb0.tgz

7) Décharger le module b43 (ainsi que le module ssb lié) puis charger le module wl (fraîchement installé).

$ modprobe -r b43 ssb
$ modprobe wl

8) Utiliser l’utilitaire de son choix (iwconfig, wicd, NetworkManager) afin de configurer l’interface réseau qui devrait normalement avoir été créée. Attention : dans mon cas, cette interface réseau porte l’identifiant eth1, et non le classique wlan0.

9) Ajouter les modules b43 et ssb dans la liste noire des modules afin de s’assurer que c’est bien le module wl qui sera pris en compte lors du redémarrage du système.

$ echo "blacklist ssb" >> /etc/modprobe.d/blacklist
$ echo "blacklist b43" >> /etc/modprobe.d/blacklist

Merci à Roger du blog « rog notes » pour l’astuce. J’espère que cet article sera utile à toute personne confrontée à l’installation d’un pilote pour un adaptateur Wifi Broadcom.

 

Visionneuse de photos en LC : le match feh – qiv

Samedi 20 octobre 2012

Aujourd’hui, j’aimerais parler de visionneuses de photos en ligne de commande (LC).

Je suis personnellement habitué à utiliser qiv, mais ma distribution courante (Salix OS) a choisi de mettre en avant feh. Ces deux outils présentent le même objectif de permettre la visualisation d’images à partir de la ligne de commande :
$ feh ma_première_image.jpeg ma_deuxième_image.jpeg …
$ qiv ma_première_image.jpeg ma_deuxième_image.jpeg …

Ces deux commandes auront le même effet : celui d’ouvrir une fenêtre avec la première image affichée.

Visionneuse de photos en LC : le match feh – qiv dans Planet Libre

Vue par défaut de feh

 feh dans Planet Libre

Vue par défaut de qiv

Les autres images peuvent ensuite être visualisées en cliquant dans la fenêtre (bouton de gauche) ou en appuyant sur la barre espace.
Dans les deux outils, la fenêtre peut être fermée avec la touche q.

Cependant, des différences existent entre les deux outils, de par leurs nombreuses options et leur mode de fonctionnement. Je vais tâcher de vous présenter les différences les plus notables à mes yeux.

Dépendances

feh: nécessite principalement imlib2.
qiv: nécessite imlib2 et gdk2.

Installation sous Salix OS

feh: est disponible en tant que paquet binaire.
$ slapt-get –install feh

qiv: n’est seulement disponible qu’en paquet source (slkbuild).
$ slapt-src –install qiv

Intéraction

feh: touches de raccourcis clavier + menu contextuel (accessible avec la souris).

 Linux

Menu contextuel de feh

qiv: raccourcis clavier principalement (liste des raccourcis disponible en appuyant sur la touche ?).

 photo

Aide en ligne de qiv

Accès à la résolution de l’image

feh : disponible dans le menu uniquement.

 qiv

Résolution dans le menu contextuel de feh

qiv : disponible dans la barre de la fenêtre, ou dans une barre de statut en mode plein écran (affichée via la touche i).

 Salix OS

Résolution dans la barre de statut de qiv

Visualisation en vue maximisée

feh: possible (option -.).

Aspect maximisé dans feh

qiv: possible (option -m ou -t), mais à condition d’être en plein écran.

Aspect maximisé dans qiv

Vitesse d’affichage

J’ai fait un test consistant à visualiser 16 photos de résolutions 2592×1944 avec mon ordinateur (acheté en 2001…). Résultat « à vue d’œil » : feh est environ deux fois plus rapide que qiv, aussi bien pour le chargement initial que pour le passage d’une image à une autre.

 

Même si les points présentés ici peuvent faire pencher la balance du côté de feh, j’ai tendance à préférer qiv, car ses options en LC et ses raccourcis clavier me semblent plus naturels (mais peut-être est-ce dû à l’habitude ?).

Et vous, lequel des deux outils préférez-vous ?

Note : pour ceux qui se demanderaient quel est l’endroit apparaissant sur les photos de cet article, il s’agit de la très agréable ville belge de Dinant, avec son bord de Meuse et sa citadelle.

Mon passage à Frugalware 1.6 (Fermus)

Dimanche 15 avril 2012

Comme je l’ai indiqué dans mes deux derniers articles, j’ai mis à jour mon système Frugalware de la version 1.5 (Mores) vers la version 1.6 (Fermus). Cette mise à jour m’a posé quelques problèmes, que je souhaite reporter ici.

J’ai entrepris cette mise à jour, en espérant que cela pouvait éventuellement résoudre mon problème de blocage du chargement de Linux en fonction de la date du système.

Pour cela, j’ai suivi les instructions de mise à jour données par l’équipe de développement. La mise à jour des paquets m’a posé des problèmes d’espace disque car il semble que le système de base de cette nouvelle version demande plus d’espace disque. J’ai été contraint de désinstaller des logiciels que j’utilisais de temps en temps.

Suite au redémarrage, ce fut la déception (prévisible) : le chargement du noyau se bloquait toujours. J’ai alors été contraint de redémarrer le système en désactivant l’ACPI.

Puis ce fut le drame : le système ne retrouvait pas la partition racine spécifiée dans le fichier de configuration de GRUB (indiquée avec son UUID). Heureusement, je suis arrivé dans un mode où j’ai pu constaté que le chemin représentant ma partition racine n’était plus /dev/hda1 mais /dev/sda1. Ni une ni deux, j’ai redémarré le système en précisant ce chemin.

Mais ce n’était pas encore suffisant : le système n’arrivait pas à monter les partitions. J’ai rapidement compris que le fichier /etc/fstab devait être aussi mis à jour afin de remplacer toute référence à hda par sda.

Après redémarrage, le système se lance finalement jusqu’au bout. Il est maintenant utilisable. Ouf ! Je précise que j’ai également eu l’occasion de mettre à jour le système Frugalware de mon frère et que j’ai eu les mêmes désagréments.

À partir de là, je n’ai pas constaté de problèmes de prise en charge du matériel (à part les fonctions ACPI bien sûr…). Par contre, je subis de gros problèmes de performance. Je ne pense pas que cela vient du système en tant que tel, mais plutôt du changement de version de Mozilla Firefox (4 vers 10). Je pense que cela est du à sa consommation mémoire car j’ai pu constater qu’il pouvait prendre jusqu’à 60 % de la mémoire virtuelle avec seulement 4 ou 5 onglets ouverts. Je trouve cela assez étonnant, étant donné que la version 7 était censée améliorer significativement la consommation mémoire

En conclusion, mon passage à Frugalware 1.6 (Fermus) a été plutôt malheureux : non résolution du problème lié à la date du système, consommation accrue d’espace disque, et dégradation des performances.

Il s’agissait de ma huitième mise à jour du système, depuis Frugalware 0.8 (Kalgan) et je crois malheureusement que cela sera la dernière, car trop de problèmes se sont maintenant accumulés. De plus, je me rends compte que le cycle de mise à jour de Frugalware ne correspond plus à mes besoins. Lorsqu’une nouvelle version de Frugalware est publiée, elle devient automatiquement la version par défaut. Si je souhaite alors obtenir des mises à jour de sécurité, ou simplement installer un paquet, je suis dans l’obligation de mettre à jour l’ensemble du système, et, ainsi, de prendre le risque d’obtenir des régressions ou des changements non désirés.

Ce n’est en aucun cas un reproche que je fais aux développeurs Frugalware. Le cycle de développement choisi convient sans doute à de nombreuses personnes. Il reste que Frugalware est une distribution complète, avec un nombre très important de paquets, une documentation claire et une communauté active de développeurs. Cela en fait une distribution de très bonne qualité. D’ailleurs, je ne m’interdis pas de revenir vers cette distribution dans le futur (avec une autre machine), ou de la conseiller autour de moi.

Encore merci aux développeurs Frugalware ! Et bonne continuation !

Pour ma part, je suis actuellement à la recherche d’une distribution qui conviendrait à mes besoins, i.e., avec le même objectif de simplicité que Frugalware, mais résolvant mes trois problèmes mentionnés plus haut, et laissant à l’utilisateur le libre choix de passer à une version supérieure du système. À ce jour, je pense me diriger vers une distribution Slackware ou dérivée. J’aurais probablement l’occasion d’en reparler sur mon blog dans un prochain article.

123