Mots-Clés ‘Linux’

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.

Réglage de l’heure locale sous Linux

Lundi 2 janvier 2012

J’ai récemment installé Frugalware Linux 1.5 (Mores) sur l’ordinateur de mon frère, et le réglage de l’heure m’a donné du fil à retordre.

MS Window XP est installé sur l’ordinateur. Comme ce système travaille avec l’horloge RTC (celle de la machine, configurable dans le BIOS), nous sommes contraints de renseigner l’heure locale dans l’horloge RTC.

Par conséquent, mon frère et moi avions  sélectionné, à l’installation, le choix localtime, afin que l’heure du système soit celle de l’horloge RTC.

Pourtant, suite au démarrage du système installé, l’horloge du système avait une heure d’avance. La commande date renvoyait l’heure locale avancée d’une heure alors que les commandes date -u et hwclock renvoyaient l’heure locale.

Après quelques jours de tergiversation, j’ai trouvé la manipulation à effectuer pour régler le problème (en tant que root) :

  1. Régler d’abord l’horloge du système avec l’heure locale. Exemple de commande à exécuter : date -s 18:45:30.
  2. Appliquer cette heure à l’horloge RTC. Commande à exécuter : hwclock  –systohc.

Suite à cette manipulation, c’est l’heure de l’horloge RTC qui est utilisée, aussi bien sous Linux que sous MS Windows.

J’espère que cette solution pourra être  utile à quelqu’un d’autre.

Changements pour le gestionnaire de fenêtres Ion3

Dimanche 23 octobre 2011

Dans un article précédent, j’avais parlé du gestionnaire de fenêtres Ion3, que j’utilise en permanence sur mon ordinateur. Pour rappel, Ion3 a pour particularité d’être un gestionnaire de fenêtres en mosaïque et à onglets (tiling tabbed window manager en anglais). A l’époque où j’avais écrit mon article, il était clair que Ion3 était déjà un projet mort. Depuis lors, quelques changements sont apparus avec ce projet.

Tout d’abord, dans le courant de l’année 2010, le site de l’auteur du projet (hébergeant Ion3) est devenu inaccessible. L’auteur du projet, Tuomo Valkonen, avait tout simplement retiré toutes les ressources liées à ce projet. Je n’ai trouvé aucune justification à cela. Il faut dire que l’auteur est connu pour ses conflits avec la communauté des logiciels libres…

Heureusement, il y a quelques mois, l’auteur a publié une page permettant de télécharger tous les logiciels qu’il a créés (dont Ion3).

Entre temps, deux forks de Ion3 sont apparus: Notion et Anion. Ce dernier semble avoir été abandonné au profit du premier. Je suis d’ailleurs le projet Notion (notez le jeu de mot avec not ion) depuis quelques mois, et je peux dire qu’il est plutôt actif, même si rien n’a été publié pour l’instant. J’espère qu’il aboutira à quelque chose.

Malgré tout cela, je continue à utiliser Ion3 comme gestionnaire de fenêtres, considérant que ce n’est pas parce qu’un projet est mort que son produit l’est.

Je sais que des gestionnaires de fenêtres similaires existent (wmii, xmonad, awesome, …) . J’avoue que je n’ai jamais pris le temps de les essayer. Si vous avez eu l’occasion de les comparer avec Ion3, n’hésitez pas à me faire part de vos impressions en commentaires.

 

Mon passage à Frugalware 1.4 (Nexon)

Dimanche 22 mai 2011

Il y a quelques jours, j’ai mis à jour mon système Frugalware de la version 1.3 (Haven) vers la version 1.4 (Nexon). Une fois n’est pas coutume, je reporte ici mes problèmes et mes impressions.

J’ai d’abord procédé à la mise à jour, en suivant les instructions de mise à jour données par l’équipe de développement. Comme d’habitude, je ne fais une mise à jour massive, comme indiqué dans les instructions, car j’ai un espace disque qui ne permet pas de télécharger tous les paquets à mettre à jour. A la place, je suis obligé d’installer les paquets par groupe de 5 ou 6, en vidant le cache de pacman-g2 régulièrement. Cela fait que je me peux me retrouver à effectuer des opérations avec un système à moitié mis à jour. Dans ce cas-ci, la commande df ne fonctionnait plus (heureusement, elle est redevenue pleinement opérationnelle après la fin de la mise à jour et un redémarrage).

Suite au redémarrage, j’ai malheureusement constaté trois soucis.

Tout d’abord, ma connexion Wifi ne fonctionnait plus. Ma clé USB Wifi était bien reconnue, mais mal configurée. Comme indiqué dans de précédents articles, et en particulier celui concernant la configuration de cette clé, j’ai l’habitude d’utiliser le pilote Windows, via le module ndiswrapper. Or, ce module ne peut plus être chargé. J’ai reporté le problème dans l’outil de suivi des bugs de Frugalware.

Heureusement pour moi, ma clé USB Wifi est reconnue par un autre pilote, le module r8712u. Bien que ce module soit expérimental (staging), il semble parfaitement fonctionner, jusqu’à maintenant, en tout cas. Cependant, j’ai constaté qu’on ne peut assigner un essid à l’interface Wifi qu’à partir du moment où elle est activée. Je devais donc assigner l’essid manuellement, après chaque démarrage du système.

Pour automatiser cela au démarrage du système, j’ai suivi le conseil donné dans la page man de netconfig (l’outil réseau de Frugalware), en ajoutant les deux lignes suivantes dans mon fichier /etc/sysconfig/network/default :

pre_up = ifconfig wlan0 up

post_down = ifconfig wlan0 down

La première ligne a pour effet d’activer l’interface Wifi (wlan0) avant sa configuration proprement dite et, en particulier, le positionnement de l’essid. Symétriquement, la deuxième ligne permet de désactiver l’interface Wifi après que l’interface Wifi soit « dé-configurée ».

Mon deuxième soucis concernait le plantage des applications Web que j’utilise régulièrement: firefox, liferea (aggrégateur de flux RSS, qui une petite fonction de navigation) et uzbl (un navigateur que j’expérimente de temps à autres). Ces trois applications plantaient systématiquement dès qu’une page devait être chargée.
J’ai commencé par désinstaller les plug-ins firefox, et en particulier le plug-in flash, mais ça plantait encore. Je me suis également lancé dans la désinstallation d’un maximum de polices, en pensant que cela pouvait être une chose commune entre ces trois applications, mais cela n’a rien changé. Désespéré, je me suis alors dirigé vers le salon IRC francophone de Frugalware. Les gens ont pris le temps d’écouter mon problème (merci à eux !) et m’ont donné un ou deux conseils, mais qui n’ont pas porté leurs fruits.

Entre temps, un collègue de travail m’a conseillé d’utiliser l’outil strace, que je ne connaissais pas du tout. Il permet de voir tous les appels systèmes (librairies chargées, fichiers accédés, …) effectués par une application. Je l’ai installé en tapant simplement :

# pacman-g2 -S strace

Je l’ai d’abord essayé avec firefox :

# strace firefox

Mais cela ne m’a donné aucune piste. J’ai ensuite essayé avec liferea :

# strace liferea

Et là, quelques lignes ont attiré mon attention. Ces lignes indiquaient que l’application tentait de charger la librairie /usr/lib/firefox/plugins/libflashplayer.so. Ce fichier existait bien et était un lien vers /usr/lib/mozilla/plugins/libflashplayer.so. J’étais étonné car il s’agit de la librairie du plug-in flash, alors que j’avais désinstallé le plug-in flash. J’ai alors vérifié d’où venait ces deux fichiers :

# pacman-g2 -Qo /usr/lib/firefox/plugins/libflashplayer.so

erreur: Aucun paquet ne contient /usr/lib/firefox/plugins/libflashplayer.so

# pacman-g2 -Qo /usr/lib/mozilla/plugins/libflashplayer.so

erreur: Aucun paquet ne contient /usr/lib/mozilla/plugins/libflashplayer.so

J’avais donc deux fichiers fantômes, n’appartenant à aucun paquet. J’ai alors renommé les deux répertoires plugins en plugins.bak. Puis j’ai réessayé les trois applications Web, et là, bingo ! Elles semblaient fonctionner parfaitement.

J’ai alors réinstallé le plug-in flash. Tout fonctionnait encore. De toute évidence, la mise à jour du paquet flashplugin et sa suppression n’ont pas fonctionné, et je ne sais pas pourquoi.

Enfin, mon troisième soucis concerne le fichier rc.local (du répertoire/etc/rc.d/). J’y ai quelques commandes me permettant d’activer des touches spéciales de mon clavier (du genre touche Internet). Suite à la mise à jour, j’ai constaté que ces touches ne fonctionnaient plus.

En analysant le problème, j’ai eu la désagréable surprise de voir que le fichier rc.local avait été écrasé par une version vierge, sans mes modifications. Est-ce normal ? Ai-je fait une mauvaise manipulation ? Y a-t-il un autre fichier plus approprié pour exécuter des commandes à chaque démarrage ? Je ne sais pas. Si quelqu’un a une idée, je serais très content de la connaitre.

En conclusion,  mon passage à Frugalware 1.4 (Nexon) s’est déroulé globalement bien. J’ai eu les trois soucis mentionnés ci-dessus, mais ils ont été finalement vite corrigés. Au final, je n’ai perdu ni en fonctionnalités, ni en stabilité, ni en performance.

J’apprécie le nouvel écran graphique de démarrage, très sobre, avec simplement le logo et le slogan de Frugalware. Je regrette simplement la disparition de la barre de progression.

Il s’agissait de ma sixiè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.

Installation et configuration de la clé Amarina 54Mbps Wireless USB Adapter sous Linux

Samedi 26 février 2011

Dans un précédent article, je vous avais expliqué comment j’avais installé et configuré Frugaware 1.3 (Haven) sur l’ordinateur de mon frère. Il me restait une dernière étape à expliquer, qui est, à mon humble avis, plutôt indépendante du modèle d’ordinateur ou de la distribution Linux : l’installation et la configuration de la clé USB Wifi de mon frère.

Il s’agit d’une clé de marque Amarina et de modèle Wireless Lan USB 54M 802.11G 54 Mbps (cf. page du produit).

Malheureusement, la clé n’est pas reconnue automatiquement sous Frugalware 1.3 (Haven) et il a fallu chercher longuement avant de pouvoir la faire fonctionner.
Comme souvent avec ce genre de produit, ce n’est pas vraiment la marque et le modèle du produit qui compte, mais la puce (chipset) qui est à l’intérieur.

La commande lsusb retourne la ligne suivante :

Bus 001 Device 002: ID 148f:2070 Ralink Technology, Corp.

Ceci laisse penser que la puce est une Ralink Technology 2070.

 

Mon frère et moi avons d’abord essayé d’utiliser le pilote ndiswrapper (pilote faisant office de sur-couche au dessus des pilotes Windows).

Pour cela, nous avions besoin des pilotes Windows. Le seul élément donné par le constructeur était un exécutable Windows (extension .exe). Nous avons cherché tous les moyens d’extraire les pilotes de cet exécutable. En vain… Nous avons finalement dû exécuter le fichier sur une machine Windows XP, ce qui revient à procéder à l’installation du pilote. Nous avons ainsi pu récupérer le pilote (pour cela, il suffit de chercher un fichier *.inf dans c:\windows).

Nous avons alors utilisé le pilote (un fichier .inf et des fichiers associés dans un même répertoire) pour configurer ndiswrapper. Malheureusement, cela n’a rien donné. Je ne me souviens pas du problème exact mais je me rappelle qu’une erreur survenait lors de l’initialisation du périphérique.

 

Nous nous sommes rabattus sur l’installation du pilote natif pour Linux. Pour cela, nous avons suivi les instructions données sur une discussion du forum Ubuntu.
Etant donné que les instructions sont données un peu dans tous les sens, et qu’elles sont incomplètes pour les dernières versions du noyau, ou inadaptées pour Frugalware 1.3 (Haven), je me permets de les résumer :

1) Télécharger les sources du pilote nommé RT3070USB(RT307x) sur la page Support Linux du site web de Ralink Technology, ou via le lien proposé sur la discussion du forum Ubuntu.

2) Prendre les droits root.

su -

3) Installer les sources du noyau.

pacman-g2 -S kernel-headers kernel-source

4) Désarchiver le paquet téléchargé et se déplacer dans le répertoire créé.

tar jxvf /2009_0525_RT3070_Linux_STA_v2.1.1.0.bz2

cd 2009_0525_RT3070_Linux_STA_v2.1.1.0

5) Modifier le fichier os/linux/usb_main_dev.c pour ajouter la ligne

{USB_DEVICE(0x148F,0×2070)}, /* Ralink 2070L */

juste en dessous de la ligne

#ifdef RT3070

6) Télécharger le patch attaché à la discussion du forum Ubuntu, ou celui attaché à cet article, puis l’appliquer.

cd ..

gunzip /rt3070-2.6.31-compile.patch.gz

patch -p0 < /rt3070-2.6.31-compile.patch

cd 2009_0525_RT3070_Linux_STA_v2.1.1.0/

Ceci est valable pour un noyau de version supérieure ou égale à 2.6.31, ce qui est le cas Frugalware 1.3 (Haven).

7) Modifier le fichier include/iface/rtmp_usb.h afin de remplacer les mots-clés usb_buffer_alloc et usb_buffer_free respectivement par les mots-clés usb_alloc_coherent et usb_free_coherent.

Ceci est valable pour un noyau récent, ce qui est le cas de Frugalware 1.3 (Haven), qui présente le noyau 2.6.35.8.

8) Modifier le fichier os/linux/config.mk pour activer le support WPA (replacer n par y pour la propriété HAS_WPA_SUPPLICANT).

9) Lancer la compilation du pilote.

make

10) Installer le pilote.

make install

11) Charger le pilote.

modprobe rt3070sta

 

Si tout se passe bien, la clé USB Wifi devrait se mettre à clignoter. L’interface réseau ra0 devrait apparaitre sur la sortie de la commande suivante :

ifconfig -a

Enfin, les réseaux Wifi disponibles doivent pouvoir être listés :

iwlist ra0 scan

 

Il reste alors à configurer l’interface réseau en utilisant, par exemple, netconfig ou wicd. Pour une raison complètement inconnue, je n’ai pas réussi à faire fonctionner la clé Wifi avec une adresse IP dynamique (DHCP) mais c’est peut-être dû au routeur utilisé.

 

Malheureusement, je dois avouer que je ne suis pas sûr à 100% de la procédure. Avec mon frère, nous avons dû pas mal tâtonner pour arriver à nos fins. Si j’ai l’occasion, j’essaierai de reconfirmer la procédure.

Comme vous pouvez le constater, le nombre d’opérations à effectuer est assez important. Idéalement, il serait intéressant de faire un paquet Frugalware pour automatiser les instructions et faciliter l’installation du pilote.

Néanmoins, j’espère que cet article sera utile à quelqu’un. Comme d’habitude, n’hésitez pas à laisser un commentaire si vous avez une remarque ou une question.

Installation et configuration de Frugalware 1.3 (Haven) sur Compaq Presario 2500

Mercredi 12 janvier 2011

Bonne nouvelle ! J’ai converti mon frère à Frugalware ! Il possède un ordinateur portable Compaq Presario 2500 et était précédemment sous SliTaz, une très bonne distribution à mon humble avis (de ce que j’en ai vu). Malgré tout, je lui ai conseillé de passer à Frugalware car je m’occupe régulièrement de l’administration de son PC et il n’était pas évident pour moi de passer du mode de fonctionnement d’une distribution à une autre.

Nous avons procédé à l’installation et à la configuration de la distribution Frugalware Linux 1.3 (Haven) sur cet ordinateur. Nous avons d’abord voulu tenter une installation « netinstall », mais nous avons galéré à cause de l’indisponibilité des serveurs FTP belge et français (nous soupçonnons fortement notre fournisseur d’accès sur ce point). Nous nous sommes alors rabattus sur l’installation « classique » à partir des deux premiers CDs. L’installation s’est alors bien déroulée, jusqu’à ce que l’installeur ne puisse pas reconnaitre le deuxième CD (probablement dû à la gravure sur CD-RW). Nous avons été contraints de terminer l’installation avec la moitié des paquets installés.

Le premier démarrage nous a amené tranquillement au login de la console texte (normal, car aucun gestionnaire de connexion n’avait pu être installé).

Avant de configurer un gestionnaire de connexion, nous avons vérifié que la session X était prête à fonctionner. Pour cela, nous avons lancé un premier startx. Cela s’est mal passé : une erreur indiquait que le module radeon n’avait pu être trouvé. Pour résoudre le problème, nous avons commenté toutes les lignes du fichier /etc/X11/xorg.conf.d/20-graphical.conf (et tant pis si cela n’est pas très optimal). Nous avons alors lancé un deuxième startx et la session X s’est lancée avec succès.

Cependant, un autre problème est apparu très rapidement : le touchpad ne fonctionnait pas. Un coup d’œil dans les traces a montré qu’il manquait le module synaptics (pilote de la plupart des touchpads d’ordinateur portable) :

pacman-g2 -S xf86-input-synaptics

Nous avons lancé startx pour la troisième fois, et là, le touchpad a réagi. Nous avons branché une souris USB, et elle a été reconnue immédiatement. Tout semble OK. Pour une fois, j’ai trouvé la configuration de X plutôt facile !

Afin que mon frère ne soit pas trop dépaysé par sa toute nouvelle distribution, je lui ai conseillé d’installer l’environnement de bureau LXDE (bureau par défaut de SliTaz) :

pacman-g2 -S lxde-desktop

Cet environnement vient avec son propre gestionnaire de connexions LXDM. Nous l’avons configuré afin que le système se connecte directement au compte de mon frère. Pour cela, nous avons renseigné le login du compte utilisateur à la propriété autologin, dans le fichier /etc/lxdm/lxdm.conf.

Après redémarrage,  nous avons obtenu ce que nous désirions : le système se connecte au compte utilisateur de mon frère et lance l’environnement de bureau LXDE.

Par défaut, nous nous sommes retrouvés avec un fond d’écran noir. Mon frère souhaitait quelque chose de plus « joli ». Après une longue recherche sur Internet, la solution la plus simple que nous ayons trouvée a été d’exécuter feh au démarrage de l’environnement de bureau. Pour cela, nous avons créé le fichier ~/.config/lxsession/LXDE/autostart avec le contenu suivant :

@feh –bg-scale /usr/share/lxde/wallpapers/lxde_green.jpg

Je ne sais pas si c’est vraiment utile mais nous avons également donné la permission d’exécution au fichier :

chmod +x ~/.config/lxsession/LXDE/autostart

Sous LXDE, le gestionnaire de fichiers est PCManFM. Mon frère avait déjà l’habitude d’utiliser ce logiciel sous SliTaz. Lorsqu’il insérait une clé USB, une entrée apparaissait automatiquement dans PCManFM, lui permettant de monter la clé et de parcourir son contenu. Afin de conserver ce comportement, nous avons créé un répertoire de montage :

mkdir /media/usb

Puis nous avons simplement ajouté la ligne suivante à la fin du fichier /etc/fstab :

/dev/sda1        /media/usb            auto        defaults,noauto,user         1   1

Ainsi, nous associons le périphérique /dev/sda1 (nom usuel du périphérique pour une clé USB) avec le point de montage /media/usb, en autorisant n’importe quel utilisateur à monter/démonter le système de fichier (option user).

Pour le son, nous avons d’abord installé les outils ALSA :

pacman-g2 -S alsa-utils

Ensuite, nous avons exécuté la commande alsaconf et suivi les instructions. La carte son a été bien reconnue et était directement prête à l’emploi.

A cette étape, nous avons cherché désespérément un contrôleur de volume. Après plusieurs dizaines de minutes, nous nous sommes rendus compte qu’un contrôleur de volume était déjà présent dans le tableau de bord LXDE (la barre en bas de l’écran). En fait, comme ce tableau de bord est noir par défaut, et que l’icône du contrôleur de volume est aussi noire, nous n’avions pu le voir…

Afin de disposer d’un écran de démarrage et d’arrêt du système, nous avons installé  splashy :

pacman-g2 -S splashy

Après redémarrage, nous avons malheureusement constaté que l’écran ne s’affichait pas correctement. Au départ, je pensais que l’image s’affichait en vidéo inversé, mais il semble plutôt que le mode vidéo n’ait pas assez de couleurs disponibles pour afficher correctement l’image. Je pense que ce problème vient de la carte graphique de l’ordinateur (ATI Radeon). Je n’ai pas analysé davantage, mon frère ayant considéré le problème comme mineur. Cependant, si vous avez des idées sur ce problème, je serai content de les connaitre.

La dernière étape de la configuration a été d’installer la clé USB Wifi de mon frère. Etant donné qu’il s’agit d’un élément extérieur à l’ordinateur portable lui-même, et que l’opération est un peu longue à expliquer, je préfère garder ce sujet pour un prochain article.

Au final, je pense que mon frère est globalement satisfait de sa nouvelle distribution. Le système démarre assez rapidement et est tout à fait utilisable (comparativement à l’âge de la machine).

Si vous avez des idées alternatives ou des corrections à apporter aux problèmes décrits dans cet article, je vous invite à utiliser les commentaires.

Mon passage à Frugalware 1.3 (Haven)

Samedi 30 octobre 2010

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.

123