| Le royaume de Eric Buist >> Informatique >> Configuration informatique | ||
| Me contacter | Plan du site | |
| << Installation de ports USB avant: un voyage en enfer cybernétique | Passage à Fedora Core 4 | Remplacement de mon synthoniseur TV >> |
En juin 2005, voilà que Fedora Core 4 était sorti. GNOME 2.10, KDE 3.4, GCC 4, teTeX 3, intéressant. Mardi, le 14 juin exactement, je disposais d'un DVD+R contenant la nouvelle version de cette distribution de Linux, obtenu encore une fois par BitTorrent. Toutefois, au moment du téléchargement, je n'étais pas certain de l'installer, puisque Fedora Core 3 fonctionnait assez bien et je n'avais pas envie de me taper du déboguage à plus finir. Comme d'habitude, j'éprouvai de multiples problèmes mais seulement après une réinstallation.
Vendredi, 17 juin, j'eus de la misère noire avec Linux. Je tentai pendant un temps fou de régler ALSAMixer pour obtenir un son correct, mais ça ne cessait de gricher légèrement dans mon haut-parleur avant gauche. Je tentai aussi de transférer des CD sur mon disque dur et GRip, le programme que j'utilise habituellement pour ça, ne cessait de me faire redémarrer. J'essayai, tanné, avec Sound Juicer, un autre logiciel d'extraction audio, mais ce dernier refusait de démarrer. Il y eut de multiples problèmes avec Linux et avec mon ordinateur en général: des sites Web difficiles à lire, la connexion à Internet devenue trop lente, etc. Je passai plus de trois quarts d'heure, un bon soir, à tenter d'imprimer un simple document sous Linux! C'était une page Web traitant de SELinux et venant du site de Fedora Core. Bientôt, il faudra que j'utilise Windows simplement pour imprimer des informations sur Linux! Cette contradiction me frustrait au plus haut point. Je dus aussi désactiver SELinux, car Fedora a modifié la politique de sécurité, empêchant GnuPG et Adobe Reader de fonctionner. Il faudrait probablement recompiler GnuPG pour une édition de liens statique plutôt que dynamique et me passer d'Adobe Reader en attendant une hypothétique version ultérieure qui résoudrait peut-être le problème. Désactiver SELinux était la meilleure solution!
Mardi, 28 juin 2005, je me résolus à tester Fedora Core 4. Si je perdais des plumes après l'installation, par exemple le graveur cessant de fonctionner ou l'accélération 3D, je débarrasserais ma machine de Linux et reformaterais tout en NTFS. J'allais attendre la noyau 2.8 avant d'essayer de nouveau le système.
L'installation de Fedora Core 4, qui eut lieu samedi, 2 juillet 2005, se passa très bien! Cette fois-ci, je n'activai pas SELinux, mais j'essayai le pare-feu. Je dus le désactiver, car il m'empêchait d'utiliser Samba pour partager des fichiers. Aucune option ne permettait de déverrouiller les ports nécessaires, il fallait tout faire manuellement. Désactiver le pare-feu IPTables régla le problème et évita beaucoup de niaisage. Je suis tanné d'écrire des commandes qui sont tellement complexes qu'elles ne fonctionnent jamais et les commandes pour configurer IPTables sont de cette catégorie. La solution est de copier/coller les commandes depuis une page Web quelconque, et encore. Je ne pus utiliser le fichier yum.conf de Fedora FAQ, car YUM plantait avec ce dernier. Il me fallut extraire des informations de ce fichier afin de créer plusieurs fichiers de configuration dans /etc/yum.repos.d. Le fichier le plus important est livna-stable.repo qui contient ceci:
[livna-stable] name=Livna.org - Fedora Compatible Packages (stable) baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.lvn http://livna.cat.pdx.edu/fedora/$releasever/$basearch/RPMS.lvn gpgcheck=0
Je dus inférer les chemins à partir de ceux de Fedora Core 3, en accédant au site Web avec Mozilla. Livna m'a permis d'installer le support MP3 dans XMMS, le lecteur DVD Kaffeine, etc.
Contrairement à la dernière fois, j'ai conservé Fedora Core 3 sur mon disque dur, sur une autre partition. Comme ça, je pourrais revenir à l'ancienne distribution si celle-là ne me convient pas; le besoin ne se fit jamais sentir! Toutefois, conserver FC3 m'a permis de recopier bon nombre de fichiers de configuration, me sauvant temps et tâtonnement. Il y a malheureusement deux bogues. Tout d'abord, la mise à jour automatique ne fonctionne plus. L'icône reste verte, comme sous Mandrake, même s'il y a de nouvelles mises à jour. Sur la console, il me faut ainsi appeler yum update régulièrement. Il y eut aussi le son qui était beaucoup moins bon que sous Fedora Core 3. Pour résoudre ce bogue très tannant, je dus démarrer alsamixer et mettre Sigmatel 4-Speaker stereo sur Muet.
Pour Java, j'ai voulu tenter une autre approche qu'auparavant: construire un RPM personnalisé compatible JPackage. Le projet JPackage met à disposition des utilisateurs Linux des RPMs contenant différentes applications et bibliothèques Java. Ils ne proposent pas des RPMs pour JDK de Sun, car sa distribution est interdite. Il faut ainsi créer les RPMs manuellement; j'ai tenté de le faire et ça a fonctionné. La procédure est détaillée sur le site JPackage et un lien vers cette dernière est disponible sur FedoraFAQ. Puisque Java est à présent intégré à JPackage, il ne devrait plus y avoir de conflits avec GCJ, comme j'ai déjà vécu par le passé.
Ainsi, le passage à Fedora Core 4 n'a pas occasionné de problèmes insolubles. C'est donc une très bonne chose et la distribution fonctionne très bien. FC4 est même plus rapide à démarrer que FC3, peut-être à cause des optimisations dans GCC 4 utilisé pour compiler les éléments du système. J'ai bien cru que ce nouveau Linux allait redonner vie à ma machine qui me semblait de plus en plus déclinante, mais une nouvelle expérience hasardeuse viendra troubler ma confiance.
Vendredi, 23 septembre 2005, j'ai effectué un grand nombre d'expérimentations dans le but de faire fonctionner mon nouveau TV tuner Hauppage WinTV PVR-150 sous Linux. J'ai découvert qu'il fallait installer IvTV, un module de noyau qui n'était pas intégré en standard et la version 0.2-rc3j de ce module ne compilait pas avec le noyau 2.6.12 de Fedora Core 4! Je parvins non sans mal à bidouiller son code source pour le rendre compilable, mais je ne pus obtenir que de la statique, comme sur un téléviseur qui ne serait pas raccordé au câble ou à une antenne. Je découvrirais dimanche, 2 octobre 2005, que je ne disposais pas de la version la plus récente du module. La version 0.2-rc3k compilait mais ne fonctionnait pas mieux. Seule la version 0.3.9 de développement me permit d'avoir une image de façon stable.
Revenons maintenant au 23 septembre, le premier soir de test. Ce soir-là, je n'obtenais rien du tout et je pensai qu'installer le logiciel MythTV pourrait améliorer mon sort. Étant donné que yum install mythtv ne fonctionnait pas, je téléchargeai son code source et tentai de le compiler. Surprise: MythTV 0.18.1 ne compile pas sous Fedora Core 4, probablement une incompatibilité avec GCC 4! Je parvins à faire avancer le processus de compilation en modifiant des fichiers source, mais je finis par tomber sur une partie en code assembleur qui ne compilait même pas!
Je tentai alors d'installer une version précompilée de MythTV à travers ATRpms. Je dus pour cela ajouter un nouveau fichier atrpms.repo dans /etc/ym.repos.d et taper yum install mythtv-suite. Il en résulta l'installation d'une cinquantaine de paquetages et la mise à jour de certains paquetages de mon système. MythTV s'avéra complexe à configurer, nécessitant la création d'une base de données MySQL. De plus, jamais le logiciel ne voulut détecter mon TV tuner. Lorsque je découvris comment le configurer correctement pour qu'il produise de la statique plutôt que rien du tout, le tuner put être détecté par MythTV, mais MythTV ne voulut jamais démarrer. MythTV me demandait d'appeler mythtv-frontend qui, lui, cherchait mythtv-backend. MythTV semble un gros logiciel dont plusieurs éléments sont superflus. Il est probable qu'il ne fonctionne que sous certaines versions de certaines distributions de Linux seulement. Malheureusement, beaucoup de sites Web qui ne sont pas actualisés en fonction des nouvelles versions de MythTV et/ou de Linux considèrent uniquement ce logiciel comme solution pour exploiter un TV tuner. Il faut décidément trouver une autre alternative, car MythTV n'est pas viable sous Fedora Core 4.
Au cours de la journée de samedi, j'utilisai la commande yum update, ce qui installa une centaine de mises à jour. Étant donné que ATRpms se trouvait désormais parmi mes sources de mises à jour, Yum installa tout ce qu'il put y trouver! Le lendemain, Yum me proposa encore une centaine de mises à jour! Je compris vite qu'il y avait un problème et découvris que ATRpms avait installé de nouveaux fichiers dans /etc/ym.repos.d. Ces fichiers incluaient des liens vers ATRpms et d'autres sites, ce qui avait provoqué le remplacement de mes paquetages par des versions de test que je ne voulais pas. Il n'y eut aucun moyen de revenir en arrière. Mon unique tentative pour stopper le mal me supprima l'accès à Yum que je pus retrouver en réinstallant manuellement le paquetage supprimé. C'est dimanche, 25 septembre 2005, que je dus déclarer mon installation de Linux sabotée et à refaire!
Dimanche, 25 septembre 2005, j'entrepris ainsi de réinstaller Linux. J'optai encore une fois pour une installation complète et désactivai SELinux et le pare-feu. L'installation se passa très bien, comme la dernière fois, si bien que j'aboutis sous GNOME. J'ouvris une console et tapai yum update pour télécharger toutes les mises à jour.
Après un temps fou, l'opération échoua, Yum rapportant un conflit entre des paquetages. Pour résoudre le conflit, je dus taper
rpm -e cman-kernel cman-kernheaders cman dlm-kernel dlm-kernheaders dlm dlm-devel gnbd gnbd-kernel gnbd-kernheaders
Cela permit à Yum d'accomplir toute la phase de téléchargement des nouveaux paquetages, mais il planta au moment d'installer! Je dus, pour résoudre ce second plantage, supprimer le paquetage kdelibs-i18n-Polish. Comme on peut le deviner à partir de son nom, ce paquetage s'avère parfaitement inutile pour moi et le supprimer ne me fit pas un pli.
Le reste de la configuration se passa comme avec mon installation précédente et ne souleva pas de problèmes particuliers. En une journée, je disposais déjà d'un système Linux à peu près complet et fonctionnel, pilote NVIDIA installé et fontes ajustées. Malheureusement, c'est à partir de ce jour que Fedora Core a commencé à perdre des fonctionnalités. La plupart des bogues purent être résolus, mais ils me firent tous perdre un temps précieux.
Lundi, 26 septembre 2005, je constatai que Samba ne fonctionnait plus du tout. L'appel de smbclient -L faucondefer provoquait l'effet escompté, mais si j'utilisais smbclient -L buist pour afficher la liste des partages sur la machine familiale, rien ne se passait. Le logiciel attendait pendant plusieurs secondes avant de déclarer qu'il ne pouvait pas se connecter. J'essayai vers une autre machine, une vieille picouille tournant sous Windows 95, et obtins le même résultat. L'erreur contenait le message Called name not present, comme si la machine distante ne répondait pas. Sous Windows, par contre, tout fonctionnait très bien. La seule façon, désormais, de me brancher sur les machines distantes était d'utiliser des adresses IP plutôt que des noms en clair. Par exemple, je devrais utiliser //192.168.1.2/data plutôt que //buist/data comme nom de partage réseau pour accéder aux données de la machine familiale. Cela impliquait des modifications dans mes scripts de sauvegarde automatique que je trouvais totalement ridicules. Pourquoi, à présent, est-ce que je perdais cette fonctionnalité qui n'avait jamais bogué auparavant?
Notez que puisque mon routeur n'implante pas le protocole SMB, ces partages ne sont pas accessibles depuis l'extérieur si bien que je peux donner leur nom en toute sécurité. En théorie du moins...
Si je tapais nslookup faucondefer, j'obtenais une IP locale: 192.168.1.5. NSLookup permet de transformer un nom de machine NetBIOS en une IP. Toutefois, si je tapais host faucondefer, j'obtenais une IP différente, celle de mon domaine ericbuist.com! Il y avait donc un défaut de configuration; il ne fallait pas mettre faucondefer.ericbuist.com comme nom d'hôte de la machine. Corriger le bogue Samba nécessita plusieurs étapes simples.
Pour mes scripts de sauvegarde, j'utilisais smbmount qui ne fonctionnait plus. Je dus, pour le réparer, utiliser chmod u+s /usr/bin/smbmnt /usr/bin/smbumount. Une alternative a SMBMount est l'usage du système de fichiers CIFS. Il faut par contre inclure des lignes additionnelles dans /etc/fstab qui est mystérieusement tripoté par un programme. Rien ne me disait que les lignes que j'ajouteraient ne disparaîtraient pas au prochain démarrage.
Par exemple, à l'insertion de ma clé USB, le périphérique /dev/sda que j'avais pris soin de configurer s'était modifié de lui-même. Il est par contre possible que cette fonctionnalité rende possible l'usage de clés USB sur des machines Linux sans disposer d'un accès root pour configurer le système, ce qui est plus qu'intéressant.
Mardi, 27 septembre 2005, j'eus plusieurs recherches à faire sur Internet pour un projet de cours. Sous Linux, le réseau était très lent tandis que je gagnai de la vitesse en redémarrant sous Windows. Pourtant, j'avais bien ajouté la ligne alias net-pf-10 off dans /etc/modprobe.conf pour désactiver IPv6.
Pour tenter de résoudre ce problème, j'essayai de me brancher à mon routeur et obtins les serveurs DNS de Vidéotron. Dans mon fichier /etc/resolv.conf, je remplaçai 192.168.1.1 (mon routeur) par ces DNS, une IP par ligne. Cela semblait avoir accru la vitesse de recherche des pages Web et résolu le problème.
Vendredi, 30 septembre, l'appel de yum update installa le noyau 2.6.13-1.1526. Je dus, pour faire face à cette mise à jour, télécharger un nouveau module NTFS, recompiler le pilote IvTV de mon TV tuner et réinstaller le pilote NVIDIA de ma carte graphique après un redémarrage dans le noyau 2.6.13. Je constatai toutefois que le volume du son était réduit de beaucoup.
J'activai alors alsamixer et constatai que plusieurs réglages du mixer étaient disparus. Je me rendis ensuite compte que le son ne jouait que dans les haut-parleurs centre et arrière. Si je reconfigurais mes haut-parleurs pour qu'ils ne considèrent comme signal d'entrée que les canaux avant gauche et avant droit, il n'y avait plus de son du tout, ce qui confirmait mon diagnostic. Il n'y eut absolument rien à faire pour résoudre le bogue, à part revenir au noyau 2.6.12-1.1456!
Ce problème semblait lié au noyau 2.6.13 lui-même et il se pouvait fort bien qu'il se manifeste pour toutes les versions futures du noyau, à moins de changer ma carte son. Toutefois, je constatai que même avec une Sound Blaster Audigy, j'éprouverais le même bogue, car cette carte est aussi gérée par le module EMU10k1. Tant que Fedora Core 5 ne devenait pas disponible, rester avec le noyau 2.6.12 demeurait la meilleure solution. Toutefois, lorsqu'une nouvelle version de Linux verrait le jour, elle comporterait le noyau 2.6.13 ou 2.6.14. Si le son ne fonctionnait toujours pas, il allait falloir m'en passer ou recompiler le noyau 2.6.12. Je pourrais toujours tenter ma chance avec OSS, mais ce serait encore un ensemble de modules à code source fermé causant problèmes par-dessus problèmes.
Cela me désespéra, mais je me résolus à attendre la sortie de Fedora Core 5 pour agir. Il était possible qu'une mise à jour vienne entre temps corriger le bogue. Dans le cas contraire, si Fedora Core 5 éprouvait le même bogue et qu'il n'était pas possible de le résoudre sans recompiler manuellement le noyau 2.6.12, je me débarrasserais de Linux. Le son serait la dernière fonctionnalité qu'on m'enlèverait.
Heureusement, vendredi, 21 octobre 2005, j'installai le nouveau noyau 2.6.13-1.1532_FC4 et tout rentra dans l'ordre. Je dus par contre, dans alsamixer, reconfigurer certains volumes et réactiver des sources audio, dont Master.
Voilà quelques temps, je suis tombé sur Filesystem in Userspace (FUSE), une extension très intéressante qui permet d'incorporer de nouveaux systèmes de fichiers dans le noyau. Certains systèmes de fichiers sont en effet trop complexes pour être implémentés dans un module de noyau sans récrire beaucoup de code qui existe déjà. FUSE permet d'implémenter de tels systèmes dans des programmes traditionnels, dits user space, plutôt que dans des modules, dits kernel space. Cela permet entre autre toutes sortes d'implémentations ésotériques du système de fichiers NTFS de Microsoft, comme par exemple Captive NTFS qui utilise carrément le code de Microsoft! Mes premiers essais avec FUSE échouèrent, car il fallait compiler un module de noyau qui refusa de fonctionner. Mes expérimentations avec Captive furent également un échec, car il ne voulut jamais charger le gestionnaire NTFS de Microsoft.
Par hasard, un bon jour, je découvris que FUSE était désormais intégré au noyau 2.6.14, ce qui simplifiait grandement les choses. Pour utiliser FUSE, avec Yum, j'installai les paquetages fuse, fuse-libs, fuse-devel et fuse-sshfs.
Ce n'est que lundi, 23 janvier 2006, sur ma nouvelle machine Salvator, que je fis de véritables expérimentations. Cela commença par une visite sur Linux NTFS pour obtenir des informations plus détaillées à propos de NTFS. J'essayais de savoir pourquoi l'écriture sur NTFS n'était toujours pas possible sous Linux sans installer des modules qui ne fonctionnent que sur un système sur deux. Est-ce en raison de l'incroyable complexité du système de fichiers lui-même ou est-ce par manque d'informations? S'il n'est pas possible d'obtenir la spécification du système NTFS, peut-être a-t-il été possible de découvrir les structures de base suffisantes pour la lecture, mais toute la structure doit être connue pour la modifier sans tout casser. Je découvris qu'il existait désormais un module FUSE implémentant partiellement l'écriture sur NTFS, ce qui me surprit agréablement! Bien que ce module ne traitait pas encore tous les cas et que l'écriture échouait de temps en temps, sa présence signifiait une progression: peut-être un jour serait-il possible d'écrire sur du NTFS comme sur du FAT32! Je dus, pour utiliser le nouveau pilote NTFS, télécharger ntfsprogs et le compiler. Utiliser le paquetage RPM était hors de question, car il n'était pas fait pour x86_64. J'aurais pu l'essayer, ça aurait sans doute très bien fonctionné, mais autant avoir une version 64 bits. La compilation réussit, mais le logiciel que je cherchais, ntfsmount, brillait par son absence. Je dus installer le paquetage fuse-devel et tenter de recompiler ntfsprogs: cela fonctionna!
Grâce à ntfsmount, en root, je parvins à monter ma partition NTFS de données et j'y transférai un gigantesque fichier de 7Go créé la veille sur ma partition de données Ext3. Le transfert était impossible autrement, car le fichier n'aurait pas tenu sur une partition FAT32. J'aurais été forcé de le casser en deux parties. Ce fichier contenait un film que j'ai enregistré avec mon synthoniseur TV et qui était destiné à divers traitements expérimentaux dont une gravure sur DVD. Des logiciels pour Windows étaient nécessaires pour la coupure des pauses publicitaires ainsi que pour la création simple de la structure DVD-Video. La copie fonctionna à merveille, bien qu'elle fut un peu longue.
Je décidai donc de rendre ma partition de données NTFS accessible en écriture de façon permanente en modifiant /etc/fstab. La ligne permettant cela dans mon cas se présente comme suit:
/dev/sda7 /mnt/windata ntfs-fuse umask=0,default_permissions,allow_other 0 0
Étant donné que ce module FUSE n'implémente pas tous les aspects de l'écriture NTFS et qu'il est possible que le système de fichiers soit endommagé par une écriture incorrecte, je décidai de laisser ma partition Windows, sur /dev/sda1, en lecture seule. Je n'avais pas du tout envie de devoir réinstaller Windows à cause du module NTFS de Linux!
Une seconde expérience avec FUSE échoua complètement, du moins la première tentative. En tant qu'utilisateur, j'essayai sshfs. Cette commande pourrait me permettre d'accéder à mon compte à l'université comme à un répertoire sur mon système, ce qui simplifierait les transferts de fichiers. Malheureusement, sshfs refusa de démarrer en mode utilisateur, prétextant que fusermount n'avait pas les permissions nécessaires.
La solution consistait à ajouter mon utilisateur dans le groupe fuse et à redémarrer ma session. Je ne fis que l'ajout au groupe et n'obtins aucun résultat. Je tentai vainement de trouver des indices sur Internet, ce qui me mena à une telle frustration que je tentai de voir si je ne pourrais pas passer à Mandriva 2006. Cette distribution, au moins, a plus de fonctionnalités intégrées que Fedora Core 4; il y avait des chances que SSHFS fonctionne bien, ainsi que bien d'autres choses. Mais le x86_64, faudrait oublier, à moins de prendre la version CD plutôt que la version DVD!
Mardi soir, 24 janvier 2006, je réessayai SSHFS et cette fois-ci, cela fonctionnait! Je dus me créer un répertoire dans mon compte (mkdir tst) et utiliser sshfs buisteri@frontal.iro.umontreal.ca: tst. Je dus entrer mon mot de passe DIRO après quoi le répertoire tst contenait mon compte. Malheureusement, les liens symboliques ne fonctionnaient pas, mais c'était déjà impressionnant. Je dus utiliser fusermount -u tst pour démonter le système SSH après avoir supprimé quelques fichiers inutiles sur mon compte.
Ces bogues remirent en question ma résolution à conserver Linux sur ma machine. En effet, toutes les raisons pour lesquelles je conserve ce système d'exploitation devenaient de moins en moins valables.
C'est ainsi que je souhaite conserver Linux le plus longtemps possible sur ma machine. Lorsque j'aurai cessé d'utiliser le système, Bill Gates aura gagné contre moi et je devrai éventuellement choisir entre ne plus avoir de machine personnelle ou payer un abonnement pour Windows lorsque Microsoft en sera rendu à ce point.