Mots-Clés ‘Linux’

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.

Blocage du chargement de Linux en fonction de la date du système

Dimanche 15 avril 2012

J’aimerais revenir sur un problème qui était apparu suite à la précédente mise à jour de mon système Frugalware Linux. Le système se bloquait lors du chargement du noyau (ou à la fin de celui-ci, je ne l’ai jamais vraiment su). La seule solution de contournement que j’avais trouvée était de préciser le paramètre noyau acpi=off. Cependant, cela a le désagréable effet de désactiver les fonctions ACPI (extinction automatique de la machine lors de l’arrêt du système, mise en veille, contrôle des boutons de marche/arrêt, contrôle lors de la fermeture de l’écran de portable, …). Puis le problème avait subitement et mystérieusement disparu le 1er janvier 2012.

À ce moment, je ne pensais pas que le problème venait du changement d’année, jusqu’à ce que je tentasse de démarrer mon système en mars 2012. Le problème est réapparu. J’ai alors tenté de démarrer le système après avoir changé la date au 28/02/2012. Et le système a bien démarré. Après plusieurs essais de dates, je suis arrivé à la conclusion que le système ne peut fonctionner correctement de mars à décembre, quelle que soit l’année…

J’ai alors repris mes recherches de solution « acceptable » à ce problème (considérant que désactiver l’ACPI ou falsifier la date du système n’étaient pas acceptables), mais je n’ai rien trouvé.

J’ai entrepris de mettre à jour mon système Frugalware vers la version 1.6 (Fermus), en espérant que cela pouvait éventuellement résoudre le problème, mais j’en doutais car j’avais déjà pu constater le même problème en essayant une version live bêta de Frugalware 1.6 (Fermus). Et cela s’est confirmé : le chargement du noyau se bloque toujours.

Suite à mes longues investigations, je pense (mais je ne peux pas vraiment l’affirmer) que le problème est lié au module rtc-cmos. J’imagine que c’est ce module qui va lire la date dans l’horloge système. Si le mois est supérieur à 2, il y a vraisemblablement blocage. Ce que j’ai remarqué, c’est que ce module a été intégré dans le noyau entre la version 1.4 (Nexon) et la version 1.5 (Mores). J’ai l’intime conviction que c’est ce changement qui a entrainé cette régression.

Pourquoi ce module a-t-il été intégré ? Je ne connais pas la raison précise, mais il semble que certaines personnes ont, au contraire, des problèmes si le module n’est pas inclus dans le noyau. Si c’est le cas, je ne peux pas vraiment blâmer les développeurs Frugalware.

Si vous avez des idées sur le problème, ou plus d’informations concernant ce module, n’hésitez pas à laisser un commentaire.

Nettoyage de système sous Frugalware

Mercredi 21 mars 2012

J’ai récemment mis à jour mon système Frugalware Linux de la version 1.5 (Mores) vers la version 1.6 (Fermus). J’en ferai d’ailleurs l’objet d’un nouvel article. Mais je voulais aujourd’hui parlé d’une opération que j’effectue généralement avant chaque mise à jour : un nettoyage de système.

Il s’avère que mon système prend plus de 90 % de mon disque dur, et que la mise à jour du système s’en retrouve compliquée. Je procède donc d’abord par ce nettoyage avant toute mise à jour.

1ère étape : les répertoires temporaires

Je consulte le contenu des répertoires temporaires :
> ls -lrt /tmp
> ls -lrt /var/tmp

Si un fichier ou un répertoire ne me semble plus utile, je le supprime. Exemple :
> rm -rf /var/tmp/<fichier|répertoire>

2ème étape : les journaux

Je commence d’abord par les journaux :
> ls -lrt /var/log

Si je constate qu’un fichier est un peu trop volumineux, je le vide. Exemple :
> echo «  » > /var/log/<fichier>

3ème étape : les paquets logiciels

Je liste les paquets « orphelins », c’est-à-dire, les paquets qui ne dépendent d’aucun autre paquet :
> pacman-g2 -Qed > /var/tmp/orphans1

Dans une autre console, je parcours la liste des paquets trouvés :
> less /var/tmp/orphans1

Si je trouve un paquet qui est superflu, je le désinstalle :
> pacman-g2 -R <paquet>

Puis je recalcule la liste les paquets « orphelins » :
> pacman-g2 -Qed > /var/tmp/orphans2

Et je regarde si de nouveaux paquets sont apparus :
> diff /var/tmp/orphans1 /var/tmp/orphans2

Si de nouveaux paquets superflus apparaissent, je les supprime. Et ainsi de suite…

Enfin, je trie la liste des paquets par ordre de taille. Pour cela, je lance la commande suivante :
> find /var/lib/pacman-g2/local/ -name desc | xargs grep ‘^[1-9][0-9]*$’ | sort -t ‘:’ -k 2 -n

Explications :

  • la commande « find … » liste les fichiers desc de tous les paquets de la base de données pacman-g2 ;
  • la commande « xargs … » exécute la commande grep sur chacun des fichiers trouvés par find ;
  • la commande « grep … » filtre les lignes ne contenant que des chiffres (il s’agit a priori de la taille du paquet) ;
  • la commande « sort … » sépare chaque ligne selon le caractère deux-points (« -t ‘:’ »), et trie sur le deuxième champ (« -k 2 ») comme un nombre (« -n »).

Les paquets apparaissant à la fin sont ceux qui prennent le plus de place sur le disque. Il reste alors à voir si ces paquets sont indispensables et, si ce n’est pas le cas, à les désinstaller (si c’est possible).

C’est tout pour aujourd’hui ! Si vous avez d’autres astuces dans le mêmes sens, n’hésitez pas à les partager en commentaires.

Touches mortes et UTF-8 sous Linux

Dimanche 19 février 2012

Aujourd’hui, j’aimerais évoqué un problème de saisie au clavier sous Linux.

Sous mon système (Frugalware Linux), le codage de caractère par défaut est ISO8859. Or, pour certaines raisons que je ne détaillerai pas ici, j’ai besoin de travailler en UTF-8. Pour cela, j’exécute, en m’inspirant de la section UTF-8 de la documentation de mon système, les commandes suivantes dans une console :
export LANG=fr_FR.utf8
export LC_ALL=$LANG
export CHARSET=utf-8

Mais voilà, à partir de là, les touches mortes pouvaient poser problème. Dans des applications GTK, il n’y a aucun problème. Mais dans plusieurs autres applications (comme l’application XTerm et les applications Tk), les touches mortes ne fonctionnaient plus. Par exemple, lorsque je tapais sur la touche ^, le caractère « ^ » était directement affiché, au lieu d’être gardé « en tampon » afin de pouvoir l’associer avec une autre lettre.

Je ne peux pas dire exactement quand ce problème est apparu, mais je pense avoir commencé à constater ce problème à partir de la version 1.4 (Nexon) de la distribution Frugalware Linux, sortie en février 2011.

J’ai longtemps cherché une solution à ce problème, jusqu’à ce que je tombe sur cet article de blog.

Sous Frugalware Linux, le fichier problématique est /usr/share/X11/locale/en_US.UTF-8/XI18N_OBJS. Voici les changements que j’ai appliqués :
6,8c6,10
< XOM   common/xomLTRTTB        _XomGenericOpenOM       # XOM_open
< XIM   common/xiiimp           _SwitchOpenIM           # XIM_open
< XIM   common/xiiimp           _XimpLocalOpenIM        # XIM_open

> #XOM  common/xomLTRTTB        _XomGenericOpenOM       # XOM_open
> XOM   common/xomGeneric       _XomGenericOpenOM       # XOM_open
> #XIM  common/xiiimp           _SwitchOpenIM           # XIM_open
> #XIM  common/xiiimp           _XimpLocalOpenIM        # XIM_open
> XIM   common/ximcp            _XimOpenIM

Une explication plus détaillée du problème est explicitée sur ce message de forum. D’après ce que j’ai compris, ce fichier de X.org fait référence à des modules qui ne sont présents que sous le système Sun Solaris.

Suite aux changements, les touches mortes sont devenues fonctionnelles. Je trouve cela un peu aberrant de devoir faire cette manipulation pour avoir un système fonctionnel. Si vous connaissez une autre solution, n’hésitez pas à la partager dans un commentaire.

Mon passage à Frugalware 1.5 (Mores)

Samedi 21 janvier 2012

J’ai profité de la pause de Noël dernier pour mettre à jour mon système Frugalware de la version 1.4 (Nexon) vers la version 1.5 (Mores). Comme pour chaque mise à jour, je reporte ici mes problèmes et mes impressions.

La mise à jour proprement dite ne m’a pas posé de problème. J’ai suivi scrupuleusement les instructions de mise à jour données par l’équipe de développement. Il me restait simplement à redémarrer.

Cette nouvelle version de Frugalware inclut un changement majeur — le passage à systemd — et j’appréhendais ce redémarrage… Et cela n’a pas raté ! Le système se bloquait lors du chargement du noyau. Les dernières lignes affichées à l’écran n’indiquaient aucune erreur particulière, et aucune trace du fameux (et redouté) kernel panic. Tout semblait laisser croire que le noyau se chargeait correctement, mais que systemd ne prenait pas le relais. Je me suis alors mis à la recherche d’un paramètre de noyau permettant de fournir des informations sur le problème ou de débloquer le chargement du système. Après de nombreuses recherches sur Internet, j’ai trouvé un paramètre intéressant : acpi=off.  Il désactive l’ACPI (fonctions de gestion d’énergie) et m’a permis de démarrer mon système.

Cependant, cela ne me satisfaisait pas, car les fonctions de gestion d’énergie, comme le contrôle de la batterie, la mise en veille ou le paramétrage des boutons d’alimentation, n’étaient plus actives. J’ai d’abord essayé de réinstaller quelques paquets majeurs comme le noyau et systemd, mais cela n’a eu aucun effet. J’ai alors passé plusieurs jours à chercher un autre paramètre de noyau qui pourrait agir sur l’ACPI sans le désactiver et qui permettrait à mon système de démarrer. Le 31 décembre, je trouve enfin le Saint-Graal : pci=usepirqmask. Satisfait, je alors suis parti fêter le réveillon de nouvel an. Le lendemain (en 2012 donc), j’ai réessayé de démarrer mon système sans paramètre particulier, et là, le système a démarré correctement ! Ai-je fait quelque chose sur le système ? Je ne le crois pas. Est-ce l’effet de la nouvelle année ? Je ne le pense pas. Le dernier démarrage avec le paramètre pci a-t-il permis au système de conserver la configuration matérielle de ma machine ? Je n’en sais rien… Toujours est-il que le problème ne s’est plus manifesté depuis.

Avec systemd, le temps de démarrage devait être amélioré. J’ai pris le soin de mesurer la durée avant et après la mise à jour. Avec Frugalware 1.4, mon système mettait environ :

  • 18 secondes jusqu’à la fin de GRUB et le début du chargement du noyau,
  • 49 secondes jusqu’à la fin du chargement du noyau et l’affichage de l’écran de démarrage (splash),
  • 88 secondes jusqu’à l’affichage de l’écran de connexion (slim).

Cela veut donc dire que mon système démarrait en 70 secondes. Avec Frugalware 1.5, mon système met environ :

  • 18 secondes jusqu’à la fin de GRUB et le début du chargement du noyau,
  • 54 secondes jusqu’à la fin du chargement du noyau et l’affichage de l’écran de démarrage (plymouth),
  • 77 secondes jusqu’à l’affichage de l’écran de connexion (slim).

Cela veut donc dire que mon système démarre maintenant en 59 secondes, soit 11 secondes gagnées. Cela n’est pas négligeable mais ne change pas la vie non plus. Par contre, sur la machine de mon frère (moins vieille que ma machine), j’ai pu constater que le démarrage est fulgurant (une poignée de secondes) !

J’ai également eu un problème avec la connexion au réseau Wifi de mes parents, qui ne s’initialise pas correctement au démarrage du système. Je n’ai pas constaté le problème avec mon réseau Wifi (qui a une configuration différente). Je n’ai pas pu investiguer plus en profondeur.

Au niveau des applications, tout fonctionnait aussi bien qu’avant, sauf pour Liferea, le lecteur de flux RSS, qui marquait systématiquement 10 ou 20 articles de chaque fil comme non lus, alors que je les avais déjà lus. De plus, il m’a semblé particulièrement gourmand en mémoire. J’ai été étonné de constater que la version installée était la version instable 1.7.6. J’ai donc décidé de me créer un paquet pour installer la dernière version stable de la branche 1.6 (1.6.7), qui fonctionne beaucoup mieux. N’hésitez pas à me contacter si vous souhaitez le paquet.

En conclusion,  mon passage à Frugalware 1.5 (Mores) s’est déroulé  dans une certaine douleur. Mais, au final, je pense n’avoir rien perdu en fonctionnalités, en stabilité ou en performance.

Il s’agissait de ma septième mise à jour du système, depuis Frugalware 0.8 (Kalgan). J’ai pu, une nouvelle fois, mettre à jour son système sans pour autant passer par une réinstallation complète. Je tiens à remercier et à féliciter les contributeurs Frugalware pour cette version.

J’espère que cet article vous aura intéressé. N’hésitez pas à laisser des commentaires.

123