| Le royaume de Eric Buist >> Informatique >> Configuration informatique | ||
| Me contacter | Plan du site | |
| << Passage à Mandrake 10.1 | Passage à Fedora Core 3 | Installation de ports USB avant: un voyage en enfer cybernétique >> |
Le bogue m'ayant incité à quitter Mandrake 10.1 est malheureusement assez subtil et il me faudra bon nombre de mots pour le faire comprendre à un lecteur ne l'ayant jamais rencontré. En bref, un paquetage posait problème et Mandrake ne fournissait aucune mise à jour, à moins de reconfigurer URPMI d'une façon inacceptable.
Le bogue est en fait lié à LaTeX, un système de préparation de documents spécialement adapté pour les articles scientifiques contenant beaucoup de notation mathématique. LaTeX peut également fonctionne pour d'autres types de documents comme des lettres et je m'en sers même pour écrire mon journal intime! En guise d'exemple, mon didacticiel sur la gravure de CD/DVD a été écrit grâce à ce logiciel.
Un document LaTeX consiste en un simple fichier texte auquel est associé par convention l'extension .tex. Ce fichier contient le texte qui doit être formaté ainsi que diverses séquences de contrôle permettant d'indiquer comment le formater. Par exemple, des commandes sont disponibles pour créer des sections, mettre en évidence, ... Deux processus sont disponibles pour transformer un tel document dans un format plus courant, à savoir le Portable Document Format (PDF) qui peut être pris en charge par Adobe Reader.
ps2pdf est un script shell qui utilise en interne l'interpréteur PostScript GhostScript. C'est GhostScript qui est responsable du subtil bogue présent sous Mandrake 10.1. Plutôt qu'incorporer la version standard de GNU, Mandrakesoft utilisa la version ESP. Cette version est mieux adaptée au système Common UNIX Printing System (CUPS) permettant le support simplifié des imprimantes sous UNIX/Linux. CUPS reçoit, comme tout système d'impression UNIX/Linux, des fichiers PostScript. Ces fichiers sont convertis grâce à un pilote spécial pour GhostScript. ESP GhostScript contient d'office ce pilote tandis que GNU GhostScript doit être patché pour l'y incorporer. C'est pourquoi Mandrake a choisi ESP GhostScript.
Le bogue se trouve dans ESP, car la même version (GNU) sur les systèmes Fedora Core 3 de mon université fonctionne parfaitement. Ainsi, pour résoudre le bogue, il me fallait une mise à jour de ESP GhostScript ou un passage à GNU GhostScript. Toutefois, Mandrake cherche à transformer sa distribution en produit commercial et de nouvelles fonctionnalités n'apparaissent que lorsqu'un nouvelle version est produite. Une mise à jour de version d'un paquetage est considérée, on dirait, comem un ajout de fonctionnalité et n'arrive que rarement, voire jamais! C'est ce défaut qui m'a poussé à passer de Mandrake 10.0 à 10.1. Outre attendre la 10.2 ou tenter de télécharger le GhostScript de Cooker, il n'y avait aucune autre solution que la longue et douteuse procédure suivante.
Le bogue GhostScript était la raison principale de ma mise à jour, l'autre raison étant la curiosité de voir GNOME 2.8 et KDE 3.3.
L'année 2005 a vu survenir bien des changements chez Mandrake. D'abord, la firme française a acheté la société Connectiva et a changé son nom pour témoigner de cette fusion. Mandrake se nomme à présent Mandriva. Jusqu'à la version 10.1, une nouvelle version de Mandriva Linux sortait environ aux six mois. En 2005, le cycle fut rendu annuel et une version de transition appelée 2005 Limited Edition serait disponible.
Premier inconvénient: cette version n'est disponible que pour les membres du MandrivaClub ou par le biais du MandrivaStore. Toutefois, je me trouvais dans le club et pour rentabiliser mon abonnement, j'avais estimé qu'il me fallait obtenir au moins deux Linux commerciaux Mandriva. Eh bien la 2005 LE serait le second, 10.1 Powerpack étant le premier. Vendredi, 15 avril 2005, j'ai appris que Mandriva Linux édition limitée 2005 était sortie. Cette distribution promettait GNOME 2.8, KDE 3.3 et une version plus à jour de GhostScript qui ne causerait plus les problèmes de fontes rencontrés avec ESP GhostScript sous Mandrake 10.1. Je voulais ainsi mettre la main sur ce nouveau Linux et je pus le faire par BitTorrent, comme j'ai fait avec 10.1.
Le téléchargement dura plus de trois heures, menaçant bien entendu de me faire dépasser la limite de 10Go de Vidéotron (Une grande vigilence s'imposait!) et je dus le terminer le lendemain matin. Je vérifiai que l'image ISO obtenue avait la bonne somme de contrôle, en testant la somme MD5 et SHA1. Je gravai cette version Powerpack sur DVD+R puis vérifiai le contenu du disque. Tout était fin prêt pour tenter la réinstallation. La première chose qui m'a frappé a été l'absence du nouveau nom Mandriva dans la distribution: ils utilisaient encore Mandrake. Le fichier VERSION, à la racine du CD, contenait
Mandrakelinux 10.2 cooker-Powerpack-i586-Limited-Edition-2005 20050413 10:07et Cooker est le nom de code de la branche en développement actif de Mandriva. Cela créa une légère réticence chez moi, mais je la réprimai et tentai l'installation. Il faut après tout garder l'esprit un tant soit peu ouvert.
La procédure se passa très bien, sauf la sélection des paquetages qui fut très longue. Comme sous 10.1, je ne vis pas la case à cocher pour sélectionner les paquetages individuels, l'installation commença, mais cette fois, le bouton Annuler ne répondit pas. Il me fallut utiliser reset et recommencer l'installation, après bien entendu avoir reformaté ma partition Ext3fs pour supprimer les déchets produits par le reset. À la seconde tentative, je trouvai le bouton.
Après l'installation, Mandriva m'offrit de faire une mise à jour que j'acceptai. L'installeur me demanda de sélectionner un miroir parmi une liste. Je ne me souviens plus si j'en ai pris un au hasard ou si j'ai laissé celui sélectionné sans le changer, mais les deux reviennent à peu près au même. Comme sous 10.1, il prit un temps considérable à se relier au site, mais il y parvint. La mise à jour dura très longtemps, car on aurait dit qu'il téléchargeait tout de nouveau!
Lorsque ce fut enfin fini, je fus amené à redémarrer la machine et je vis Mandrake apparaître. Le démarrage fut long, plus long que sous Mandrake 10.1. Je me retrouvai finalement sous X et un assistant me demanda si j'étais dans le MandrakeClub. Je dis Oui et on me fit entrer mon identifiant et mon mot de passe. Toutefois, le clavier ne répondait pas. Agacé par ces bogues stupides qui sont tellement nombreux que j'en viens à croire que c'est une tentative ratée d'humour noir, je dus cliquer sur Annuler puis KDE démarra. Le démarrage de KDE dura au moins vingt secondes, sinon trente! J'essayai de double-cliquer sur MandrakeOnline pour le configurer, il se plaignit d'un problème de connexion Internet. Décidément, MandrakeOnline ne fonctionnerait pas mieux que sous 10.1! Ou il y avait un problème de configuration Internet.
Première chose: démarrer une Konsole pour vérifier Internet avec un Ping. Alt-F2 suivi de konsole puis Enter ne provoqua absolument aucun effet. Un second essai ne fut guère plus fructueux. Une tentative de cliquer sur l'icône de la console ne provoqua aucun effet. Choqué, je fermai ma session et redémarrai sous GNOME. En passant, KDE souffre toujours du bogue de pointeur de souris: seuls de petits curseurs sont offerts et aucun moyen de les agrandir! GNOME 2.8 permet toujours le changement du curseur par le biais du fichier .Xresources, comme je le faisais sous Red Hat 9.
Sous GNOME, je pus obtenir un GNOME-Terminal dont je grossis la police à Monospace 18. Internet fonctionnait, c'était MandrakeOnline qui boguait. Il était temps de commencer à recopier les fichiers de configuration issus de Mandrake 10.1. Cela me permettrait de gagner un temps fou avec les problèmes de fontes. Je commençai par Firefox, le navigateur Web. Ce dernier ne semblait pas installé! Choqué, étant certain de l'avoir sélectionné parmi les paquetages à installer, vérifiai s'il était installé et oui il était là! Je découvris que l'exécutable firefox avait été renommé mozilla-firefox. Firefox démarra et fonctionna bien, mais Thunderbird (client e-mail) ne voulut JAMAIS démarrer!
Je tentai de le démarrer depuis la console et obtins des messages d'erreur répétitifs à propos de symboles introuvables dans rpnp.so. Le paquetage RealPlayer prit le bord puis une nouvelle tentative eut lieu: boucle infinie! Aucun message d'erreur. Après un temps considérable, il finissait par afficher quelque chose à propos de GConf qui avait ouvert un trop grand nombre de fichiers. Je finis par tenter de démarrer konsole depuis la fenêtre du GNOME-Terminal et obtins ceci:
konsole: symbol lookup error: /usr/lib/libkdeinit_konsole.so: undefined symbol: _ZN19KAcceleratorManager10setNoAccelEP7QWidgetIl semblait donc qu'il y ait des incompatibilités entre les différents exécutables contenus dans la distribution. Mandriva Linux 2005 Limited Edition portait bien son nom: c'était une édition limitée! Limitée en distribution mais aussi en fonctionnalités! Cela me choque beaucoup de constater à quel point le système Linux s'éait détérioré depuis que Red Hat était devenu commercial.
Il y aurait certes eu moyen de faire fonctionner ThunderBird en désinstallant le RPM Mandrake et en réinstallant la version que j'avais sous 10.1, venue du site officiel de Mozilla, mais pour Konsole, que pouvais-je faire? Recompiler KDE au grand complet! Il semble que de plus en plus d'applications Mandrake nécessitent ce traitement: supprimer le RPM, télécharger depuis le site officiel, recompiler. Mozilla (pour le mettre à jour), GhostScript (pour pouvoir transformer des PostScript issus de LaTeX en PDF) et maintenant tout le système KDE pour que la Konsole fonctionne.
J'aurais pu me passer de cette Konsole puisque je travaillais sous GNOME, mais qui me disait que d'autres programmes n'allaient pas me faire faux bond dans le futur?
En effet, je découvris ultérieurement que XMMS fonctionnait lui aussi très mal. Son démarrage prenait plus de trente secondes et il se bloquait périodiquement, nécessitant plusieurs secondes avant de daigner répondre de nouveau. XMMS est le lecteur MP3 Linux le plus proche de Winamp. Pour moi, il est tout simplement indispensable, car les autres lecteurs utilisent des raccourcis clavier totalement différents, ou pas de raccourcis clavier du tout!
Le bogue du pointeur de souris noir revint en force et possiblement le problème DRI connu sous 10.1. Je n'ai pas gardé ce Linux suffisamment longtemps pour vérifier. Bien entendu, on ne s'étonnera pas d'apprendre que mon TV Tuner ne fonctionnait pas.
Je tentai, avant de tout supprimer, d'envoyer des emssages sur le forum MandrivaClub. J'appris que j'étais pratiquement le seul à éprouver ce genre de difficultés et que j'allais sans doute devoir changer ma configuration matérielle et acheter la distribution sur MandrivaStore pour que cela fonctionne!
Je découvris, au fil de mes recherches, que le système avait installé des éléments de KDE 3.4 pendant la mise à jour et ces éléments étaient incompatibles avec KDE 3.3. Il y avait donc eu un mauvais choix de miroir qui avait endommagé mon installation. Je tentai de supprimer le paquetage fautif (pour la console KDE) avec urpme, le logiciel me demanda confirmation, puis il me signala qu'il devait supprimer un nombre multiple de paquetages, à peu près tout KDE! C'est alors que je rendis les armes. Il fallait retourner à 10.1 ou changer de machine, c'était aussi dingue que ça!
Voici mes hypothèses tentant d'expliquer pourquoi cela a si mal fonctionné. Je place ces hypothèses en ordre décroissant de plausibilité.
Déçu, je suis retourné sous Windows, décidé à y rester jusqu'à avoir téléchargé Fedora Core 3. Malheureusement, jamais BitTorrent ne voulut fonctionner et le téléchargement FTP serait beaucoup trop lent. Il téléchargeait très lentement et ne voulait pas utiliser mes ports 12345 et 12346 que j'ai configurés sur la machine Buist pour rediriger vers mon ordinateur. Sans ces ports entrants, BitTorrent ne pourrait télécharger efficacement.
J'essayai avec Azureus et ça ne fonctionna pas davantage! Il me fit tester le port 12345 et déclara un échec. Il semblait impérativement falloir me brancher directement sur la machine Buist pour télécharger Linux, avec un longissime transfert réseau vers ma machine de l'image ISO pour la graver sur DVD.
J'ai fini par redémarrer sous Mandrake/Mandriva Cooker 10.2/2005LE afin d'utiliser le client BitTorrent et le téléchargement put enfin avoir lieu!
Samedi, 16 avril 2005, j'ai pu terminer le téléchargement de Fedora Core 3 et l'installer. Ça semblait assez stable, mais il y avait plusieurs éléments à configurer. Après avoir ajusté les fontes par copie des fichiers de mon ancien Mandrake 10.1 avec légères adaptations, j'eus à faire un grand nombre de mises à jour. Cela prit plus de deux heures à télécharger et à installer et se termina le lendemain. Je tombai ensuite sur Fedora FAQ où j'obtins un fichier de configuration Yellowdog Updater Modified (YUM), ajoutant plusieurs miroirs au système de mise à jour de paquetages. Cela me permit d'incorporer le support MP3 à XMMS et d'obtenir Flash, sans recompiler quoi que ce soit. Linux-NTFS me donna comme sous Red Hat 9 le support NTFS lecture seule. Je n'ai jamais pu avoir mieux que ça sous Linux.
Je dus installer Adobe Acrobat manuellement pour avoir la version 7. Après l'installation, pour pouvoir visualiser des fichiers PDF sous Mozilla Firefox, j'ai exécuté le script /usr/local/Adobe/Acrobat7.0/Browser/install_browser_plugin afin d'installer le plug-in pour Mozilla. L'emplacement de Mozilla est /usr/lib/mozilla et un fichier du nom de nppdf.so se trouve ajouté par le script dans le sous-répertoire plugins.
Java s'installa sans misères, plugin Mozilla/Firefox inclus. Je dus créer un répertoire /usr/java et m'y placer afin d'y exécuter le script d'installation de JDK 1.5. Cela copia un paquet de fichier dans l'emplacement choisi et après, je dus faire en sorte que la variable JAVA_HOME soit créée et que $JAVA_HOME/bin soit ajoutée à la variable PATH. Je dus pour cela créer un fichier /etc/profile.d/java.sh contenant les instructions nécessaires. Bien entendu, pour le plug-in Mozilla, je dus créer le lien symbolique manuellement avec une commande du genre
ln -s $JAVA_HOME/jre/plugin/i386/ns7/libjavaplugin_oji.so /usr/lib/mozilla/plugins/libjavaplugin_oji.so
Après une période de désespoir, pensant que je ne pourrais ravoir le support NTFS par exemple, tout semblait se placer et bien aller. Je pus configurer Samba, l'imprimante, des éléments de GNOME, tout cela par le biais d'interfaces graphiques qui fonctionnèrent très bien. Les mises à jour Fedora ont fait passer Firefox à 1.0.2 et Thunderbird à 1.0.2 sans aucun mal! Pas besoin de supprimer les paquetages et d'installer les versions du site officiel de Mozilla.
Comme sous Mandrake 10.1, j'eus droit au bogue du pointeur noir que je pus corriger simplement en activant le curseur logiciel. Le système cessa de geler inopinément lorsque ce réglage fut effectué. Le MTRR se trouve bien configuré et l'accélération 2D/3D fonctionne. Le TV Tuner, lui, demeure désespérément inopérant.
En passant de 24 bits à 16 bits pour la profondeur des couleurs, je pus grandement améliorer la performance du 3D et possiblement aider à faire cesser les plantages qui continuèrent même après avoir résolu le bogue du pointeur noir. Pour ce faire, dans /etc/X11/xorg.conf, section Screen, j'ai changé DefaultDepth 24 pour DefaultDepth 16.
Je trouvai bien dommage que sous GNU Emacs, AucTeX ne soit pas installé. Cette extension fournit des macros facilitant l'édition de fichiers LaTeX et, dans le temps, était plutôt longue à installer et à configurer. Tel ne fut pas mon soulagement de trouver, sur le site du logiciel, un RPM pour Fedora Core 3!
Quoi de plus frustrant que de se rendre compte que les concepteurs de distributions Linux ne tiennent compte que des américains. Dimanche après-midi, 17 avril 2005, c'est bien cela que je crus découvrir sous Fedora Core 3. Ça recommença à mal aller lorsque je découvris qu'aucun accent n'apparaissait dans les noms de fichiers. Je trouvais cela déplorable que ce problème soit encore revenu et je pensai bien abandonner Linux si aucune solution ne s'offrait à moi. S'ils en sont encore là, il n'y a plus rien à espérer.
Le système utilise l'encodage courant qui est défini en même temps que la langue courante pour afficher les noms de fichiers. Par défaut, Fedora Core utilise UTF-8. Chaque caractère est formé d'une chaîne d'un ou plusieurs octets. UTF-8 est une version sur 8 bits du standard Unicode qui supporte à peu près toutes les langues courantes. Les partitions Ext2fs/Ext3fs (système de fichiers natif de Linux) ne contiennent aucune information quant à l'encodage. Les noms de fichiers ne sont que des chaînes de caractères que le système lit comme il veut. Sous Mandrake 10.1, j'utilisais l'encodage ISO Latin 1 pour mes noms de fichiers. Dans cet encodage, chaque caractère ne prend qu'un octet, mais seuls un sous-ensemble très restreint de UTF-8 peut être représenté. Ceci inclut les caractères accentués usuels en Français. Mes partitions Ext3fs de données étaient donc encodées en Latin 1. Il allait donc falloir tout reconvertir les noms ISO Latin 1 en UTF-8 si je voulais un système Unicode. Dans le cas de NTFS, le système de fichiers de Windows NT/2000/XP, il fallut que je change /etc/fstab pour que les choses fonctionnent. Je dus remplacer l'option nls=iso8859-15 inspirée de Mandrake par nls=utf8
Toutefois, lorsque je lus un fichier depuis un CD, je me rendis compte que les accents là aussi étaient tordus. Je passai au moins une demi-heure, sinon plus, à changer /etc/fstab afin de l'obliger à afficher les accents. Il n'y eut tout simplement rien à faire. Il semblait que le système ignorait l'option utf8 suggérée par Introduction to Unicode - Using Unicode in Linux par Michael Kosmulski. Bogue dans le noyau, pensai-je. Cela serait long avant que ça disparaisse, peut-être pas avant Fedora Core 4.
Au prix de désespoir et de frustration, je finis par comprendre pourquoi cela fonctionnait aussi mal: Rock Ridge! Mon CD testé contenait du Rock Ridge, l'extension Linux à ISO9660 (norme pour la structure de fichiers des CD) et, comme Ext2/Ext3, ce système ne contient pas d'informations sur l'encodage. Lorsque je montais le CD, Rock Ridge prenait la priorité sur Joliet (extension ISO9660 pour Windows qui utilise Unicode) et le système tentait de lire comme du Unicode ce qui était en fait du Latin 1! Un montage avec une option désactivant Rock Ridge me confirma cette hypothèse.
La seule solution, puisque je ne voulais pas regraver tous mes CD Rock Ridge, a été de désactiver le UTF-8 en modifiant /etc/sysconfig/i18n, comme je l'avais fait sous Red Hat 9. Dommage que Unicode soit arrivé trop tard, car avec UTF-8, il aurait évité tout ce casse-tête d'encodages multiples qui m'en a fait arracher, des cheveux.
Les souris IntelliMouse Optical et IntelliMouse Explorer comportent cinq boutons: un bouton gauche, un bouton centre qui est en plus une roulette de défilement, un bouton droit et deux boutons latéraux. Sous Mandrake, avec Firefox, les boutons latéraux fonctionnaient comme sous Windows, permettant de passer à la page précédente et à la page suivante. Sous Fedora Core 3, nada! Je décidai qu'il fallait que ces boutons fonctionnent, si bien qu'une bataille virtuelle dut avoir lieu!
En me fondant sur la documentation de Xorg, trouvée avec man et par Internet, je dus ainsi modifier /etc/X11/xorg.conf, section InputDevice consacrée à la souris (Driver "mouse"). Je conservai l'option Device déjà donnée, mais je remplaçai le protocole IMPS/2 par ExplorerPS/2, comme sous Mandrake. Ensuite, je dus indiquer que ma souris avait 7 boutons (gauche, milieu, droit, côté gauche, côté droit, roulette vers le haut, roulette vers le bas) et associer les deux derniers à la roulette.
La première tentative échoua, car j'oubliai de mettre la ligne Device, Xorg refusa de démarrer et la machine planta. Je dus la faire démarrer sur le niveau d'exécution 1 (en passant 1 au noyau depuis GRUB), modifier le fichier et taper init 5 pour repasser au niveau 5, faisant redémarrer Xorg. Je craignais de plus en plus que ces plantages trop fréquents ne soient dûs à une mauvaise gestion d'une de mes composantes matérielles, en particulier la carte graphique. Il se pouvait de plus en plus que je sois contraint de la changer ou de retourner à Mandrake 10.1 et garder cette distribution pour tout le temps. GhostScript ne fonctionnerait pas et il me faudrait le recompiler depuis le code source si je voulais produire des PDF avec la procédure latex/dvips/ps2pdf. Je préférerais ce travail que de m'acheter une nouvelle carte graphique, attendre six mois (ou davantage) qu'elle soit supportée sous Linux et endurer tout ce temps sous Windows!
Afin que les boutons de côté soient utilisables, il faut que les boutons de la roulette soient les derniers et en fait, ce sont les boutons 4 et 5 plutôt que 6 et 7. Il me fallut donc réordonner les boutons pour que cela finisse par fonctionner!
En résumé, voici mes paramètres pour la souris.
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
# Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
# Option "ZAxisMapping" "4 5"
# Option "Emulate3Buttons" "yes"
Option "Protocol" "ExplorerPS/2"
Option "Buttons" "7"
Option "ZAxisMapping" "6 7"
EndSection
Pour réordonner les boutons, je dus ajouter ceci à
/etc/X11/Xmodmap:
pointer = 1 2 3 6 7 4 5Et voilà: la souris fonctionna! Après un redémarrage du serveur X bien entendu.
De temps en temps, Fedora Core 3 plantait. Je pensai pendant longtemps que c'était dû à la carte graphique mal supportée par Xorg, mais une autre hypothèse est venue s'ajouter. Le noyau 2.6.11-1.14, le plus récent noyau Fedora Core 3 en mai 2005, ne supporte pas correctement les clés USB! Si la clé était insérée, puis retirée sans éteindre le système au préalable, soit Linux gelait à un moment aléatoire, soit il affichait un Kernel Panic lors de la fermeture. Ainsi, le caractère amovible de la clé USB n'était plus pris en charge; il fallait redémarrer pour la retirer!
Je trouvai cela plutôt frustrant, surtout que j'ai investi pas mal de temps et d'argent pour ajouter des ports USB avant sur ma machine. Quel que soit le port utilisé, le bogue se présentait. Il semblait falloir essayer diverses autres distributions Linux et choisir parmi autre chose que Mandriva ou Fedora Core, à moins de reculer et conserver une ancienne version, par exemple Mandrake 10.1 ou Red Hat 9. Cette possibilité ne me plaisait pas, car plus le temps avancerait, plus j'allais devoir recompiler des librairies et applications pour installer le moindre élément!
En cherchant Kernel Panic with Fedora Core 3 USB key sur Google, je tombai sur une bogue reporté sur le Bugzilla de Red Hat Le bogue 155472 constitue exactement ce problème particulier! Malheureusement, la seule solution en mai 2005 consistait à installer un noyau non officiel, le 2.6.11-1.25. Pour une raison incompréhensible, ce noyau n'était pas encore devenu une mise à jour officielle.
La seule solution était ainsi de le télécharger et de l'installer, mais cela me supprimerait le support NTFS. Le projet Linux-NTFS ne contient en effet aucun RPM pour ce nouveau noyau. Avant d'entreprendre la conversion de ma partition Windows XP en FAT32 pour régler le problème pour de bon, je tentai de consulter Linux-NTFS et découvris une façon de recompiler le module.
Pour réparer mon système, je dus télécharger plusieurs éléments. D'abord, sur la page 2.6.11-1.25, j'obtins kernel-2.6.11-1.25_FC3.i686.rpm et kernel-doc-2.6.11-1.25_FC3.noarch.rpm. Je pus alors installer le nouveau noyau:
rpm -ivh kernel-2.6.11-1.25_FC3.i686.rpm kernel-doc-2.6.11-1.25_FC3.noarch.rpmEnsuite, j'utilisai le lien Parent Directory et sélectionnai SRPMS.kernel. De là, je pus obtenir kernel-2.6.11-1.25_FC3.src.rpm, un élément nécessaire seulement pour reconstruire le module NTFS. Ensuite, sur Linux-NTFS, je cliquai sur NTFS RPMs puis Build Your Own. Il me fallut télécharger un script depuis ce site et suivre les instructions pour obtenir un RPM pour mon module NTFS.
Finalement, je redémarrai mon système pour activer ce nouveau noyau. Tout fonctionna ensuite à merveille et ma clé USB redevint utilisable sous Linux!
Mardi, 24 mai 2005, une nouvelle mise à jour pour le noyau est apparue. Je l'ai installée et elle n'a pas fait ressurgir le bogue USB. Ainsi, à présent, le noyau le plus récent de Fedora Core 3 ne souffre plus de ce bogue des plus déplaisants.
Ce bogue, apparu sous Mandrake 10.0, a refait surface sous Fedora Core 3. Chaque recherche sur Google était devenue désespérément lente, mais je pensais que la cause venait des sites contactés. Mardi soir, 7 juin 2005, j'ai eu de la misère avec un transfert FTP, j'ai essayé de faire des recherches pour trouver des informations et le réseau répondait particulièrement mal. À bout de patience, j'ai fini par redémarrer sous Windows, mon transfert FTP s'est terminé en un éclair et les recherches sur Google étaient beaucoup plus rapides.
Afin de tenter de résoudre ce problème qui semble résulter d'une forme d'incompatibilité entre le support IPv6 du noyau 2.6 et les DNS de Vidéotron, j'ai ajouté la ligne suivante à /etc/modprobe.conf.
alias net-pf-10 off
Après un redémarrage, cela semble avoir amélioré la situation.
Bien que je n'aie découvert cette astuce qu'après mon passage à Fedora Core 4, elle fonctionne aussi sous Fedora Core 3 et de façon identique. Le pilote EMU10k1 pour ALSA, supportant les cartes Creative Sound Blaster Live!, supporte non seulement le son numérique mais aussi la musique MIDI. Toutefois, par défaut, si le pilote reçoit des données MIDI, il ne joue rien! C'est pourquoi aplaymidi ne joue rien lorsqu'il est appelé.
Pour résoudre ce problème, il suffit de charger une banque d'instruments (SoundFont) sur la puce EMU10k1 de la carte son. Une telle banque peut être trouvée sur le CD accompagnant la carte son et chargée par la commande asfxload. Pour que le MIDI fonctionne en permanence, il suffit d'ajouter la ligne
asfxload /usr/local/share/8MBGMSFX.SF2
dans le fichier /etc/rc.d/rc.local après avoir copié le fichier 8MBGMSFX.SF2 à l'endroit approprié. Bien entendu, tout autre fichier SoundFont pourrait être employé.
Plusieurs claviers, dont le mien, sont dotés de touches spéciales qui sont par défaut inutilisables sous Linux. Remédier à cela a exigé pour moi plusieurs étapes. D'abord, j'ai remarqué que chaque fois que j'appuyais sur une de ces touches, une entrée était inscrite dans le journal système. En regardant ces entrées, j'ai pu obtenir les scan codes de ces touches. J'ai ensuite utilisé setkeycodes pour associer des key codes à ces scan codes. Pour ce faire, dans le cas de mon clavier Compaq Easy Access, j'ai ajouté la ligne suivante dans /etc/rc.d/rc.local:
setkeycodes e023 129 e01f 130 e01a 131 e01e 132 e013 133 e014 134 e015 135 e01b 136
Après cet ajustement, appuyer sur mes touches spéciales faisait réagir xev. Cela m'a permis de relier ces key codes à des événements Xorg. Pour ce faire, j'ai ajouté les lignes suivantes à /etc/X11/Xmodmap:
keycode 133 = XF86WWW keycode 134 = XF86HomePage keycode 135 = XF86Search keycode 140 = XF86Mail keycode 248 = XF86Community keycode 191 = XF86Market keycode 192 = XF86Meeting keycode 122 = XF86News
Il me fallut tâtonner avec xev pour trouver les bons codes. Finalement, j'ai pu utiliser ces touches normalement sous Xorg et leur associer des fonctions grâce à GNOME.
Fedora Core 3 m'a amené des problèmes, pas autant que Mandriva 2005 LE mais beaucoup malgré tout. J'eus assez de difficultés que je songeais ne plus mettre Linux à jour jusqu'à la mort de ma machine! J'allais conserver Fedora Core 3 le plus longtemps possible et endurer les possibles bogues. Lorsque je changerais d'ordinateur, je prévoyais passer au AMD64, si bien qu'il me faudra une nouvelle version Linux, 64 bits. Toutefois, cette mise à jour matérielle n'était pas prévue avant un bon bout de temps, non pas seulement à cause des coûts mais à cause des problèmes divers de compatibilité logicielle qu'elle entraînerait.
La prochaine mise à jour Linux, s'il y en a une, ne se ferait pas de la même façon. Je prévoyais réaménager les partitions de mon disque dur au moment voulu afin de dispoer d'une nouvelle zone dans laquelle je pourrais tester le nouveau système. Les tests pourraient alors durer des semaines, voire des mois, sans perturber mon travail quotidien sous Linux. De cette façon, j'espérais diminuer le stress et la frustration engendrés par une mise à jour Linux contemporaine.
Le nouvel arrangement comporterait une partition primaire pour Windows, une seconde pour mon Linux de travail et une troisième pour mon Linux de test. La configuration de la partition étendue resterait identique, mais la taille des partitions logiques diminuerait pour percer le trou de 20Go nécessaire à la zone de test. Avec mon disque dur de 120Go, un tel gaspillage d'espace pourrait être toléré. Ce qui n'était pas possible avec mon ancien 30Go.