| Le royaume de Eric Buist >> Informatique >> Configuration informatique | ||
| Me contacter | Plan du site | |
| << Le Salvator, successeur du Faucon de Fer | Passage à Fedora Core 5 | Le Nightmare, second du Salvator >> |
Était-il nécessaire de passer de Fedora Core 4 à Fedora Core 5? Pas vraiment. Est-ce que ce fut une bonne idée? Pas vraiment. Mais malgré tout, la curiosité me poussa à faire le passage et j'ai dû en payer le prix, autant en perte de temps qu'en désespoir. Cette page raconte mon aventure et, espérons-le, ne dissuadera pas trop de gens d'essayer Linux. Mais bon, autant que la vérité éclate au grand jour et que les gens qui ont le pouvoir d'améliorer les choses en usent enfin! Le plus grand problème que j'ai rencontré a été celui du pilote NVIDIA qui, pour la première fois depuis que j'ai commencé à l'utiliser en septembre 2005, a refusé de fonctionner correctement.
Première erreur: tenter de télécharger Fedora Core 5 x86_64 le jour même de sa sortie, lundi le 20 mars 2006! Bien que j'aie utilisé BitTorrent pour parvenir à mes fins, l'opération s'avéra longue, car il devait y avoir un grand nombre de personnes en train de tenter le téléchargement et peu l'ayant terminé et offrant en partage l'image ISO DVD complète.
Heureusement, malgré la longueur du téléchargement, je pouvais continuer à travailler sur mon ordinateur. Ainsi, après avoir démarré BitTorrent, j'ai pu continuer à travailler sur mon doctorat. J'ai même pu, le soir venu, stopper le téléchargement et le reprendre le lendemain, sans devoir le recommencer. Mardi soir, 21 mars 2006, je disposais donc de l'image ISO DVD de Fedora Core 5 et j'en avais partagé 65% à d'autres utilisateurs de BitTorrent! Afin de ne pas épuiser ma limite de transfert en amont imposée par Vidéotron, je stoppai BitTorrent et m'empressai de graver mon image ISO sur un DVD+R.
Contrairement à ma dernière installation de Fedora Core 4 sur le Salvator, tout se passa très bien ce vendredi 24 mars 2006. Le programme d'installation démarra sans le moindre plantage et afficha son écran de bienvenue. Je faillis commettre la gaffe de laisser le programme reformater entièrement le disque dur. Sans le message de confirmation, je n'aurais pas pu éviter l'apocalypse! Si j'avais cliqué sur Oui, j'aurais eu à réinstaller Windows XP, recharger toutes mes données depuis des CD et des DVD et peut-être même redimensionner ma partition Linux avant de pouvoir faire tout ça. Après avoir évité le pire, j'ai indiqué au programme d'installer Fedora Core 5 dans ma partition vierge de façon à ne pas déranger Windows XP et Fedora Core 4. De cette façon, en cas de problème, il serait possible sans trop de difficultés de revenir à Fedora Core 4.
L'interface graphique de l'installeur était améliorée par rapport à Fedora Core 4. On est loin de l'interface Aqua d'Apple pour Mac OS X, mais c'est quand même bien. La carte réseau Marvell fut détectée, ce qui me ravit: un pilote de moins à installer manuellement et une configuration plus facile! La carte son aussi fut trouvée, donc pas de régression à ce niveau. Mieux encore, la configuration du pare-feu m'offrait l'option de déverrouiller les ports pour Samba, ce qui me permit d'activer le pare-feu sans travailler d'arrache-pied à le configurer manuellement pour Samba. Sous Fedora Core 4, j'avais désactivé le pare-feu, car je trouvais trop compliqué de trouver la syntaxe exacte des règles à ajouter pour Samba et mon routeur sert déjà de pare-feu élémentaire. Premier aspect négatif: impossible de dire à l'installeur de copier tous les paquetages sur le disque dur. Comme avec Mandrake, il fallait sélectionner les paquetages un par un. Les paquetages sélectionnés, l'installation se passa sans difficulté après quoi je démarrai sous mon nouveau jouet.
Ma première surprise fut de constater que le noyau 2.6.15 installé n'était pas SMP. Une petite recherche avec Yum m'indiqua qu'il n'y avait aucun noyau SMP, ce qui me déçut puisque ce noyau était essentiel pour tirer parti de mon Pentium D. Par contre, cat /proc/cpuinfo affichait bien deux proceseurs. De même, top en affichait deux si j'appuyais sur 1 dans le programme pour montrer les processeurs séparément. Je constatai plus tard, avec la commande dmesg, que le noyau était bien SMP. Pour x86_64, seul le noyau SMP est disponible sous Fedora Core 5. Dans le cas d'un système monoprocesseur, c'est-à-dire un AMD Athlon 64 pas x2, le noyau SMP ne gère qu'un processeur. Les Pentium 4 d'Intel peuvent faire surgir deux processeurs en raison de la technologie HyperThreading.
Je constatai bien assez vite deux manques: j'étais encore coincé en 800x600 et mon synthoniseur TV ne fonctionnait pas. Je commençai par essayer d'installer le pilote de NVIDIA comme j'avais fait avec Fedora Core 4 et constatai que cette fois, l'installation échouait! Le programme d'installation affichait une erreur, ne pouvant pas compiler le module de noyau de NVIDIA! Il n'y avait donc aucun moyen de faire fonctionner la carte graphique en 1280x1024, ce qui était loin d'être idéal avec mon LCD. Pour empirer les choses, il fallut que le pilote IVTV 0.4.1 pour mon synthoniseur TV refuse lui aussi de compiler lui aussi.
À bout de patience, je décidai de prendre les grands moyens: télécharger le noyau 2.6.15 sur Kernel.org et le recompiler! J'avais lu que Fedora Core 5 intégrait un noyau 2.6.15 avec des fonctionnalités du noyau 2.6.16 et j'avais eu de très mauvaises expériences avec ce genre de noyaux hybrides sous Red Hat 9: jamais le pilote ATI de GATOS n'avait compilé sous Red Hat 9 si bien que je n'attendrais pas des mois en vain. Retour au noyau 2.6.15 classique et ça finirait là!
Pendant la longue compilation du noyau, je poursuivis mes recherches pour trouver une meilleure solution. Je n'aimais pas l'idée de recompiler le noyau, car je n'étais pas certain que le noyau fonctionnerait; en particulier, j'avais de grandes craintes pour le Serial ATA. En effet, je n'avais vu aucune option relative à libATA qu'il fallait pourtant activer pour le support des disques Serial ATA.
Je finis par télécharger IVTV 0.6.1 et le compilai: succès! Au moins, quelque chose pouvait fonctionner et ce, sans recompiler le noyau. Cela me soulagea un peu et je me dis que j'en resterais là si je pouvais au moins obtenir un affichage en 1280x1024 avec le pilote NV de X.Org. Ce pilote NV est à code source ouvert et permet l'utilisation de l'accélération graphique avec la plupart des cartes NVIDIA. La 3D ne fonctionnerait pas avec NV, mais au moins, le reste oui. Il faut s'attendre à ce qu'un jour, la 3D cesse de fonctionner sous X.Org, car les fabricants de cartes graphiques veulent garder leurs spécifications pour eux et les API de X.Org et surtout du noyau ne cessent de changer d'une version à l'autre si bien que l'écriture de pilotes est trop coûteuse et complexe.
Je pensai d'abord que ça pouvait être le pilote NV qui causait des difficultés, m'empêchant d'accéder à une résolution supérieure à 800x600, et le remplaçai par le pilote VESA. Pour ce faire, dans /etc/X11/xorg.conf, je substituai nv pour vesa dans la section Device correspondant à ma carte graphique. Lorsque je redémarrai X.Org, je constatai avec désespoir que rien n'avait changé. J'étais toujours coincé en résolution 800x600.
J'examinai donc le fichier /var/log/X.Org.0.log pour y trouver des messages d'erreur indiquant vaguement que le pilote graphique rejetait des modes non supportés par l'écran. J'en vins à supposer que l'affichage DVI causait désormais des difficultés, mais je ne pouvais me résoudre à rebrancher mon écran en mode VGA. En fouillant davantage dans le fichier, je découvris que des lignes dans le fichier de configuration verrouillaient la fréquence acceptée des modes graphiques et qu'en commentant ces lignes, je pourrais activer l'auto-détection via DDC. C'est ainsi que, dans /etc/X11/xorg.conf, je commentai les lignes HorizSync et VertRefresh dans la section Monitor. Bien entendu, dans la section Screen, j'avais déjà ajouté les résolutions supérieures à 800x600. Un redémarrage de X.Org plus tard, j'obtenais un écran de bienvenue en mode 1280x1024!
Mais cette astuce s'avéra bonne uniquement avec le pilote VESA, ce qui était très limitatif. En effet, ce pilote ne propose aucune accélération graphique, pas même 2D. Les performances de mon système seraient donc fortement réduites si j'employais ce pilote et il se pouvait même que DPMS, permettant l'extinction automatique de l'écran après un temps fixé, ne fonctionne pas. C'était inacceptable si bien que je poussai plus loin.
Pour ce faire, je repris les paramètres obtenus en 2003 avec ReadEDID et les plaçai dans la section Monitor de mon fichier de configuration X.Org. J'ajoutai ainsi les lignes suivantes dans la section Monitor.
HorizSync 30.0 - 82.0
VertRefresh 50.0 - 75.0
Je changeai le pilote VESA pour NV, redémarrai X.Org et constatai avec joie que j'obtenais un affichage en 1280x1024, avec pilote NVIDIA open source! J'aurais donc au moins une accélération 2D de base.
Samedi, 25 mars 2006, je constatai que GMplayer, installé depuis LIVNA, ne fonctionnait pas bien du tout. Lorsque j'essayai de lui faire ouvrir /dev/video pour tester mon synthoniseur TV, le logiciel afficha un message d'erreur. Ensuite, une seconde tentative laissa une copie fantôme du logiciel qui ne voulait plus se fermer; je dus le tuer avec killall -9 gmplayer. L'erreur ne se reproduisit plus si bien qu'elle est probablement dûe à une erreur typographique dans le nom du fichier à lire.
Autre problème: Adobe Reader 7 refusait de démarrer, fermant spontanément à chaque tentative sans afficher quoi que ce soit. Aucun message d'erreur, aucune fenêtre, rien. Il ne semblait y avoir aucune solution pour faire fonctionner cela, mais ce n'était pas un gros drame puisque je n'utilise pas très souvent Adobe Reader. Je me sers plutôt de XPDF et KPDF pour lire des fichiers PDF.
Mais la version 32 bits de Firefox 1.5 refusa aussi de démarrer, cherchant libstdc++.so.5 qui était disparu, remplacé par libstdc++.so.6. Sans cette version de Firefox, je n'aurais pas les plug-ins pour Java et Flash. Pour faire démarrer Firefox, je dus installer, via Yum, le paquetage compat-libstdc++-33. Cela permit de faire démarrer Firefox, mais il prend plus de temps à se charger que sous Fedora Core 4.
Quant à Thunderbird, il n'était même pas installé; il fallait utiliser des mastodontes comme Evolution, à présent! Heureusement, je pus l'installer par le biais de Yum et il fonctionna sans rechigner. Je peux utiliser la version 64 bits, car, contrairement à Firefox, je n'ai pas besoin de plug-ins Java ou Flash.
J'espérais que l'installation de la bibliothèque C++ 5 ferait fonctionner Adobe Reader, mais il n'en fut rien. Au lieu de stopper sans rien afficher, le logiciel se contentait dès lors de figer et d'entrer dans une boucle infinie, encore sans afficher quoi que ce soit.
Après avoir constaté que même GLXGears, un petit programme tout simple, refusait de démarrer, je voulus de nouveau faire fonctionner le pilote NVIDIA. Si, au moins, GLXGears avait fonctionné lentement, j'aurais pu tolérer que le pilote ne fonctionne pas. Je m'attendais à cela quand j'ai acheté ma carte graphique; je me disais que je devrais choisir, un jour, entre garder une ancienne version de Linux ou me passer des fonctions du pilote. Ce jour était venu plus tôt que prévu, voilà tout.
Malheureusement, personne ne semblait éprouver mon problème. Il ne semblait y avoir aucun moyen de faire fonctionner le pilote NVIDIA sous Fedora Core 5. On aurait même dit que j'étais le seul à avoir essayé! Le désespoir augmenta lorsque je vis, sur FedoraForum, un message indiquant que quelqu'un avait réussi à faire fonctionner sa carte ATI sous Fedora Core 5. Eh oui, à présent, c'était ATI qui fonctionnait et non plus NVIDIA! La perspective de devoir jouer au yoyo avec des cartes graphiques, passant de temps en temps de NVIDIA à ATI, de ATI à NVIDIA, d'ATI ou de NVIDIA vers une autre marque, etc., s'imposa à moi et ne me réjouissait pas du tout! Autant, dans ce cas, me débarrasser de Linux qui était devenu beaucoup trop contraignant.
Je finis par trouver la première pièce du casse-tête: une patch sur NVNews qui semblait pouvoir réparer le pilote et le rendre fonctionnel. Je la téléchargeai et l'appliquai avec les commandes suivantes:
sh NVIDIA-Linux-x86_64-1.0-8178-pkg2.run --extract-only cd NVIDIA-Linux-x86_64-1.0-8178-pkg2 patch -p0 < NVIDIA_kernel-1.0-8178-U012206.diff.txt
Le fichier NVIDIA-Linux-x86_64-1.0-8178-pkg2.run est le pilote NVIDIA original tandis que le fichier NVIDIA_kernel-1.0-8178-U012206.diff.txt est la patch obtenue sur NVNews. La patch modifia quelques fichiers dans le code source du module NVIDIA, ce qui me donnait un certain espoir de voir le module se compiler. J'utilisai donc ./nvidia-installer pour démarrer l'installation qui, cette fois, alla un petit peu plus loin mais pas vraiment. En effet, le module se compila, mais il refusa de se charger! Cela montrait qu'il y avait bel et bien un bogue avec le noyau 2.6.15 de Fedora.
Je tentai donc d'utiliser le noyau 2.6.15.6 recompilé la veille. Pour mettre en oeuvre ce noyau, il faut d'abord le décompresser dans /usr/src/kernels et y appliquer la patch Marvell pour la carte réseau. Ensuite, avec make menuconfig, j'ai réglé les diverses options. En fait, je n'ai pas changé grand-chose, à part activer le module NTFS. make a déclenché la compilation et make modules_install a installé les modules. Je dus ensuite copier le fichier bzImage dans /boot/vmlinuz-2.6.15.6 et créer une image INITRD avec /sbin/mkinitrd et la copier dans /boot/initrd-2.6.15.6.img. Cette image est nécessaire pour permettre au noyau de charger les modules pour le SCSI et le Serial ATA. Je dus ensuite modifier /etc/grub.conf pour établir les liens avec le nouveau noyau après quoi je redémarrai. Cela fonctionna! En fait, je dus me reprendre à deux fois, une fois pour le pilote Marvell Yukon et une seconde pour le NTFS, mais j'ai ici résumé la procédure globale à employer pour que cela fonctionne du premier coup.
L'installation du pilote IVTV réussit, mais celle du pilote NVIDIA échoua lamentablement, encore une fois. J'essayai avec la patch et cette fois, je réussis: le module compilait, se chargeait et l'installation du pilote se terminait! Par contre, X.Org refusait de démarrer avec le pilote NVIDIA! Je dus remettre le pilote NV, désinstaller le pilote NVIDIA et je retournai sous le noyau 2.6.15 de Fedora Core.
Après d'autres recherches sur Internet et un message sur FedoraForum, j'essayai le noyau 2.6.16-1.2074_FC5 encore en développement. En fait, tout noyau 2.6.16 maintenant disponible par Yum pourrait fonctionner. Par contre, ce samedi, le noyau n'était pas disponible sous Yum et j'obtins donc des RPMs. J'eus le malheur d'utiliser rpm -Uvh pour installer le noyau, ce qui écrasa mon noyau 2.6.15 fonctionnel! À contre-coeur, je redémarrai sous le nouveau noyau, tentai l'installation et cela échoua. Avec la patch, cela réussit, mais X.Org ne voulait pas démarrer!
Je disposais donc de deux des trois pièces du casse-tête: la patch pour modifier le module de noyau et un noyau sain. Par contre, cela ne suffisait pas, car X.Org 7.0 se révélait incompatible avec le pilote de NVIDIA. De longs mois d'attente seraient nécessaires pour ravoir un nouveau pilote et ces mois, je les passerais sous Fedora Core 4, me dis-je, choqué. Je ne voyais que peu de différences entre X.Org 6.8 et X.Org 7 si bien qu'il n'y avait aucune raison pour que le pilote cesse de fonctionner. De plus, pour rétablir mon système, j'allais devoir désinstaller le pilote NVIDIA, reconfigurer X.Org pour utiliser NV et compiler moi-même le module NTFS.
L'idée d'essayer d'installer X.Org 6.8 ou XFree86 4.4 ou 4.5 me passa par la tête, mais j'y renonçai, car je ne pouvais pas le faire de façon propre. Si j'utilisais RPM pour supprimer X.Org, il voudrait supprimer tout ce qui dépend de X.Org, incluant GNOME, KDE, etc. La meilleure solution serait donc d'installer X.Org 6.8 ou XFree86 par-dessus les fichiers actuels de X.Org 7.0, ce qui créerait un joli méli-mêlo qui ne pourrait se réparer que par la réinstallation de Fedora Core 5! Autant, dans ce cas, redémarrer sous Fedora Core 4 de toute façon déjà installé et prêt à l'emploi que de perdre mon temps avec cette nouvelle version qui ne fonctionnerait pour moi que d'ici quelques mois. Encore une fois, j'étais obligé de revenir à la version précédente, mais contrairement à mon expérience avec Mandriva 2005 LE, j'avais encore cette version sur mon disque!
C'est ainsi que je redémarrai sous Fedora Core 4, laissant Fedora Core 5 en chantier sans prendre la peine de le rendre de nouveau fonctionnel. Je réinstallai même GRUB de Fedora Core 4, comme si Fedora Core 5 n'avait jamais été installé sur la machine. Voilà, fini le cauchemar! Mais cela me choquait et j'avais de plus en plus de me débarrasser de Linux complètement.
Mais en soirée, je découvris la troisième pièce du casse-tête: X.Org 7.0 plaçait les fichiers à un autre endroit que X.Org 6.8 et le pilote NVIDIA ne connaissait pas le nouvel emplacement. Je découvris cela par tâtonnement, en examinant les fichiers log de X.Org et la structure des répertoires. Je me dis que peut-être un déplacement des fichiers pourrait résoudre le problème, mais je savais qu'il se pouvait fort bien que X.Org refuse de démarrer par incompatibilité du format binaire du pilote. En résumé, tous les fichiers dans /usr/X11R6/lib64 doivent être déplacés dans /usr/lib64/xorg. Les commandes utilisées pour la réparation sont les suivantes. Elles pourraient être adaptées pour un Linux 32 bits en remplaçant lib64 par lib.
cd /usr/X11R6/lib64 cp -a lib* ../../lib64/xorg cp -a modules/drivers/nvidia* ../../lib64/xorg/modules/drivers cd ../../lib64/xorg/modules/extensions mv libglx.so libglx.so.backup cd - cp -a modules/extensions/libglx* ../../lib64/xorg/modules/extensions
La suppression du pilote pourrait se faire par les commandes suivantes.
cd /usr/lib64/xorg rm libXvMCNVIDIA* rm modules/extensions/libglx.so rm modules/extensions/libglx.so.1.0.8178 mv modules/extensions/libglx.so.backup modules/extensions/libglx.so rm modules/drivers/nvidia_drv.so
Après avoir fait les ajustements depuis Fedora Core 4, j'ai configuré GRUB pour me ménager une porte vers Fedora Core 5 avant de redémarrer la machine. Le déplacement des fichiers était la bonne solution, car enfin, X.Org démarra! GLXGears fonctionna et même, pour une raison mystérieuse, Adobe Reader se remit à fonctionner! J'ai donc réinstallé GRUB de Fedora Core 5 tout en gardant une porte de sortie vers Fedora Core 4, au cas où.
Inverser le déplacement ne sera nécessaire que lorsque NVIDIA sortira un nouveau pilote adapté à X.Org 7.0. En attendant, il est possible de le faire une seule fois puis d'utiliser la version patchée du pilote pour réinstaller ce dernier lors des mises à jour du noyau.
J'installai ensuite xscreensaver-gl-extras pour avoir les écrans de veille OpenGL.
Vendredi, 14 avril 2006, j'ai constaté avec agacement que ma session GNOME se fermait toute seule après un certain temps d'inactivité. J'ai fini par supposer que l'écran de veille faisait planter X.Org et c'était bel et bien cela: chaque fois que je démarrais GLXGears, X.Org plantait. Ainsi, tout écran de veille OpenGL faisait planter le système. La cause ne pouvait être que le pilote NVIDIA dont un fichier avait été perturbé par une mise à jour.
Je dus réinstaller le pilote pour réparer le mal, mais je vérifiai sur le site de NVIDIA et constatai qu'une nouvelle version, la 8756, était disponible. Je la testai et constatai que le module de noyau compilait dès lors sans patch. Par contre, les fichiers sont toujours copiés au mauvais endroit. Il semble donc que la modification a été faite par Fedora Core et non X.Org si bien que chaque installation du pilote NVIDIA sur Fedora Core 5 posera ces difficultés!
Après toutes ces mauvaises expériences, j'en suis venu à la conclusion que j'étais sur la mauvaise voie quant à la façon d'installer le pilote de NVIDIA sous Fedora Core 5. Utiliser l'installeur générique de NVIDIA n'est pas une très bonne solution, car il court-circuite le système RPM de la distribution, provoquant divers problèmes:
Ces mêmes difficultés s'appliquent avec le pilote closed source d'ATI. L'article Attention: Proprietary video driver users (ATI, Nvidia, etc.) explique plus en détails les problèmes causés par l'utilisation de l'installeur générique provenant du fabricant.
Pour réparer mon système, j'ai dû désinstaller le pilote de NVIDIA, supprimer les fichiers que j'avais déplacés et réinstaller les paquetages xorg-x11-server, xorg-x11-utils et mesa-libGLU.
La meilleure solution est d'utiliser Yum pour installer le pilote de NVIDIA adapté à Fedora Core 5. Le seul désavantage, largement compensé par la simplification du processus, est qu'en cas de mise à jour du noyau, il faudra peut-être attendre quelques jours avant que la mise à jour du module soit disponible.
Tout d'abord, il faut configurer Yum pour qu'il accède au dépôt externe Livna, ce qui était déjà fait dans mon cas. La meilleure façon d'installer Livna est d'aller sur la page Web de Livna, cliquer sur Configuration et suivre les instructions. Cela installera un paquetage ajoutant les fichiers nécessaires dans /etc/yum.repos.d ainsi que les clés GPG pour vérifier les signatures des paquetages téléchargés.
Ensuite, il suffit d'exécuter yum update; cela installera si nécessaire une version 2.6.16 du noyau. Ensuite, il suffit d'exécuter yum install kmod-nvidia xorg-x11-drv-nvidia xorg-x11-drv-nvidia-devel xorg-x11-drv-nvidia-libs-32bit pour installer le pilote NVIDIA. Si un nouveau noyau a été installé, un redémarrage du système sera nécessaire avant de pouvoir utiliser le pilote.
Il existe par contre une difficulté qui rendra souvent cette procédure inopérante. Lors d'une nouvelle installation de Linux, yum update installera la plus récente version du noyau. Malheureusement, il arrive que le module de NVIDIA ne soit pas disponible sur Livna pour ce nouveau noyau. Pour pouvoir utiliser le pilote sans devoir attendre, outre employer la version générique de NVIDIA, il suffit de taper yum list kernel\* pour afficher la liste des noyaux disponibles par l'intermédiaire de Yum et yum list kmod-nvidia\* pour obtenir la liste des modules NVIDIA disponibles. Ensuite, il suffit d'installer l'ancien noyau le plus récent pour lequel le module existe en donnant son nom complètement qualifié, par exemple yum install kernel-2.6.16-1.2080_FC5. Il faudra bien entendu redémarrer l'ordinateur avec ce noyau et non pas le plus récent. Il est à espérer que le module de NVIDIA sera disponible dans les jours qui suivront si bien qu'il est bon de vérifier régulièrement.
Samedi, 25 mars 2006, j'essayai aussi de faire fonctionner les boutons latéraux de ma souris et cela ne fonctionnait pas! Après avoir appliqué la même procédure qu'avec Fedora Core 3 et 4, même la roulette de défilement ne fonctionnait plus. Cela me boguait que cette fonction soit disparue! Je pus heureusement trouver la façon de reconfigurer les choses. Dans /etc/X11/xorg.conf, il faut toujours la section InputDevice suivante.
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/input/mice"
Option "Protocol" "ExplorerPS/2"
Option "Buttons" "7"
Option "ZAxisMapping" "6 7"
EndSection
Par contre, XModMap change un peu. Il faut définir 11 boutons pour que les choses fonctionnent et j'ai dû tâtonner pour trouver la bonne combinaison pour mon IntelliMouse Optical de Microsoft. La solution consiste à ajouter, dans /etc/X11/Xmodmap, la ligne
pointer = 1 2 3 8 9 4 5 6 7 10 11
Le bugX ne s'est pas beaucoup manifesté sous Fedora Core 5. Le plus gros problème vécu a été celui du pointeur de souris qui demeurait obstinément petit, même si je créais le fichier .Xresources. Pour remédier au problème, j'ai dû fouiller dans les options de GNOME et j'ai constaté non sans agacement que GNOME 2.14 prenait en charge le pointeur de souris. Heureusement, parmi les pointeurs proposés, j'en trouvai un avec une taille correcte.
Comme d'habitude, je dus ajuster la taille des caractères sous GNOME, KDE, Firefox, Thunderbird, Emacs et je dus créer des fichier .gtkrc pour les programmes GTK 1. Tous ces efforts portèrent fruit et les ajustements furent rapides en raison de la possibilité de recopier des informations de ma partition Fedora Core 4.
Je constatai avec agacement que smbmount avait disparu. Il faut à présent utiliser CIFS et ce dernier n'effectue pas la résolution des noms NetBIOS. Il me fallut donc modifier tous mes scripts de sauvegarde automatique pour mettre des adresses IP statiques à la place. C'était plus simple que de chercher comment configurer un DNS!
Pour pouvoir monter les points d'accès réseau sans être super-utilisateur, il faut mettre /sbin/mount.cifs et /sbin/umount.cifs SUID et utiliser ces commandes pour faire le montage et le démontage. De même, les points de montage doivent être des répertoires accessibles en écriture par l'usager. Par exemple, voici une commande qui se trouve dans un script d'initialisation pour faire une sauvegarde de fichiers sur la machine familiale.
/sbin/mount.cifs //192.168.1.5/data ~/fdfdata iocharset=utf8,username=...,password=...
Autre problème: impossible de démonter CD, DVD et clé USB depuis la ligne de commande sans devenir super-utilisateur. Pour résoudre le problème, outre utiliser le Bureau de GNOME, j'ai trouvé la commande gnome-mount. Par exemple, gnome-mount -u -d /dev/cdrom permet de démonter un CD dans le graveur.
Je dus encore une fois recompiler moi-même le module pour le NTFS, car il n'était pas disponible pour le noyau 2.6.16-1.2074_FC5. Heureusement, avec le noyau 2.6.16-1.2080_FC5 obtenu sur Yum, je pus avoir le module NTFS.
Vendredi, 31 mars 2006, j'ai constaté que Gnome-ScreenSaver n'affichait plus que quatre ou cinq écrans de veille qui n'était pas très beaux. Ce bogue semble être apparu depuis que Yum a mis à jour XScreenSaver à la version 4.24-2. Heureusement, suite à quelques recherches sur Internet, je trouvai une parade. Je dus, pour récupérer les écrans de veille, utiliser les deux commandes suivantes, la deuxième en root. C'est une FAQ de GNOME qui me mit sur la piste de la solution et un peu de tâtonnement fit le reste.
/usr/libexec/gnome-screensaver/migrate-xscreensaver-config.sh /usr/share/xscreensaver/config/*.xml mv *.desktop /usr/share/gnome-screensaver/themes
Malheureusement, vendredi, 7 avril 2006, je constatai que Gnome-ScreenSaver supprimait les fichier .desktop concernant XScreenSaver de façon périodique. La suppression a lieu au moins à chaque fois que le paquetage Gnome-ScreenSaver est mis à jour par Yum. Par contre, je ne suis pas certain que la première suppression des fichiers coïncide avec une mise à jour. La seule solution semblait consister à mettre l'appel à gnome-screensaver/migrate-xscreensaver-config.sh dans un script d'initialisation! Je n'en fis rien; j'optai plutôt pour désactiver l'écran de veille. Je considérai cela comme un bogue insoluble dont les deux seules solutions étaient d'attendre une éventuelle mise à jour ou de revenir à Fedora Core 4. Puisque cela n'en valait pas la peine pour des écrans de veille, tout désactiver était la meilleure chose à faire. Quelques minutes plus tard, je désinstallai Gnome-ScreenSaver qui ne servait plus à rien de toute façon. J'essayai ensuite d'accéder aux préférences de l'économiseur d'écran de GNOME pour voir le message d'erreur qu'il afficherait et constatai avec étonnement que XScreenSaver avait pris le relais! La suppression de Gnome-ScreenSaver a redonné sa place à XScreenSaver si bien que les écrans de veille fonctionnent dès lors correctement, comme sous Fedora Core 4.
La configuration de Fedora Core 5 nécessita de nombreuses passes-passes et fut plus difficile que celle de Fedora Core 4 en raison du pilote NVIDIA. Le problème n'est par contre pas dû à NVIDIA qui a fait son possible pour produire un pilote de très bonne qualité mais aux développeurs de Fedora Core qui ont changé des fichiers d'endroit. L'environnement logiciel et les interfaces d'accès ne cessant de changer sous Linux, il est très difficile, voire impossible, de produire un pilote stable. Cela m'a mené à penser que dans le futur, NVIDIA finira peut-être par cesser le développement du pilote en attendant des jours ou un système d'exploitation meilleurs. Cela serait très dommage, car il n'existerait alors plus de carte graphique moderne avec accélération 3D fonctionnant parfaitement sous Linux. La seule façon de bénéficier de l'accélération 3D serait alors d'utiliser une ancienne version de Linux ou une ancienne carte graphique. Une autre solution, plus qu'acceptable pour mes besoins du moins, serait simplement de recourrir à l'accélération 3D logicielle. Comme j'ai écrit plus haut, si GLXGears avait daigné démarrer, je ne me serais pas autant cassé la tête pour faire fonctionner le pilote closed source de NVIDIA. J'aurais gardé le pilote NV qui semblait faire un bon travail.
Fedora Core 5 a par contre apporté des améliorations intéressantes. D'abord, GNOME est plus rapide à démarrer. Sous FC3 et FC4, il se bloquait lorsque je démarrais une console tandis que ce problème a disparu. De même, Emacs a cessé de lambiner au démarrage comme il le faisait depuis que j'ai activé UTF-8. L'interface graphique a été améliorée et Eclipse fonctionne parfaitement! Jamais l'environnement de développement ne m'a planté à la figure comme il le faisait sous Fedora Core 4 x86_64, à l'Université de Montréal. Je n'ai eu qu'un problème avec le déboguage d'une application multithreads. L'accès à Internet, l'impression, la gravure de CD et de DVD, l'accès à la clé USB, tout cela continue de fonctionner! Dans le futur, les utilisateurs de Fedora Core 5 pourraient également profiter de AIGLX, une extension de X.Org et de GNOME permettant d'utiliser OpenGL pour produire des effets graphiques, comme des animations lors de la réduction des fenêtres ou de l'apparition des menus. Ces effets graphiques pourraient rivaliser avec ceux de Mac OS X et du futur Windows Vista. En utilisant Yum pour installer le pilote de NVIDIA, installer Fedora Core 5 est aussi simple que d'installer Fedora Core 4. Cette nouvelle version de Linux est donc une bonne option.