Mon passage à Frugalware 1.3 (Haven)

Il y a quelques jours, je me suis enfin décidé à mettre à jour mon système Frugalware de la version 1.2 (Locris) vers la version 1.3 (Haven).

Je n’attendais rien de cette nouvelle version. Mon système était globalement fonctionnel et aucune des nouveautés annoncées ne m’attirait. Cependant, avec la mise à disposition de la pré-version 1.4, je me suis dit qu’il était temps de passer à la version 1.3.

Malheureusement, cette mise à jour m’a posé quelques problèmes, que je vais essayer de décrire dans cet article.

J’ai d’abord procédé à la mise à jour, en suivant les instructions de mise à jour données par l’équipe de développement.

Dès la première instruction, je me suis rapidement confronté à un problème. Il m’était impossible de mettre à jour pacman-g2 (et ses dépendances). Le gestionnaire de paquets plantait tout simplement. Sur le conseil de bouleetbil sur le salon IRC (merci à lui !), j’ai décidé de sauter cette étape et de passer à la mise à jour du système. Mais là aussi, certains paquets ne voulaient pas s’installer…

J’étais dans la panade lorsque, soudain, en regardant d’un peu plus près les paquets en erreur, j’ai compris d’où venait le problème : ces paquets étaient tous compressés au format xz, au lieu du format bzip2. Or, je n’avais pas le paquet xz installé. Je me alors suis empressé d’installer ce paquet. A partir de là, j’ai pu mettre à jour pacman-g2, ainsi que l’ensemble du système sans le moindre problème.

Les instructions de mise à jour sont donc incomplètes. En pré-requis, il est nécessaire d’installer le paquet xz.

Après redémarrage du système, j’ai constaté que la configuration Xorg était à revoir. Tout d’abord, la résolution d’écran était de 800×600, au lieu de ma résolution habituelle de 1024×768. Ensuite, ma souris externe (je possède un ordinateur portable avec touchpad) n’était plus pris en compte.

J’avais suivi les instructions de mise à jour, qui conseillaient de supprimer le fichier monolithique Xorg.conf. Je me suis rapidement dit que cela n’était peut-être pas une bonne idée… Heureusement, j’avais fait une sauvegarde du fichier de configuration. Je l’ai remis en place. Cela m’a permis de régler le problème de résolution. Mais le problème de souris externe persistait.

Avant tout, il est important de signaler qu’il s’agit d’une souris connectée sur le port série de mon ordinateur (eh oui, ça existe encore!). Après quelques manipulations et recherches sur Internet, j’ai constaté que ma souris n’était pas prise en compte par le système et qu’il était nécessaire d’utiliser l’utilitaire inputattach pour palier le problème :

inputattach –daemon intellimouse /dev/ttyS0

Cette commande attache une souris de type IntelliMouse (c’est le type de ma souris) au fichier périphérique représentant le premier port série (aussi appelé port COM1). L’option daemon sert à lancer l’utilitaire en arrière-plan.

Et ça marche !  La souris est tout de suite reconnue comme une entrée udev, puis détectée par Xorg. La souris devient alors utilisable.

Pour rendre cette configuration persistante, j’ai ajouté la commande dans le fichier /etc/rc.d/rc.local. Ainsi, à chaque redémarrage, la commande sera exécutée et la souris externe sera opérationnelle.

J’ai également dû ajouter la commande dans mon script de mise en veille (que j’avais parlé dans un article précédent), afin de relancer le processus juste après le retour de mise en veille.

J’ai fait un paquet de l’utilitaire inputattach. N’hésitez pas à me le demander si vous êtes intéressés.

Une autre régression est apparue. Ma clé USB Wifi n’était plus reconnue. J’avais déjà eu l’occasion d’écrire un article sur la configuration de cette clé. Pour résumer, la puce est une Realtek RTL 8192 SU, et je n’avais réussi à la faire fonctionner qu’avec le module ndiswrapper.

En regardant les traces du noyau, je me suis aperçu que la clé USB Wifi est reconnue et prise en charge par un autre module (r8192s_usb). Cependant, l’initialisation échoue. Je n’ai pas insisté (près tout, ce module est dans la catégorie staging), et j’ai décidé de l’ajouter dans la liste des modules à ne pas charger (fichier /etc/modprobe.d/blacklist.conf).

Cependant, cela n’a pas réglé le problème pour autant. La commande modprobe ndiswrapper m’indiquait que le module était introuvable. J’ai relancé la commande depmod -a mais cela n’a rien changé au problème. J’ai alors décidé de créer un lien symbolique :

ln -s /lib/modules/misc/ndiswrapper.ko /lib/modules/2.6.35-fw1/kernel/drivers/net/ndiswrapper.ko

depmod -a

Le module ndiswrapper peut alors être chargé. Je dois avouer que je n’ai pas bien compris pourquoi et comment je me suis retrouvé obligé à faire ce lien symbolique, alors que ce n’était pas nécessaire avec les précédentes versions du noyau. Si quelqu’un a une explication, je l’attends avec impatience.

Je vous passe la reconfiguration des touches multimedia de mes deux claviers (interne et externe). Il s’agit d’une tâche que je dois faire environ une fois sur trois après chaque mise à jour de système. Je ferai peut-être un article sur le sujet.

En résumé, mon passage à Frugalware 1.3 s’est déroulé dans une certaine douleur. Mais au final, je n’ai perdu ni en fonctionnalités, ni en stabilité, ni en performance. Il s’agissait de ma cinquième mise à jour du système, depuis Frugalware 0.8 (Kalgan). C’est toujours un plaisir de voir que l’on peut 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 cela.

J’espère que cet article vous aura intéressé. N’hésitez pas à me faire part de vos commentaires.

Mots-clefs : ,

3 Réponses à “Mon passage à Frugalware 1.3 (Haven)”

  1. Devil505 dit :

    Juste pour info le fichier de blacklistage est /etc/sysconfig/blacklist ;)

  2. julien1001 dit :

    @Devil505: tu as parfaitement raison. Merci pour cette précision. En fait, /etc/modprobe.d/blacklist.conf est un lien symbolique vers /etc/sysconfig/blacklist. J’ai préféré mentionner /etc/modprobe.d/blacklist.conf car cela me semble plus standard.

  3. Devil505 dit :

    Oui c’est un lien symbolique mais c’est plus facile de s’en rappeler et ca se rapproche de /etc/sysconfig/modules son « opposé » :)

Laisser un commentaire