![[Barre Superieure]](../../common/images/Topbar-fr.gif){kind=small}
![[Barre inferieure]](../../common/images/Bottombar-fr.gif){kind=small}
![[Ilustration]](../../common/images/illustration16.gif)
Résumé:
Dans ce texte, je raconte comment j'ai installé une version récente
du système d'exploitation GNU/Linux sur un ordinateur portable.
Il est destiné à servir de référence pour ceux
qui souhaite installer Linux sur une machine similaire ou même un
ordinateur de bureau et il intéressera peut-être également
les développeurs de distributions. Le contenu est assez technique
et les lecteurs doivent avoir une pratique raisonnable (ou un intérêt
suffisant pour l'apprentissage) du système d'exploitation Unix.
C'est la deuxième fois que j'installe un système GNU/Linux sur un portable. Ma première expérience concernait un LapNote P150 et est documentée ici. J'ai utilisé des informations trouvées sur le cédérom Slackware comme par exemple les multiples HOWTOs, le Linux Installation Guide version 3.2, et bien sûr la page web Linux on Laptops. Toutes les informations qui suivent concernent spécifiquement l'installation de la Slackware 3.5 sur un Fujitsu 635T. Aucun lien vers des programmes spécifiques n'est fourni, sachant que le lecteur pourra les localiser grâce aux sites cités en référence.
J'ai acheté par email un laptop d'occasion, un Fujitsu 635T. Comme je m'y attendais, l'ordinateur arriva avec le soi-disant système d'exploitation "à fenêtres", version "95 OSR 2". L'installation de "fenêtres" était probablement une "réinstallation propre" effectuée par les précédents propriétaires avant de me le vendre. La carte son n'était pas reconnue et tout le système PCMCIA semblait également absent. Je ne me rappelle plus si le mode en couleurs vraies était supporté. Enfin je n'ai pas essayé la fonction "suspendre vers le disque", car il n'y avait aucune partition suspend-to-disk sur le disque dur, et je pensais que cela ne fonctionnerait pas et pourrait endommager la partition existante. (Mes peurs étaient infondées : Le BIOS reconaissait l'absence de partition suspend-to-disk et affichait un warning lorsque j'essaya d'activer cette option.)
Je savais qu'il n'était pas recommandé de succomber à la tentation de supprimer "fenêtres" immédiatement; Je devais en extraire quelques informations. Tout d'abord, j'ai installé le pilote d'impression "Texte générique" et utilisé le panneau de contrôle pour imprimer toute la configuration systéme dans un fichier, pour pouvoir plus tard servir de référence.Ce fichier est sans doute tout ce que l'on peut obtenir d'utile de ce soi-disant systéme d'exploitation, sachant que l'unité centrale était livrée sans manuels (Je ne remercierai pas le distributeur informatique, qui se reconnaîtra). En principe, toute cette information devrait apparaître dans le manuel du matériel. Mais l'usage en vigueur considère qu'une installation de "fenêtres" équivaut à donner toutes les informations utiles sur le matériel. En clair vous obtenez une copie installée de "fenêtre" supposée correcte a partir de laquelle vous pouvez essayer d'extraire l'information.
Juste après avoir enregistré la configuration matérielle sur une disquette, j'ai rebooté et lancé le setup du BIOS. Le BIOS avait une interface agréable et permettait de contrôler
|
|
La première chose à faire était de trouver comment créer les disquettes de démarrage de Linux. J'avais déjà téléchargé la distribution Linux Slackware 3.5 et parcouru les fichiers nommés README, INSTALL, etc. Conformément à la procédure proposée, j'ai utilisé le programme DOS "rawrite.exe" fourni avec Slackware pour créer les disquettes bootables à partir des images. La commande était quelquechose comme rawrite.exe bare.i a: exécuté dans le repertoire bootdsks.144 du cédérom Slackware pour créer une disquette de boot avec le plus simple ("bare") des noyaux, et tt>rawrite.exe color.gz a: dans le répertoire the rootdisk pour réaliser la disquette "root" également nécessaire pour lancer l'installation de la Slackware. Plus tard, j'ai compris que j'aurais dû utiliser le noyau "bareapm.i" car le laptop était doté de fonctions de gestion de l'alimentation (APM) et ainsi j'aurais pu les utiliser dès l'installation, par exemple en mettant en veille le portable au milieu de l'installation pour le rallumer plus tard.Mais tout d'abord, je ne voulais rien utiliser d'autre que le plus simple des noyaux. L'utilisation d'un noyau sans support APM occasionna quelques plantages étranges quand je laissa la machine pendant une heure et qu'il se mit automatiquement en veille. Le symptôme typique consistait en des erreurs de division par zéro, accompagnée d'un dump des registres, qui apparaissaient aléatoirement. Ce genre de désagréments disparut dès que je comença à utiliser un noyau gérant l'APM.
Une fois les deux disquettes réalisées, j'ai redémarré l'ordinateur et obtint un système Linux auquel je pu me connecter en "root" sans mot de passe. L'écran de connection que je devais d'abord créer des partitions disques pour Linux et exécuter le programme "setup" ensuite. Le même message disait que je pouvais utiliser aussi bien fdisk or cfdisk pour le partionnement. Comme je savais déjà que fdisk n'était pas très pratique à utiliser, je décidais d'essayer le programme cfdisk et fût agréablement surpris par son interface simple et intuitive en mode texte. Je supprimai la partition FAT unique de 1.35 GB (Aurevoir, "fenêtres" !) et créai une partition de swap de 64MB et deux (300 MB et 1 GB) partitions de type Linux natif "ext2" Je pensais utiliser la plus petite partition pour les fichiers systèmes et la plus grande pour les fichiers utilisateurs et les applications, ainsi si je décidais plus tard de réinstaller Linux, je n'aurais pas à tout effacer.
Après en avoir fini avec cfdisk, j'ai lancé le programme setup. Les premières étapes de l'installation fûrent suffisamment claires : changer la configuration du clavier (inutile), configurer la mémoire virtuelle, choisir les répertoires cibles et sources de l'installation. Je choisis la plus petite partition comme partition racine (/) et la plus grande comme répertoire /usr. Le premier accroc apparut avec le répertoire cible : Je ne possédais pas le cédérom original Slackware mais j'avais téléchargé tous les fichiers et je les avait placé sur un cédérom avec "fenêtres". Je réessaya plusieurs fois mais l'installation ne reconnaissait pas une distribution Slackware dans le répertoire que j'avais spécifié.
|
|
La prochaine étape consistait en la sélection des paquetages que je voulais installer. Je selectionnai tous les paquets exceptés les jeux, le kit de développement de serveur X et la documentation qui de toute façon était sur le cédérom. Puis le programme d'installation me proposa d'installer le gestionnaire de démarrage lilo sur le disque dur. Je choisis l'installation automatique de lilo avec le noyau bareapm.i. Je passais la configuration réseau, conservai la police de texte par défaut, précisai que mon modem était sur le port COM2, que ma souris était de type PS/2 et que mon fuseau horaire était Amseterdam. (Pourquoi n'est il pas possible de faire défiler cette gigantesque liste de fuseaux horaires avec Page Down ?) Enfin je redémarra le systeme avec succès. Je me reconnectai en root sans mot de passe, sur le système maintenant solide comme le roc, doté d'une puissance d'approximativement 53 "BogoMips". C'était à peu près ce qui était prévu pour un Pentium 133 Mhz (d'après le "BogoMips mini-HowTo").
Jusqu'ici le seul couac coincernait le lecteur ZIP sur le port parallèle qui n'était pas reconnu. Le pilote (ppa, parallel port adapter) disait grosso modo qu'il n'y avait pas d'adaptateur de port parallèle pour le port 0x278 (le message était pourtant difficile à comprendre, modprobe disait quelquechose comme "init_module: device or resource busy" en tête du message d'erreur). Je redémarrai pour consulter le BIOS : Le port parallèle était configuré pour le port 0x378. Bon, peut-être qu'il veut wants 0x278? J'ai passé le port en 0x278, mode bi-directionnel simple pour être sûr, et redémarrai. Cette fois le pilote du port parallèle se plaint de ne pas trouver de lecteur ZIP sur le port 0x378. Cela commençait à ressembler au jeu du chat et de la souris: Pourquoi est-ce que le pilote refusait d'accepter le port correct ? Le problème disparut dès que je recompilai une nouvelle version du pilote parallèle de lecteur ZIP (voir l'information correspondante sur la Linux Laptop web page). Le nouveau pilote, "Curtin" version 1.42, détecte tous les paramètres du port parallèle correctement et exploite un mode d'accès plus rapide avec mon port ECP.
J'ai également essayé d'éditer le fichier de configuration de lilo à la main, mais j'ai trouvé qu'utiliser le programme liloconfig est plus sûr, d'autant plus que j'ai l'habitude d'oublier de relancer lilo après avoir modifier sa configuration.
Derniers Commentaires : Parfois il y a des messages d'erreurs après certaines étapes de l'installation, mais elles disparaissent immédiatement dès l'écran suivant. J'aurais préféré que ces messages restent accessibles pour pouvoir m'assurer du succès de chaque phase de l'installation. Cela nécessiterait sans doute des scripts plus complexes, mais pas tant que ça. Au minimum, les messages des commandes pourraient être redirigés et afichés sur demande. Coucou, M. Volkerding, peut-être m'entendez vous.
Je m'attendais à ce que le premier problème majeur soit de configurer le système X window pour ma carte vidéo et mon écran LCD 800x600. Mais finalement, ce ne fut pas si pénible. L'installation fonctionna du premier coup, et seuls les modes en vraies couleurs nécessitèrent quelques corrections.
La distribution Slackware est fournie avec XFreee86, un serveur X de haute qualité qui affirme supporter complètement ma puce graphique. J'ai évalué la possibilité d'installer Accelerated X mais j'ai préféré Xfree86 car il est plus largement configurable et j'avais déjà eu une certaine expérience avec lui sur mon portable précédent, moins bien supporté. Il y a deux alternatives pour configurer XFree86 : Le programme de configuration en mode graphique et celui en mode texte. Comme la seule souris dont je disposais était le touchpad usé et peu maniable, j'ai opté pour la configuration en mode texte (l'interface était un peu dépouillée mais simple tout de même). Plus tard j'ai découvert que le programme de configuration en mode graphique n'aurait pas fonctionné à ce stade parce qu'il était incompatible avec gpm, le pilote de la souris en mode texte que j'avais installé et activé. Cela fonctionnait en le tuant avec gpm -k mais le mode graphique n'est pas vraiment utile pour la configuration et il nécesite une souris.
La carte vidéo, une C&T 65550 dotée de 2 Mo de mémoire, était présente dans la liste et j'ai sélectionné le mode 800x600 pour toutes les profondeurs de couleurs. Le seul défaut de la procédure se présenta quand on me proposa d'éxécuter X -probeonly pour détecter la liste des modes valides, et qu'il échoua parce que à ce point de l'installation les fichiers de configuration n'étaient pas suffisemment complets. Je passai cette étape et répondis aux autres questions. J'ai également ignoré les questions sur les caractèristiques du moniteur (comme les plages admissibles pour les fréquences de raffraichissement vertical et horizontal). Mon expérience précédente m'a appris que ces informations n'était ni nécessaire ni suffisante pour une installation réussie.
|
|
Après en avoir fini avec la configuration, j'ai regardé le principal fichier de configuration /etc/X11/XF86Config. Ce fichier est en général plein des instructions incompréhensibles insérées automatiquement par le programme de configuration. En ce qui concerne le matériel, la partie la plus importante est constituée de la section intitulée "Modelines". Chaque "Modeline" décrit un mode vidéo particulier, correspondant à une certaine résolution, fréquence de raffraichissement, etc. Chaque mode a un nom, et le fichier de configuration se réfère ensuite à un mode par son nom, lorsque le serveur apprend quel mode il doit utiliser dans chaque profondeur de couleur (dans la section Screen du fichier). Si plusieurs mode ont le même nom, le serveur n'utilisera qu'un seul d'entre eux, celui qui a la "meilleure" fréquence de raffraichissement et donc la meilleure qualité d'image. Je connais le problème de la configuration automatique : Il insère beaucoup trop de Modelines pour la même résolution et les nomme identiquement, comme 640x480 ou 800x600, laissant au serveur la tâche de sélectionner le "meilleur" mode pour le moniteur donné. Mais seuls quelques-un des modes nommé par exemple 800x600 sont utilisables. Ce qui arrive en pratique , c'est que si le mode sélectionné par le serveur ne fonctionne pas pour une raison quelconque, l'utilisateur est coincé. Une meilleure méthode est de renommer ces modes sous des noms différents, comme 800x600a, 800x600b, et ainsi de suite, pour permettre au serveur de tous les utiliser. L'utilisateur peut alors presser Ctrl Alt + and Ctrl Alt - pour basculer dans tous les modes disponibles et sélectionner celui qui lui apparait le meilleur.
J'ai donc effacé tous les modes sauf ceux en résolution 800x600, que j'ai renommés et dont j'ai inséré les nouveaux noms dans la section Screen, puis j'ai tapé startx pour démarrer le système X window. Mon meilleur mode était :
# 800x600 @ 60 Hz, 37.8 kHz hsync Modeline "800x600a" 40 800 840 968 1056 600 601 605 628 +hsync +vsyncIl y en avait un autre similaire à 56Hz avec presque la même qualité d'image. J'ai obtenu du premier coup une bonne image en haute résolution. Pourtant, je ne voyais aucun gestionnaire de fenêtres. De plus, le mode en couleurs vraies ne fonctionnait pas du tout. (Le mode en couleur vraies était activé par la commande startx -- -bpp 24 puisque sur ma carte le mode correct utilisait 24 et non 32 bits par pixels ; X configurator ne place pas de mode 32 bits dans la section Screen et utilise une profondeur par défaut de 8 bits par pixels.) J'ai lancé X en reditrigeant sa sortie (startx >& /tmp/startx-output) puis j'ai consulté le fichier obtenu. Cette technique est très utile pour diagnostiquer des problèmes de configuration avec X, car sinon les messages défilent trop vite.
L'absence de gestionnaire de fenêtres était dû au fait que la variable d'environnement DISPLAY n'était pas renseignée, pour une raison quelconque. Cette variable d'environnement est permet à tous les programmes de savoir où ils doivent afficher leurs fenêtres. j'ai résolu le problème en éditant le script startx (voir ci-dessous).
Le problème du mode en vraies couleurs se traduisait par le message suivant de X : "pixel clock being too high" ("fréquence pixel trop élevée"). Apparemment, il s'agissait d'une véritable limitation matérielle. Pendant quelques temps, j'ai pensé que le mode en couleur vraies était impossible à obtenir, mais lorsque j'ai regardé les modelines d'autres personnes pour des cartes C&T (en provenance de la masse d'information disponible sur la page Linux on Laptops), j'ai découvert le mode suivant qui fonctionnait avec une fréquence d'horloge inférieure.
#800x600 @ 49.5 Hz vsync, 30 kHz hsync, yucky and flickery even on LCD ModeLine "800x600b" 28.3 800 816 856 920 600 603 605 618Ce mode a une fréquence de raffraîchissement très basse et une mauvaise qualité d'image. Lors du changement de mode, le moniteur produisit un bruit désagréable et mes yeux souffrirent. Les écrans LCD donnent des images de meilleure qualité que les écrans CRT et souvent l'image est acceptable vers une fréquence verticale de 56 Hz (qui serait horriblement pénible avec un tube 14 pouces habituel) mais ce n'était pas suffisant dans ce cas. Sans savoir ce que je faisais, j'ai simplement augmenté la fréquence de 28.3 à 35.1 sans changer les autres paramètres. Le mode s'améliora sensiblement. J'ai alors tenté de remplacer la fréquence du mode précédent par la valeur limite minimale de 35.4 et ça a également marché ! C'est ce mode que j'utilise au moment où j'écris ceci. J'ai également ajouté la ligne DefaultColorDepth 24 à la section Screen du fichier XF86Config pour activer par défaut le mode vraies couleurs. Je me souvenais qu'il y avait un moyen de spécifier un certaine profondeur de couleur par défaut, mais j'ai dû parcourir la documentation de X pour retrouver le mot-clé exact "DefaultColorDepth", car celui-ci n'est pas présent dans le ficher de configuration généré par le script de configuration.
Pour faire accepter le mode 28.3 au serveur X, je devais modifier les bandes de fréquences autorisées par le moniteur. Le programme de configuration avait laissé :
HorizSync 31.5 - 37.9 VertRefresh 50 - 90mais ainsi le nouveau mode 28.3 ne voulait pas démarrer car certaines fréquences étaient trop basses : En examinant le fichier /tmp/startx-output je découvris que X se plaignait de fréquence dépassant les bandes autorisées. J'ai alors abaissé HorizSync à 30 au lieu de 31.5 and VertRefresh à 48 au lieu de 50. Ces deux paramètres ne sont pourtant pas essentiels (en particulier les bornes minimales) car les fréquences sont complétement déterminées par le modeline. En principe, ces paramètres permettent de protèger le moniteur en interdisant les fréquences trop élevées. Le serveur X calcule les fréquences correspondantes à chaque modeline puis rejet ceux dont les fréquences sortent du domaine autorisé. Mais en pratique,je n'ai jamais réussi à obtenir des informations précises sur les caractéristiques de mon moniteur et j'ai dû souvent modifier légèrement ces paramètres pour que le serveur X accepte les bons modes.
J'ajoutait deux touches finales : d'abord une ligne TextClockFreq 40 dans le fichier XF86Config pour restaurer la fréquence originale du mode texte lors d'un basculement entre la session X et une console texte, puis j'ai modifié le script startx (/usr/X11R6/bin/startx) pour laisser les consoles virtuelles accessibles et pour renseigner la variable d'environnement DISPLAY (cette variable était supposée être gérée par le gestionnaire de fenêtre, fvwm2, mais cela ne semblait pas fonctionner). La dernière partie du script était alors devenue :
export DISPLAY=":0.0" exec xinit $clientargs -- $serverargs >& /tmp/xinit.out &La dernière ligne redirige la sortie de la console X vers un fichier du répertoire temp et lance tous le processus X-window en arrière-plan (à examiner si nécessaire).
Le système fonctionnait mais j'avais l'impression de manquer une partie du fun : Je disposais de deux de ces dernières distributions semi-commerciales, Red Hat 5.1 et Suse 5.2, promettant toutes les deux une installation et une configuration d'une simplicité inégalée, pourtant j'utilisais la distribution des hackers des origines, Slackware. J'ai alors décidé de goûter aux alternatives.
|
|
Suse 5.2, malgré toutes les vertues qu'on lui reconnaît, n'a jamais réussi à démarrer sur mon laptop. J'ai réalisé les disquettes à partir de mon installation Slackware, avec la commande dd if=/cdrom/disks/eide01 of=/dev/fd0. Aucun des images de boot IDE (eide01 jusqu'à eide03) ne dépassa le message "Loading Linux..." (Avec 3 points), sans doute à cause d'un conflit de mémoire ou quelquechose du même ordre. J'ai entendu dire que parfois les disquettes de boot plantent et que l'on doit alors jouer sur le cache ou essayer avec des noyaux différents, mais ici 1) aucun des noyaux ne fonctionnaient,
|
|
Quand ) la Red Hat 5.1, elle m'intéressait d'autant plus que j'avais eu une précédente expérience avec la version 4.2 et on disait que les choses s'étaient beaucoup améliorées. Le processus d'installation étincelait, je n'ai eu qu'une disquette de démarrage à faire et tout fonctionna comme dans un rêve. Le port parallèle fût détécté avec succès comme '/dev/sda", mais comme je ne l'utilisais pas pour l'installation, il fût plutôt une gêne : Par exemple, fdiskne voulait plus démarrer, générant l'erreur "unable to access the default device /dev/sda". Pendant l'installation, je disposais en parallèle d'un console sur laquelle tournait déjà un shell bash, et de deux consoles log(Ctrl-Alt-F3 et F4) pour surveiller le processus d'installation. Plus tard, lorsque j'eus à choisir individuellement les logiciels à installer, je pouvais savoir combien d'espace était requis au total, contrairement à la Slackware. Ce dernier point n'était pas vraiment crucial étant donné que l'espace nécessaire maximum était inférieur à 400MB et que j'avais plus de double d'espace libre sur ma partition /usr.
J'arriva à la configuration de X window, qui aboutit presque sans effort. Le fichier /etc/X11/XF86Config qui résulta de la configuration n'était pas vraiment adapté à mon matériel car il lui manquait le mode en couleur 24 bits. C'était le mode 32 bits qu'il aurait dû supprimer à la place. Mais je savais déjà quels modes fonctionnaient et ce n'était pas plus mal comme ça. Mon chipset video (C&T) était correctement identifié. X démarra sans problème (sauf que les xterm s'affichaient en texte blanc sur fond noir, ce qui me déplait) et juste pour m'échauffer, j'ai essayé d'installer le nouveau Ghostscript 5.10 à partir du répertoire redhat/contrib en utilisant le glorieux rpm ("RedHat package manager", l'outil qui gère l'installation et la désinstallation des logiciels). Je pensais que ça allait être du gateau, juste besoin de taper une commande simple et intuitive comme rpm -i packagename.rpm au lieu du cryptique et pervers tar zxf packagename.tgz, n'est-ce-pas ? Oups... J'obtins un message de rpm qui affirmait qu'un autre paquet était nécessaire à l'installation, quelquechose comme "ghostscript-fonts-standard", et ce paquet était introuvable. D'autres paquets de fontes pour ghostscript étaient présents mais pas celui-là. Je me rappelle que rpm m'avait dit une fois (sous Red Hat 4.2) que je "n'avais pas le paquet /bin/sh sur mon système". /bin/sh est le shell, et je ne pourrais pas taper ces commandes sans lui. J'aurai aimé lui entendre dire que la carte mère était introuvable ! Bizarreries rpm typiques, laissons tomber. Globalement le système semblait fonctionner plus lentement qu'avec l'installation Slackware qui comportait à peu près les mêmes éléments.
|
|
Ensuite j'ai essayé le logiciel de configuration système linuxconf, présenté comme le meilleur ami de l'administrateur système. Malheureusement, j'ai été incapable de comprendre ce que ces multiples fenêtres allaient changer sur mon système. A certain endroits c'était évident mais dans d'autres c'était totalement inbitable. La principale préocupation pour moi est de comprendre la configuration du système et d'être capable de résoudre les problèmes sur la base de cette compréhension. Je soupçonne Red Hat et également les autres adeptes de la doctrine "make-it-easy" de vouloir simplifier l'administration système non en cachant des détails triviaux, mais en forçant l'administrateur à utiliser un certain programme et à ne jamais rien configurer à la main.
Une autre critique : Même su le lecteur ZIP était détecté, le temps d'accès était terriblement lent car le pilote utilisé était une très vieille version béta qui ne supportait que le plus mode le plus lent. Il fallait donc que je recompile le pilote (et sans doute le noyau) de toute façon. J'ai rencontré alors d'autres problèmes lors de l'installation des sources du noyau, dont je ne me rappelle plus maintenant. Compte tenu de cela et de ma peur des " bizarreries de rpm ", je décidai d'abandonner Red Hat et de retourner à la bonne vieille Slackware. Je redémarrai avec les disquettes d'installation que j'avais conservées, répétai l'installation avec les difficultés que je connaissais déjà et bientôt le système était de nouveau en service.
Au centre d'un système Linux se trouve le noyau, et je savais qu'il devait inclure le support de tous les périphériques connectés à mon système, de la souris à la carte son en passant par le ZIP parallèle et jusqu'au lecteur de cédérom SCSI. Je savais également que le noyau pouvait gérer ces pilotes sous forme de modules, c'est à dire les charger dynamiquement à la demande pour les décharger plus tard. Cela permettait d'obtenir un noyau plus petit et plus flexible, en principe, je pouvais charger et décharger les pilotes incompatibles selon les besoins. Par exemple, le pilote de l'imprimante pouvait être incompatible avec celui du ZIP, dans ce cas j'avais la possibilité de ne charger que l'un des deux pilotes à la fois.
|
|
Le noyau fourni avec une distribution Linux standard comprend les pilotes pour de nombreux périphériques de base, y compris ceux dont je n'aurai jamais l'utilité. Les pilotes de cette catégorie ne font rien d'autre que d'occuper de l'espace mémoire. Il est préferable de compiler un noyau spécifique qui correspond exactement à l'ordinateur sur lequel il s'éxecutera.
Sachant cela, je commençai à configurer et à compiler un noyau adapté à mon ordinateur. Comme j'avais choisi d'installer la totalité des sources du noyau (version 2.0.34) dès le début, la recompilation fût très simple. Dans le répertoire /usr/src/linux, j'ai tapé make menuconfig pour obtenir le programme en mode texte de configuration du noyau. En peu temps s'afficha une boite de dialogue accueillante qui proposait diverses options de configuration. Chaque option est largement commentée et l'on peut parcourir l'ensemble en très peu de temps. J'entrai toute l'information que je pouvais, de la carte son (une "ESS AudioDrive") qui n'était pas listée mais qui était un clone SoundBlaster d'après les README (s'il n'est pas listé explicitement comme clone, il devrait l'être). Je compilai tous les pilotes de périphériques sous forme de modules, cela incluait la gestion de l'énergie ("APM"), la carte son compatible SoundBlaster, la souris PS/2, les ports série, le lecteur de disquette, le support SCSI pour les lecteurs de cédérom et les disques (pour le ZIP, toujours bon à prendre). Je créai également des modules pour les fonctions réseau comme SLIP et PPP, pour les formats d'excutables a.out, ELF et Java (juste au cas où).J'ai compilé séparément les modules pour le système de fichier Macintosh (hfs) dont j'ai besoin pour lire des ZIP compatibles SGI, et la mise à jour du support ZIP parallèle (ces derniers ne sont pas inclus dans le noyau standard, mais j'avais besoin d'eux). J'ai également téléchargé le package PCMCIA le plus récent (pcmcia-cs-3.0.4) et compilé les modules pour la carte SCSI et la carte réseau.
Puis je lançaismake dep; make zlilo; make modules; make modules_install et attendis pendant près de 15 minutes. Une fois que tout fût terminé, les modules et le noyau fûrent placés à leur emplacements définitifs. Je vérifiai que le fichier du noyau /vmlinuzétait plus petit et plus récent que le précédent sauvegardé en /vmlinuz.old, et redémarrai... juste pour découvrir que le système ne démarrai plus, bloquant avec l'activation des systèmes de fichiers. La succession habituelle des messages de boot cessaient après le contrôle des partitions avec VFS: mounted root (ext2 filesystem) readonly. Aucun système de fichiers n'était monté en lecture-écriture et aucun script d'initialisation (lancés par INIT) n'était exécuté. Oups.
Après avoir redémarré avec la disquette de démarrage de la Slackware, qui contenait l'ancien noyau, je récupérais mon système, passais de nouveau en revue la configuration du noyau et commencit à réfléchir à ce qui n'allait pas avec le nouveau noyau. Je trouvai vite l'erreur fatale : J'étais tellement enthousiaste à l'idée de tout rendre modulaire que j'avais fait l'erreur stupide de compiler sous forme de modules le support de tous les formats exécutables (c'est à dire a.out, ELF et java). Le noyau et tous les programmes sont compilés en ELF. Ainsi, quand le noyau démarre, il est incapable de lancer quelque programme que ce soit avant de charger le module du support ELF, mais pour charger ce module il a besoin de lancer le programme insmod, qui est au format ELF. Pour s'en sortir, il faut bien évidemment compiler le support ELF dans le noyau et non comme un module. C'est une chose bien naturel puisque maintenant la plupart des programmes sont compilés à ce format. Après avoir recompilé le noyau avec cette seule modification, je pu redémarrer sans problème.
Ensuite j'ai inspecté le répertoire /lib/modules et effacé tous les modules plus anciens que ceux que j'avais recompilés. Ceci me débarrassa des messages d'erreurs au démarrage concernant des modules incompatibles. J'ai également édité les scripts d'initialisation /etc/rc.d/rc.S pour activer kerneld, le "démon" qui charge et décharge automatiquement les modules. Avec kerneld, il n'est plus nécessaire de charger et de retirer les modules soi-même en utilisant les commandes insmod et rmmod (même s'il est toujours possible de le faire). La commande lsmodaffiche la liste courante des modules chargés dans le noyau.
|
|
kerneld fonctionna sans difficultés, chargeant les modules lorsqu'ils étaient nécessaires et les retirant de la mémoire lorsqu'ils n'étaient plus utilisés pendant un cerrtain temps. J'ai eu besoin de rajouter la ligne alias scsi_hostadapter ppa au fichier /etc/conf.modules et le module ppa fût automatiquement chargé lorsque j'essayais de monter le lecteur ZIP(/dev/sda). Je suppose que ceci devrait changer si j'utilisais une carte SCSI au lieu du port parallèle.
Quelques points de détail de la configuration apparurent après que le nouveau noyau fût recompilé. il s'agissait de : la configuration de l'accès aux médias amovibles (en l'occurence les lecteurs de disquettes,de cédéroms et de ZIP). ,le support de deux souris en même temps, le support de la langue russe, et la configuration du gestionnaire de fenêtre fvwm2.
Le script d'installation Slackware avait créé le répertoire /mnt dans lequel on trouvait les sous-répertoires /mnt/floppy et /mnt/cdrom pour monter les systèmes de fichiers externes comme les disquettes et les cédéroms. Au début, j'avais décidé que ce n'était pas pratique de les placer dans un répertoire séparé et j'ai créé les répertoires /floppy et /cdrom sous la racine. Plus tard, je me suis rendu compte que j'avais besoin de plus de répertoire pour monter des périphériques avec des options différentes, et au lieur de tous les conserver dans la répertoire racine, j'ai recréé la hierarchie /mnt.
J'ai également modifié les options de montage de fichiers dans /etc/fstab. A la fin de l'installation, ce fichier contenait des valeurs par défaut raisonnables, mais il ne suffisait pas à mes besoins. Avant tout, je créai les lignes pour la disquette,le cédérom et le lecteur ZIP, désactivais leur montage automatique au démarrrage et permettais aux utilisateurs de les monter (avec l'option user) :
/dev/fd0 /mnt/floppy vfat user,noauto,noexec,nonumtail 0 0 /dev/sda4 /mnt/zip vfat user,noauto,noexec,nonumtail 0 0 /dev/hdc /mnt/cdrom iso9660 user,noauto,noexec 0 0Remarquez l'option noexec pour le système de fichier compatible DOS : Il rend les fichiers non exécutables, ce qui est sans doute une mesure de bon sens. L'option nonumtail empêche la génération de noms de fichiers horribles : le fichier longname.filesera renommé longname.fil au lieu de longna~1.fil s'il n'y a pas de conflits de noms. Le système vfat supporte les noms de fichiers longs tout en restant compatible avec DOS, contrairement au vieux type msdos, alors pourquoi ne pas l'utiliser.
Le paquetage mtools m'ennuya un peu : il nécessite soit des permissions en lecture écriture sur /dev/fd0 ou alors seul le superutilisateur peut écrire ou lire sur la disquette. Rien ne changeait si je positionnai le bit setuid sur le fichier mtools. Je décidai que je préferai monter les périphériques à la main.
Le problème de la souris était relativement simple grâce à l'expérience que j'avais retirée de la configuration de mon précédent laptop. Celui-ci possède un touchad incorporé (qui est techniquement une souris PS/2), mais j'aime également utiliser une souris externe connectée via le port série. Les deux souris peuvent facilement être supportée de concert en utilisant le programme gpm ("general purpose mouse"). Ce programme offre deux fonctionnalités : D'abord, il permet de gérer la souris sous forme d'un curseur dans les consoles textes
|
|
gpm -t ps2 -m /dev/psaux -2 -M -t mman -m /dev/cua0 -3 -R #wowzersCeci peut être décrypté ainsi : première souris de type ps/2 sur le port auxilliaire qui a deux boutons, la deuxième souris(-M) est de type [Logitech] MouseMan, est connectée au premier port série(/dev/cua0), a trois boutons ,et -R signifie que les deux souris doivent être disponible sous X-window come un unique périphérique. (Remarquez que l'option -R n'est pas nécessaire ici si l'on utilise gpm version 1.14 ou ultérieure.) Après avoir entré cette ligne, je tuai et redémarrai gpm (gpm -k; /etc/rc.d/rc.local) et maintenant mes deux souris fonctionnaient immédiatement sans aucun problèmes. Je pouvais même brancher la souris série au milieu d'une session X window et voilà, tout fonctionnait sur le champ. Ce genre de choses était impossible sous le soi-disant système d'exploitation aux "fenêtres" : Ce dernier demandait à l'utilisateur de redémarrer pour exploiter tout "nouveau matériel".
Je me suis occupé ensuite de la gestion des caractères cyrilliques. J'ai besoin de pouvoir lire et parfois écrire des textes en russes. Je n'ai installé le support du cyrillique que dans X window. Cela s'est fait en deux temps : installer les fontes cyrilliques et la description du clavier russe. Il y a un certain nombre de pages sur le Net qui expliquent la "Cyrillization d'Unix". Un jeu de polices KOI-8 est fourni avec Slackware. Le "Cyrillic Howto" se réfère à la collection VakuFonts created by Serge Vakulenko (vak@kiae.su). elle peut être trouvée dans l'archive cyrillic stuff for the X Window System. J'ai téléchargé deux jeux de fontes identiques dans les codes KOI-8 et CP-1251 (ou codage "windows"), désarchivé les fichiers de fontes (*.pcf.gz) dans les sous-répertoires koi8-r et x-cp1251 du répertoire principal de fontes d'X window /usr/X11R6/lib/X11R6/fonts/ (qui est plus facilement accessible sur mon système Slackware via le lien /etc/X11/fonts). Puis j'ai installé les fontes en ajoutant ces deux sous-répertoires au "FontPath" dans le fichier /etc/X11/XF86Config. Après cela, j'ai redémarré X window et toutes les polices étaient disponibles, et j'ai pu configurer Netscape (j'avais la version 4.05) pour utiliser automatiquement ces fontes avec les "encodages" koi8-r and x-cp1251.
Maintenant j'avais besoin d'un pilote de clavier russe. J'ai utilisé le programme xrus,simple et flexible, que j'ai trouvé sur la page Moshkow's Library, the page on Cyrillization, et après avoir patché son fichier de ressources /etc/X11/app-defaults/Xrus et la configuration du clavier conformément à mon idée d'une machine à écrire russe :) J'étais en train de taper confortablement en russe.
La dernière chose que j'avais besoin d'installer était un programme de conversion entre les différents encodages russes. J'ai utilisé un script maison très simple que j'ai appelé 323. Il est capable de convertir entre CP866 ("DOS" et "alternatives"), KOI-8, CP1251 ("Windows"), et l'encodage Macintosh. J'ai créé des liens vers 323 nommés koi2win, alt2mac et ainsi de suite (ln 323 koi2win etc.) et le script détermine automatiquement son action à partir de son nom de fichier. En utilisant ce script et les fontes installées, j'étais capable de lire à peu près n'importe quel texte russe.
|
|
Tout était proprement configuré pour le système X window, sauf le gestionnaire de fenêtres fvwm2. Toute sa configuration était controllé par un unique fichier de ressources ~/.fvwm2rc ou (si ce fichier n'existait pas) par le fichier système /etc/X11/fvwm2/system.fvwm2rc.Je trouvai que que le fichier fourni avec Slackware avait de nombreuses choses commentées qui n'était pas vraiment utiles ou qui ne fonctionnaient pas, et j'ai considérablement économisé sur ces "fonctionnalités". Les fonctions de base que j'exigeais d'un gestionnaire de fenêtre était : Afficher des boutons pour pouvoir lancer rapidement le petit nombre des programmes les plus utilisés, de répondre aux commandes des gestion des fenêtres (déplacement, agrandissement) provenant de la souris et du clavier, de placer certaines commandes dans la barre de titre de toutes les fenêtres, et de gérer un menu de toutes les applications X window installées. Idéalement tout cela devrait être accessible depuis le clavier sans toucher la souris.
J'ai commmencé avec le fichier de ressources fourni et l'ai édité à de nombreuses reprises, tout en lisant la longue page du manuel (man fvwm2) que j'ai trouvé assez dense, pour trouver comment les nombreuses fonctions étaient invoquées et ajouter mes modifications progressivement. En particulier, je souhaitais utiliser la touche "Windows 95" pour la gestion des fenêtres. Le résulat est ici, avec j'espère suffisamment de commentaires pour comprendre ce qui se passe.
L'accès dial-up PPP mon prestataire internet local fût configuré et fonctionnel si vite que j'en fûs ébahi. Après avoir lu des manuels compliqués et qui en plus semblaient obsolètes sur la configuration de PPP, dont le "Guide d'Installation", j'avais l'impression que la configuration de PPP était un processus douloureux. Pourtant, en essayant au hasard les commandes dont les noms commençaient par ppp, j'ai découvert que Slackware incluait un script nommé pppsetup qui me posait toutes les bonnes questions sur mon modem et mon prestataire PPP. Il y avait une chose que je ne savais pas, pourtant : si le "protocole d'authentification" était "PAP", "CHAP", ou "CHAP-Microsoft". J'ai choisi (au hasard) "CHAP" et continuais la configuration. Bientôt tout fût fini, et on me dit d'utiliser les deux commandes aux noms explicites : ppp-go and ppp-off pour controler la connection PPP, et il y avait également un fichier texte /etc/ppp/pppsetup.txt qui décrivait toutes les modifications apportées au système par pppsetup. Dans ce fichier, j'appris que je pouvais lancer ifconfig pour vérifier si la connection avait été établie avec succès, et on me dirigeait vers les fichiers /var/log/messages and /var/log/debug en cas de problèmes (car l'option debug était activée par défaut dans le fichier d'options /etc/ppp/options. Plus tard, j'ai l'ai désactivée car le fichier de déverminage était remplie presque en totalité par les messages de pppd, maintenant inutiles.)
Tout semblait paradisiaque, mais quand j'ai connecté le modem à la ligne téléphonique, la commande ppp-go ne semblait pas établir de connection. Le fichier /var/log/debugcontenait de nombreux messages. En regardant près de la fin du fichier, j'ai trouvé un échange infructueux entre pppd et la machine distante. L'un des messages reçu de l'hôte distant disait : <auth pap>. Aha, j'ai pensé, ainsi j'aurai dû choisir l'authentification "PAP" au lieu de "CHAP". J'ai relancé tt>pppsetup et la connection PPP était configurée et fonctionnelle en un rien de temps. En y repensant, le pppscript contenait des fonctions qui utilisaient grep et le fichier de messages système et affichaient des messages du genre "il semble qu'ils veulent PAP...", mais pour une certaine raison ces fonctions avaient été désactivées. Existe-t-il une meilleure version de pppsetup, sans doute son développement n'est-il pas encore fini ?
|
|
Même si PPP fonctionne maintenant parfaitement et que je peux utiliser fetchmail, ncftp, Pine, netscape et d'autres logiciels de qualité sans aucun problèmes, je ne suis pas complètement satisfait avec ma configuration. Je souhaiterai que le processus de connexion soit plus paramètrable et que les messages d'erreur, quand il y en a, soient visibles de l'utilisateur. Dans le cas où la connexion PPP échoue pour une raison quelconque, je ne voudrais pas à avoir à me connecter en root pour consulter les messages systèmes. Peut-être que ces Linux plus commerciaux sont livrés avec un utilitaire qui rend visible sous une forme agréable la connection PPP (par exemple gppp?), mais j'avais peur que ces utilitaires nécessitent l'installation de beaucoup d'autres bibliothèques inconnues ou même qu'ils ne fonctionnent pas du tout sans leur environnement "natif". Un jour, j'installerai un utilitaire plus convivial ou j'apprendrai Perl/Tk et j'écrirai ma propre interface de connection réseau. Ou alors je choisirai d'utiliser la Red Hat "tout du long" , quand son interface orientée objet GNOME atteindra sa maturité.
Une autre considération avec PPP est que le script ppp-go devait être démarré par le super-utilisateur. Au début ,je pensai à configurer la connection à la demande, mais pour une raison ou une autre, le noyau ne contenait une version du pilote PPP (2.3) qui supportait cette fonctionnalité. Alors j'ai fouillé dans les archives réseau et j'ai trouvé un programme C extrêmement court, "ppp pour mortels", qui appelle simplement la fonction setuid(0) pour devenir l'utilisateur root et ensuite exécute le script ppp-go. Je l'ai compilé puis installé dans mon PATH avec le bit setuid mis à 1 (chmod 4755 ppp_for_mortals). Après cela, je pouvais lancer ce programme en tant qu'utilisateur pour démarrer ou interrompre la connection PPP.
Traduit par Cyril M. Hansen
|
© Serge Winitzki 1998 LinuxFocus 1998 Contacter le Webmestre. |
![[Photo de l'Auteur]](../../common/images/Who.gif)