Author: Marc

Sous Linux la plupart des programmes sont livrés sous formes de packages, qui ne sont plus ou moins que des archives. Il en existe de différentes sortes (.tar.gz, .rpm, .deb), certains étant plus utilisés que d’autres suivant la distribution.

Les tar.gz/tar.bz2

REQUIS :

gcc, make, binutils, nasm, g++ : pour compiler
gunzip, bzip2, tar : pour décompresser l’archive

Ce format de package permet souvent d’avoir les sources d’un programme. C’est aussi le format le plus utilisé pour véhiculer des programmes.
Cependant sur un système à base de rpm comme la Mandrake ou La Red Hat je ne puis que déconseiller VIVEMENT l’utilisation de ces packages. Ces packages ne devront être utilisé que si la version équivalente en rpm n’existe pas.
Si le prog vient de sortir, il est d’usage d’attendre en moyenne une semaine avant qu’une version packagée en rpm ne sorte.

Le meilleur moyen de trouver des tar.gz , tar.bz2 est d’aller sur le site, la homepage du programme/projet. Pour cela on fera une recherche sur http://freshmeat.net ou http://www.linuxapps.com.

Le format d’archivage à proprement parler est le tar. Ensuite cette archive est compressée pour prendre moins de place soit par gunzip ( .gz ) ou bzip2 ( .bz2 ).

Pour utiliser l’application, il faut avant tout compiler les sources. Ne vous inquiétez pas, le processus est automatiser, et si tous ce passe bien, cela se fait sans douleur si les packages requis sont présent ( souvent des -devel qui sont des packages de développement ).

Pour compiler les sources il faut au minimum un compilateur ( gcc ), l’utilitaire make, nasm pour les optimisations mmx et les fichiers includes et de devel que le programme va utiliser. D’habitude ces vérifications se font lorsqu’on exécute le fichier configure. Donc prétez attention à ce qui s’affiche. Comme cela défile très vite concentrez sur le mot no : il est souvent synonyme du fait que quelquechose n’a pas été trouvé.

De plus il est souvent conseillé de décompresser l’archive dans le répertoire /tmp ceci afin de ne pas surcharger son répertoire personnel.

Comment installer un prog avec un tar.gz/tar.bz2 ?

Supposons que l’archive que nous devons décompresser se nomme foo-x.y.tar.gz ou foo-x.y.tar.bz2. Voici les différentes étapes qu’il faut suivre pour installer cette archive.

décompresser l’archive :

$> tar -zxvf foo-x.y.tar.gz<- cas d’un tar.gz (je recommande que gunzip/gzip soit installé)
$> tar -jxvf foo-x.y.tar.bz2<- cas d’un tar.bz2 (je recommande que bzip2 soit installé)
$> cd foo-x.y<- on va dans le répertoire crée lors de la décompression souvent le nom de l’archive

Compiler et installer :

$> ls<- on vérifie le contenu
$> ./configure<- si on aperçoit un fichier configure on le lance, regardez les message d’erreurs possibles
$> make<- on démarre la compilation
$> make install <- on install le prog

Note : si il n’y a pas de configure, il se peut qu’un “make” puis “make install” suffisent, ou alors chercher un fichier “setup” ou “install.sh” et le lancer. Cela se fera en tapant :
$> ./setup   <- lance le fichier setup. Sinon lire le fichier README ou INSTALL et suivre les instruction qui s’y trouvent.

Souvent le binaire du programme s’installe dans /usr/local/bin ( recommandé ). Pour forcer l’installation des différents dans /usr/local comme racine, il suffit de passer le prefix durant le configure :
$> ./configure –prefix=/usr/local

Explications :

Comme on peut le voir on fournit des options à la commandes tar. penchons nous un peu sur ces options :
z = le fichier est un tar.gz, donc il va décompresser en utilisant gunzip ou gzip
j = le fichier est un tar.bz2, donc il va décompresser en utilisant bzip2
x = eXtract = extrait l’archive, souvent cré un repertoire du nom de l’archive et y extrait les fichiers
v = Verbose = afficher message d’erreur si il le faut et ce qui se passe (on voit défiler les fichiers extraits)
f = File = spécifie que l’on va agir sur un fichier (tar a l’origine était fait pour les lecteurs de bandes et non pour les fichiers)

Si vous voulez juste lister le contenu d’une archive, il faut taper :

$>  tar -ztf foo-x.y.tar.gz

Il y a d’autres options (création, …) pour cela un “man tar” dans une console ou #tar dans la barre d’url de konqueror.

Comment convertir des tar.gz en rpm ?

En fait il faut passer par un programme nommé alien. Souvent ce programme est déjà inclus sur les CD de votre distribution. Avec kpackage/gnorpm/rpmdrake ou un urpmi alien” vous devriez être en mesure d’installer ce programme très simplement.
La conversion est relativement aisé. Il suffit de récupérer le .tgz (format slackware) ou le tar.gz (format général) et d’appliquer la commande alien comme suit :

$>  alien –to-rpm package.tar.gz

 

Les RPM

what’s this ?

Devant certaines lacunes du format tar.gz (pas de signature pgp, pas de gestion des dépendances, difficultés pour la maintenance), il a été crée par Red Hat un nouveau format d’archive le rpm (Red Hat Package Manager).
Ce format accroit la sécurité (signature pgp), la facilité d’utilisation et la maintenance. Les noms des rpm respectent un format précis de type nom-version.arch.rpm où :
nom  =  nom du package/prog
version  =  version du package/prog
arch  =  architecture pour lequel est fait le prog/package.
En effet Linux existant sur plusieurs architectures, on peut trouver des packages pour PowerPC ( ppc ), Alpha ( alpha ), Intel qui regroupe Pentium/Athlon et Cie (i386, i586, i686).
ix86 définit le niveau d’optimisation du code. Pour simplifier, nous allons plutôt désigner les rpm en ommetant l’architecture. Cela donnera des noms du genre foo-x.y.rpm au lieu de foo-x.y.i686.rpm.

De plus si vous trouvez des rpm du type foo-x.ymdk.i586.rpm, sachez que ce sont des rpms fait normalement spécialement pour la distribution Mandrake. Je ne saurais trop vous conseillezd’installer ces rpm en priorité si vous êtes sous Mandrake !

Comment vérifier qu’un package est installé ?

Pour utiliser les rpms il faut bien que le prog rpm soit installé. Il est forcément installé de base sur un sys à base de rpm (Red Hat, Mandrake).
Rien de telle qu’une petite vérification :

[[email protected] will] rpm -qa | grep rpm
rpm-python-4.0-33mdk
rpmdrake-1.3-59mdk
rpm-devel-4.0-33mdk
grpmi-8.0-9mdk
rpm-4.0-26mdk<- ce qui nous intéresse
rpmtools-2.3-21mdk
urpmi-1.5-34mdk
gnorpm-0.96-1mdk
rpmlint-0.31-1mdk
rpm-build-4.0-33mdk
gurpmi-0.9-34mdk

Nous venons de voir l’une des premières utilité des rpms : la possibilité de vérifier si un package est installé ou non. En effet à chaque installation d’un rpm, le programme rpm écrit dans une base de données ceci afin d’indiquer que le pros a été installé.

Explications :

q = query = interroge la base de données rpm
a = all = liste tous les packages installés
Pour ne pas tout voir défiler, on utilise la commande grep qui ne va donner que les lignes qui contiennent ce que l’on cherche. Ainsi grep rpm donne toutes les lignes qui contiennent rpm. On utilise un tube ( | ) pour transmettre la sortie du rpm -qa à la commande grep.
Pour chercher si un package est installé :

$> rpm -q package<- si on connait de manière précise le nom du package
$> rpm -qa | grep -i motif<- si on cherche un package dont le nom contient motif

Par exemple :

[[email protected] will]$ rpm -q rpm
rpm-4.0-26mdk

 

Comment installer un rpm ?

$> rpm -Uvh foo-x.y.rpm<- install le rpm

Explications :

U = Upgrade = pour une mise a jour, mais convient aussi pour une install
v = verbose = affiche des infos si nécessaires
h = hash =  montre la progression de l’install du package, ce sont les hash que l’on vois : ######
syntaxe :
rpm -Uvh package.rpm  (mis a jour)
rpm -ivh package.rpm   (installation)

Si jamais l’install d’un rpm échoue, souvent c’est due à un pb de dépendance, c’est à dire que le programme que l’on va installer a besoin de d’autres progs, or rpm ne le trouve pas dans sa base données. Souvent cela signifie que le prog n’est pas installé. Alors au choix on essaie d’installer ce progs à partir des CD d’install. Si il n’est pas dessus, on peut essayer de le télécharger sur internet, et là il y a un site qui fait référence : http://rpmfind.net
Pour une question de rapidité, je conseille d’utiliser les mirroirs français : http://fr.rpmfind.net ou http://fr2.rpmfind.net
Sur une Red Hat une solution serait d’utiliser soit gnorpm (semble gérer à peu près les dépendances) ou kpackages.
Sur Mandrake bien que kpackage et gnorpm soit dispos, on utilisera plutôt rpmdrake et urpmi.

Rpmdrake et urpmi permettent très facilement d’installer des packages et ce à partir de plusieurs sources (ftp, cdrom, local, …). rpmdrake n’est qu’un front-end pour urpmi.
Par défaut le sys a configuré déjà 2 sources qui sont celles des 2 CD d’install (en admettant que vous ayez utilisé les 2 CD d’install). Une autre source qu’il serait intéressant d’installer serait celle de cooker mais ce point est abordé ici.

Il peut arriver qu’un rpm ne veuille pas s’installer car il dit qu’il manque quelquechose, mais que l’on soit sûr de l’avoir installé (cas typique ou la lib est installée à partir de tar.gz ce qui fait que la BD de rpm ne le sait pas). Dans ce cas il faut forcer l’installation. Pour cela on va utiliser les options –force –nodeps.
IL NE FAUT UTILISER CES OPTIONS QUE SI L’ON SAIT CE QUE L’ON FAIT.
Cela donne :

$> rpm -Uvh –force –nodeps foo-x.y.rpm

Explications :

–force  = force l’install et ne tient pas compte de possibles erreurs
–nodeps  = ne tient pas compte des pbs de dépendances

 

Comment désinstaller un package ou un programme ?

C’est très simple avec les rpm.

$> rpm -e foo<- désinstall le package foo-x.y.rpm

e = Erase = effacer/enlever/désinstaller

Note : les options –force –nodeps sont aussi reconnues et utilisables au cas où le package serait indispensable a d’autres et que donc il ne veut pas l’enlever.

On peut aussi utiliser kpackage ou gnorpm et surtout rpmdrake/urpme sous Mandrake.

Comment lister le contenu d’un package installé ?

$> rpm -ql foo

q = query = interroge la BD de rpm
l = list = liste le contenu du package

On peut utiliser grep motif pour chercher un motif précis dans la liste des fichiers : rpm -ql foo | grep motif

 

Comment avoir des infos sur un package déjà installé ?

$> rpm -qi foo

i = info = demande d’informations

 

Comment lister le contenu d’un package non installé ?

$> rpm -qpl foo-x.y.rpm

p = package = précise qu’il faut interroger le package donné en paramètre et non la BD de rpm

 

Comment avoir des infos sur un package non installé ?

$> rpm -qpi foo-x.y.rpm

 

Comment avoir les dépendances d’un package non installé ?

$> rpm -qpR foo-x.y.rpm

Bien sûr il y a pleins d’autres options et de possibilités, et rien de mieux qu’un “man rpm” dans une console ou #rpm dans la barre d’url de konqueror pour avoir plus d’infos.

Comment installer des src.rpm ?

Les src.rpm sont des sources livrés sous formes de rpm. Donc il faut compiler le rpm qui va alors créer un package en .rpm (voire même le packages -devel qui correspond).
Note : il faut le package rpmtools et surtout rpm-build
Pour compiler le src.rpm :

$> rpm –rebuild foo-x.y.src.rpm

Ensuite installer les rpm crées :

$> rpm -Uvh /usr/src/RPM/RPMS/i686/foo-x.y.rpm
$> rpm -Uvh /usr/src/RPM/RPMS/i686/foo-devel-x.y.rpm

Note : L’emplacement où se trouvent les rpm peut varier. Pour vérifier il suffit de regarder les dernières lignes qui s’affiche après la compilation. Vous devriez apercevoir une ligne ressemblant à
Wrote: /usr/src/RPM/RPMS/ix86/foo-x.y.rpm
Les packages en -devel sont les packages de développement. Ils contiennent notamment les headers qui seront utiles pour compiler les programmes faisant appel au prog/librairies concernés.

 

urpmi/urpme/urpmf et rpmdrake

Ce sont les outils spécifiques de la Mandrake dont le but est de nous simplifier la vie. Ils permettent de gérer les packages rpms et leurs dépendances et offrent un moyen puissant de gérer les programmes installés sur son postes de travail.

Rpmdrake

Rpmdrake en lui même n’est qu’un front-end pour urpmi/urpmi. Avec rpmdrake on peut chercher un package précis qui serait dispo soit dans l’une des sources configurées (CD d’install, ftp, NFS, …). Les critères de recherches peuvent être le nom du package, un mot clé dans la description, la source, un fichier, etc …
Il permet d’ajouter des packages en prenant en compte les dépendances et cela avec une jolie interface graphique. Je vous conseille de jeter un oeil sur cette démo de Rpmdrake
Via rpmdrake il est aussi possible de faire les mises à jours de sécurité.

urpmi/urpme

Pour ceux qui aiment la rapidité et l’efficacité ->  urpmi/urpme.

$>  urpmi foo<- permet d’installer des rpm d’une sources en tenant compte des dépendances
$>  urpme foo<-  permet de désinstaller un rpm ainsi que ceux qui en dépendent.

urpmi/urpme acceptent les options suivantes (je donne une sélection des plus intéressantes) :
–auto = installe tous les packages requis sans demander confirmation
–force = installe le package et ceux qui en dépendent même si il peut y avoir des problêmes (écrasement de fichier, pb de dep ? – cas très très rare). Cela revient à répondre par l’affirmative à toutes les questions/confirmations qu’il aurait faire.
–allow-nodeps = Permet à urpmi de continuer l’installation et ce même si une dépendance n’est pas satisfaite ( souvent parce que le package n’a pu être installé ou trouvé )
–X = utilise une interface graphique
–provides = installe le package qui fournit ce qui est préciser ensuite en option. Ainsi pour installer le package du kernel sur les dernières mdk : urpmi –provides kernel va fournir la liste des packages fournissant le noyau
-a = installe tous les packages dont le nom correspond
–auto-select = sélectionne automatiquement les packages pour mettre à jour le système. Personnellement je n’ai jamais tenté cette expérience, je pense qu’il vaut mieux upgrader le système en gardant le control de ce que l’on fait c’est-à-dire le faire petit à petit de manière progressive et réfléchie.
–skip nom_package = Utile lorsque l’on fait une mise à jour globale ( –auto-select ) car il permet de préciser au coup par coup un package qu’il ne faut pas toucher ( à partir de la Mandrake 9.2 ).
–keep = Permet de dire à urpmi de ne pas désinstaller de packages et de ne faire que des mises à jours ( à partir de la Mandrake 9.2 ).
–no-verify-rpm = Permet de dire à urpmi de ne pas vérifier la signature gpg des packages. Utile lorsque vous installer des packages contrib ( à partir de la mdk 9.2 )

Dans /etc/urpmi/skip.list on peut préciser la liste des packages que l’on ne veut pas que urpmi touche.

urpmf

L’autre programme intéressant s’apelle urpmf. Il permet de trouver quel package contient un fichier précis : très utile quand un rpm ne veut pas s’installer car il manque un fichier.
Le fonctionnement est enfantin :

$> urpmf fichier

Il dit alors quel package contient/fournit le fichier. Ensuite il ne reste plus qu’a installer le package avec rpm ou urpmi.
Penchons plus longuement sur les possibilités de recherches qu’offre urpmf au travers des options qu’il accepte :
–summary = donne les packages dont le résumé contient contient le mot passé en argument
–description = donne les packages dont la desciption contient contient le mot passé en argument
Etant donné que la réponse peut être longue, il est conseillé de combiner cette commande avec more en utilisant un tube ( | ), de cette façon vous pourrez consulter tranquille les résultats si ils sont nombreux :

$>  urpmf –summary ftp | more<- on cherche tous les packages ayant un rapport le protocol ftp ( serveur ftp, client ftp) 
$>  urpmf –summary mp3<- tous les packages dont la description contient mp3 et qui sont donc en relation avec le mp3

urpmf –summary et urpmf –description ne sont pas la panacée pour trouver un package sur un sujet précis. Ainsi alors que xmms est le lecteur de mp3 le plus connu sous Linux ( clone de winamp ), il n’apparait pas dans les résultats ! Donc je ne saurais trop conseiller de parcourir la liste des packages dans rpmdrake ou d’aller sur les sites qui recensent les applications sous linux.

Il existe encore pleins d’autres options pour urpmf :
–provides = cherche dans les provides ( i.e les packages qui disent fournir quelquechose )
–requires = cherche dans les requires ( i.e listera les packages en ayant besoin )
–conflicts = cherche tous ceux qui entrent en conflit

urpmq

Pour savoir si vous avez un package (installé ou disponible dans une de vos sources de packages configurées), il suffit d’utiliser urpmq :

$> urpmq -gr package

Pour connaitres les dépendances d’un package :

$> urpmq -d package

Bien sûr on peut combiner avec -g ( affiche le groupe du package ) et -r ( affiche le numéro de version du package ) :

$> urpmq -dgr package

urpmi.addmedia

Cette commande permet d’ajouter des sources pour urpmi/rpmdrake. Les sources sont des emplacements où urpmi/rpmdrake vont aller chercher les rpms. Ces sources peuvent être locales ( disque durs ), amovible ( CDROM/DVD/ZIP/… ), distante ( ftp, rsync, nfs ). On les ajoutes avec urpmi.addmedia et on les enlèves avec … urpmi.removemedia.
On précise donc le nom de la source ( celui-ci doit être unique ( i.e 2 sources ne peuvent porter le même nom ), le protocol ( file pour un répertoire sur un disque local ou NFS, ftp pour un serveur ftp, http pour un serveur web, removable pour les média amovibles à savoir CDROM/ZIP/…
Éventuellement on peut préciser à urpmi.addmedia le fichier hdlist et ce en mettant son chemin relatif par rapport au répertoire qui contient les sources. Ce fichier contient la liste des rpms de la sources, les informations sur les différents packages et les relations de dépendances entre eux. Si le hdlist n’est pas précisé, urpmi.addmedia essaiera d’en faire un.

Imaginons que vous ayez un répertoire où vous ayez stocké des rpms et que vous vouliez qu’ils soient disponible lorsque vous installerez un package avec urpmi/rpmdrake, il vous suffit de taer la commande suivante :

$>  urpmi.addmedia mesrpms file:///path/vers/mes/rpms<- on ajoute une source nommée mesrpms pour laquelle les rpms se trouvent dans le répertoire /path/vers/mes/rpms

Prenons le cas de rpms se trouvant sur un serveur ftp et dont le hdlist est fournit ( il se nomme hdlist.cz et se trouve dans le répertoire précédent celui où se trouvent les rpms ), à ce moment là on fera ceci :

$>  urpmi.addmedia mesrpmsftp ftp://ftp.monserveur.com/path/vers/rpms with ../hdlist.cz

D’autres informations sont disponibles sur le site officiel d’urpmi à savoir http://www.urpmi.org

Note : Pour ajouter des média intéressants pour la Mandrake comme plf ( bcp packages multimédia comme support DVD cryptés, wma, rip de DVD, codecs windows, quicktime ), Texstar ( nouvelles versions de KDE, Gnome backportées de cooker vers la dernières version stable de la distribution ), je vous recommande vivement Easy urpmi qui vous permettra de choisir les mirroirs pour les différentes sources et vous donnera les lignes à taper.

+ Ajoutons une source plf pour mdk 9.1 et ce avec le miroir ftp de club internet :

$> urpmi.addmedia plf ftp://ftp.club-internet.fr/pub/linux/plf/mandrake/9.1 with hdlist.cz

+ Ajoutons une source contrib pour une mdk 9.1 via le site ftp de free.fr ( proxad.net ) :

$> urpmi.addmedia contrib ftp://ftp.proxad.net/pub/Distributions_Linux/Mandrake/9.1/contrib/i586 with ../../i586/Mandrake/base/hdlist2.cz

+ maintenant une source texstar pour la mdk 9.1 sur le miroir de ibiblio.org :

$> urpmi.addmedia texstar ftp://ftp.ibiblio.org/pub/Linux/distributions/contrib/texstar/mandrake/9.1/rpms with hdlist.cz

+ Pour refaire les sources de vos CD d’installations ( utile si vous les avez effacer par inadvertance ou que vous avez eu des CD en plus après coup ). On suppose que le CD1 d’installation est dans /mnt/cdrom :

$> urpmi.addmedia –distrib cd removable://mnt/cdrom/

Ce site est une référence si vous voulez apprendre à utiliser rpmdrake/urpmi : http://www.zebulon.org.uk/urpmi_fr.html

Tirez le meilleur parti de votre SSD sous Linux – voici ce que vous devez savoir.

Linux est assez bon prêt sortit de la boite, il y a encore quelques points particuliers qui nécessitent un peu d’optimisation manuelle pour qu’ils fonctionnent aussi bien que possible. Le contrôle de la consommation d’énergie est le problème le plus courant, mais l’optimisation de votre système pour les SSD est un autre élément important. Et c’est important de le faire, parce que les SSD bien entretenus sont un atout de taille dans votre arsenal.

Pour obtenir les meilleures performances et le moins d’usure de votre disque dur, essayez ces optimisations pour votre système Linux.

Mettez à jour votre distribution

Bien que je ne pense pas que ce sera un problème pour la plupart des gens, cela vaut quand même la peine d’être mentionné. Afin de profiter des dernières optimisations dans les applications, le noyau, le système de fichiers et bien plus encore, il est préférable d’exécuter la dernière version de votre distribution préférée.

Si même si vous êtes sur des versions plus anciennes mais toujours supportées (comme Ubuntu 12.04), il est préférable de mettre à jour vers la dernière version (comme 14.04) car il y a eu une tonne de changements qui rendent le système d’exploitation beaucoup plus convivial pour les SSD.

Mettre à jour le firmware SSD

C’est aussi une bonne idée de mettre à jour le firmware de votre SSD. Les instructions sur la façon de procéder sont différentes pour chaque fournisseur, vous devrez donc consulter les instructions pour votre SSD spécifique. Sachez que certains (mais pas tous) ne permettent pas la mise à jour du firmware via Linux ; au lieu de cela, vous devrez utiliser un environnement bootable spécifique (similaire à un environnement Linux live) ou un utilitaire Windows pour faire le travail.

Utiliser ext4

Lorsque vous venez d’installer un système Linux, il est préférable d’utiliser le système de fichiers ext4. C’est le système de fichiers le plus utilisé et le plus stable disponible qui supporte TRIM (qui doit encore être activé – plus d’informations ci-dessous).

Cela ne devrait pas poser de problème : la plupart des distributions sont par défaut à ext4.

Options de montage au démarrage

Chaque fois que vous démarrez votre système Linux, il doit monter les différents lecteurs dans votre ordinateur afin de les utiliser. Il existe différentes options de montage que vous pouvez utiliser, en fonction de votre matériel et de vos besoins, et certaines sont appropriées à utiliser avec les SSD.

Pour faire ces changements, ouvrez votre terminal et exécutez la commande sudo nano /etc/fstab. Ensuite, trouvez la (les) partition(s) dans votre (vos) SSD qui sont listées dans ce fichier. Les partitions sont normalement listées par UUID, ce qui est plus précis que le système d’identification /dev/sdXY. Si vous avez plusieurs partitions, vous pouvez utiliser la commande blkid /dev/sdXY pour trouver l’UUID, remplaçant X par a-z et Y par 1-9.

Ensuite, ajoutez les options de montage suivantes : discard et noatime. Discard permet d’utiliser la fonction TRIM du SSD, ce qui améliore les performances et la longévité. L’autre option, noatime, indique au système de fichiers de ne pas garder la trace des derniers temps d’accès – juste les derniers temps modifiés. Cela peut réduire l’usure de votre SSD, parce qu’il y a beaucoup de fichiers auxquels vous accédez lorsque vous utilisez votre ordinateur, mais il y a beaucoup moins de fichiers que vous finirez par modifier. Le fichier doit ressembler à la capture d’écran ci-dessus.

Si vous constatez que certains programmes se comportent mal avec l’option noatime (car les derniers temps d’accès seront avant les derniers temps modifiés, ce qui est normalement impossible), vous pouvez remplacer noatime par relatime. Ceci met à jour le dernier temps d’accès avec la même valeur que le dernier temps modifié, le tout dans la même opération d’écriture.

Ne pas utiliser SWAP

Lorsque vous utilisez un SSD, c’est aussi une très bonne idée de ne pas avoir une partition SWAP dessus (à moins que vous n’ayez une raison sérieuse de le faire).

Le simple fait de lire et écrire les partitions SWAP ajoute une usure significative au SSD. Si vous souhaitez vraiment avoir une partition SWAP, il serait préférable de la placer sur un disque dur secondaire, non-SSD si possible. Je sais qu’il est tentant de mettre une partition SWAP sur un SSD – ce serait la partition SWAP la plus performante que vous n’ayez jamais eue – mais cette vitesse a un coût majeur.

Beaucoup de gens suggèrent que vous pouvez toujours ajouter une partition SWAP mais désactiver l’hibernation, car cela provoque des quantités extrêmes de lectures et d’écritures. Mais comme il est rare que vous utilisiez une partition SWAP, car vous avez probablement plus qu’assez de RAM, cela ne fera qu’occuper de l’espace et causera potentiellement de l’usure. De plus, ne pas inclure une partition SWAP pour commencer est un moyen facile de désactiver l’hibernation.

Conclusion

Ces conseils devraient vous permettre de progresser vers une expérience SSD beaucoup plus optimisée sous Linux. Et votre SSD vous remerciera en durant quelques années de plus qu’il ne le ferait sans ces optimisations. Si vous vous sentez chanceux, vous pouvez rechercher encore plus d’optimisations liées au SSD qui peuvent ne pas convenir aux personnes au cœur fragile. C’est à vous de décider, mais ces conseils font le plus de bien à votre SSD.

Le but de cet HOWTO est d’aider à installer les drivers nvidia sous Mandrake 9.x. J’ai essayé de donner la méthode la plus propre qu’il soit pour que cela se passe sans encombres et ce en détaillant le plus possible.
Les commandes doivent être fait en tant que root ( super-utilisateur ).

Information :
Certains pourraient se demander : “Pourquoi est-ce si compliqué pour installer les pilotes NVIDIA sous linux ?”.
La réponse est complexe :
– Normalement les pilotes graphiques sont directement intégrés à XFree ( XFree est le composant qui gère de manière hardware la carte graphique, l’écran, la souris et le clavier ).
Cependant dans le cas des pilotes nvidia c’est plus compliqué, il y a 2 versions : une version libre qui n’a pas le support 3D mais est inclus dans XFree ( nv ) et une version non libre ( closed source ) récupérable sur le site de nvidia mais non inclus dans XFree ( nvidia ).
L’existence de cette version non libre est due au fait que nvidia ne pouvait/voulait faire une version OpenSource de ses pilotes à cause de problèmes de brevet concernant la partie 3D, notamment la partie openGL ( SGI détient le brevet ).

– une distribution comme Mandrake ne peut inclure les pilotes nvidia dans la version librement téléchargeable ( GPL ) car pour tous les logiciels inclus dans la version téléchargeable, il faut que les sources soient disponibles ( OpenSource ), or les pilotes NVIDIA n’étant pas Open source, ils ne peuvent être inclus. Si vous achetez la Mandrake, les pilotes seront inclus dans la version commerciale et aussi pour ceux ayant souscrit au Mandrake Club et l’installation sera grandement simplifié, voire même automatique.

– Enfin les pilotes NVIDIA intègrent des extensions spécifiques qui font qu’il ne peut se contenter des interfaces standards du noyau linux et donc il faut les compiler pour le noyau qui va être utilisé. De plus Linus Thorvalds ( le créateur de Linux ) ne voulant pas favoriser l’apparation de modules/drivers closed source, fait qu’il devient problématique d’utiliser un pilote sur un noyau autre que celui pour lequel il a été compilé

Installation

Préparation

REQUIS :
binutils, gcc, ed, kernel-source, glibc-devel

ed, kernel-source, glibc-devel se trouvent sur les CD de la distribution et peuvent être installé via urpmi/rpmdrake.
Vous devez installer la version de kernel-source qui correspond au noyau que vous utiliser !

Installation des sources du noyau ( kernel-source )

on installe ed,binutils et kernel-source. glibc-devel est installé automatiquement lorsque l’on installe kernel-source

# urpmi binutils ed kernel-source

vérification de l’installation des sources du noyau

on vérifie la version de kernel-source, par exemple on peut avoir comme résultat kernel-source-2.4.22-26mdk. ceci signifie que ce sont les sources pour le noyau 2.4.22-16mdk

# rpm -qa | grep kernel-source

vérification de la version du noyau

on vérifie la version du noyau que l’on utilise. Celle-ci doit correspondre à celle du package kernel-source. Par exemple cela devrait donner dans mon cas 2.4.22-26mdk

# uname -r

Note :
Si votre noyau est plus ancien que la version des kernel-source que vous avez, cela signifie que vous avez installé la dernière version des kernel-source de votre distribution et qu’un nouveau noyau est disponible. Ceci arrive si vous avez configuré votre système pour récupérer les mises à jour de sécurité et corrections de bogues via internet. Pour récupérer la dernière version du noyau, il vous suffit alors de l’installer via urpmi.

Pour cela vous tapez soit :# urpmi -p kernelqui vous donnera une liste des noyaux disponible, ou alors pour être sûr, vous taper directement le nom entier du noyau que vous voulez :# urpmi kernel-2.4.22-26mdkPour toujours utiliser la dernière version disponibles des noyaux pour votre système, mettez à jour vos sources updates :
# urpmi.update -aPuis récupérez les dernières version de votre noyau et de kernel-source avec urpmi. Ensuite vous mettez à jour lilo ( si vous l’utiliser ) afin de pouvoir démarrer sur le bon noyau :# /sbin/liloEt vous redémarrez en sélectionnant le bon noyau ( normalement linux devraient point vers le nouveau noyau, mais au pire vous pouvez sélectionner par exemple 2422-26 ). Une fois que vous avez fini de redémarrer, vous pouvez vérifier que c’est correcte avec la commande uname.

1°/ Récupération des drivers :

Télécharger les drivers nvidia sur le site de nvidia. Vous sélectionnez “Graphics Driver” puis “GeForce and TNT2” et enfin “Linux IA32” ( IA32 = Intel Architecture 32 bits, soit les processeurs Intel/AMD/Ciryx/Via 32 bits ). Si vous avez une connexion internet, vous pouvez procéder comme cela en console :

# urpmi wget‹— on install wget qui va nous permettre de télécharger les drivers
# cd /tmp‹— on va télécharger les drivers dans le répertoire /tmp
# wget http://download.nvidia.com/XFree86/Linux-x86/1.0-6111/NVIDIA-Linux-x86-1.0-6111-pkg1.run

2°/ Installation des librairies requises [ obsolète ] :

Note :A partir de la Mandrake 9.2, cette manipulation est inutile et est même déconseillée !!! Les librairies Mesa sont désormais livrés par défaut avec le serveur graphique X.

Il faut installer les librairies Mesa pour le support OpenGL. Pour cela il faut installer les packages libMesaGL1, libMesaGLU1 ( anciennement nommée Mesa-common ) :

# urpmi libMesaGL1 libMesaGLU1

3°/ Installation des drivers :

Arrêt de l’interface graphique

Tout d’abord le mieux est de quiter l’interface graphique, pour cela vous vous délogguez, ensuite vous basculer dans une console ( CTRL+ALT+F1 ), vous vous connectez en tant que root et vous tapez :

# service dm stop‹— permet d’arréter votre gestionnaire de connection ( gdm/kdm/mdkdm/xdm ) et d’arréter XFree

Installation du pilote

On lance le script d’installation qui se trouve dans /tmp

# sh /tmp/NVIDIA-Linux-x86-1.0-6111-pkg1.run

Note 1 : Lorsque vous tapez une commande faites attention à la casse ( respect majuscule/minuscule ). Un bon moyen pour éviter de faire de erreur est d’utiliser la touche TAB pour compléter automatiquement le nom du fichier. Souvent on tape les 3 premières lettre et ensuite on appuies sur TAB.

Note 2 : Si le driver ne dispose pas d’un module précompilé pour votre noyau alors il va essayer d’en compiler un : c’est pourquoi j’ai mis gcc, kernel-source et glibc-devel dans les requis. Cela devrait se passer normalement de manière transparente pour vous.

Note 3 : Si vous avez un message d’erreur concernant le support de rivafb activé et incompatible, vous pouvez l’ignorer. En effet bien que le support de rivafb soit activé dans le noyau, le module n’est pas chargé par défaut, donc il n’y a pas de problème. Si vous voulez vous en assurez, vous pouvez ajouter la ligne suivantes dans le fichier /etc/modprobe.conf ( noyau 2.6 ) ou /etc/modules.conf ( noyau 2.4) : alias rivafb off
Cette ligne empéchera le chargement du module rivafb.

Configuration du serveur graphique ( XFree/Xorg )

Chargement du pilote

Si tout s’est correctement déroulé, Il ne reste plus qu’a configurer XFree pour qu’il prennent en compte ces nouveaux drivers
Il faut d’abord vérifier si les modules sont configurés correctement. Pour cela on va vérifié que le chargement du pilote est configuré dans le fichier de configuration qui contient la liste des pilotes à charger au démarrage.
Sous le noyau 2.4, c’est le fichier /etc/modules.conf, sous le noyau 2.6 c’est le fichier /etc/modprobe.conf :

# grep -i nvidia /etc/modprobe.conf

Vous devriez obtenir la ligne suivante :

alias /dev/nvidia* nvidia

Si elle n’y est pas rajouter la à la fin du fichier /etc/modules.conf ( pour un noyau 2.4 ) ou /etc/modprobe.conf ( noyau 2.6 ). :

# echo “alias /dev/nvidia* nvidia” >> /etc/modules.conf‹— pour un noyau 2.4
# echo “alias /dev/nvidia* nvidia” >> /etc/modprobe.conf‹— pour un noyau 2.6

Note :Une autre solution pour s’assurer que le pilote sera chargé au démarrage est d’ajouter nvidia dans le fichier /etc/modules ( pour un noyau 2.4 ), ou /etc/modprobe.preload pour un noyau 2.6

Activation 3D/support OpenGL

Maintenant il faut modifier le fichier de configuration de XFree à savoir le fichier /etc/X11/XF86Config-4
Dans la section Module , ajouter Load “glx” . Cela devrait donner quelquechose comme cela :

Section “Module”
# This loads the DBE extension module.
Load “dbe”
Load “glx”
# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
SubSection “extmod”
#Option “omit xfree86-dga”
EndSubSection
# This loads the Type1 and FreeType font modules
Load “type1”
Load “freetype”
EndSection

Note : Si vous avez les lignes Load “dri” et Load “GLcore” , vous devez les enlever.

Note 2 : Sous la Mandrake 10.1 avec le passage à Xorg, il faut modifier le fichier /etc/X11/XF86Config ou /etc/X11/xorg.conf

Note 3 : Vous pouvez ajouter la ligne Load “v4l” pour avoir des optimisations matérielles concernant la vidéo. Cependant cette option devra être désactivé si vous revenez aux drivers livré par défaut avec XFree

Activation du pilote

Ensuite remplacer dans la section Devices le driver nv par celui de nvidia nommé nvidia
Vous devrier avoir quelquechose d’approchant :

Section “Device”
Identifier “NVIDIA GeForce 256 (generic)”
VendorName “Unknown”
BoardName “Unknown”
Driver “nvidia”
# VideoRam 4096
# Clock lines
# Uncomment following option if you see a big white block
# instead of the cursor!
# Option “sw_cursor”
Option “DPMS” “on”
EndSection

Vérifications

Chargement de l’interface graphique

Maintenant croisons les doigts et vérifions si tous s’est déroulé sans problême. Tout d’abord il faut relancer le serveur X pour que les changements prennent effet. Il est inutile de rebooter.

# service dm start

Normalement X devrait s’afficher de nouveau normalement.
Si vous vous logguer en mode console, quittez votre session, puis relancer X avec startx.
Il se peut que vous notiez un décalage de votre affichage et que vos polices sont devenus plus grosses. Ceci est due au fait que les drivers n’ont pas un support DCC ( Display Data Channel ) parfait.

Vérification du support OpenGL

Vérifier si le support OpenGL est bien chargé en tapant :

# xdpyinfo | grep GLX

Vous devriez obtenir à peu près cela :

GLX
NV-GLX

Une autre commande pour le vérifier est la suivante :

# glxinfo

Vous devriez obtenir pleins d’informations sur le drivers OpenGL et notamment les différentes extensions supportées.

Vérification que le pilote est bien chargé

Vérifer que le module est bien chargé et ce gràce à la commande lsmod ( list modules ) qui permet de voir la liste des pilotes/modules chargés :

# lsmod | grep nvidia

Si vous passez tous les tests alors vous êtes prêts pour la 3D accélérée sous Linux. Des jeux sont disponibles parmis lesquels Unreal Tournament, UT2003, Quake 3 Arena, Tribes 2, Descent 3, Kohan, Civilisation, NeverWinter Nights … .
Un jeu sympa que je recommande pour passer le temps : chromium.
C’est un shoot’em up en 3D avec des graphiques sympas, supporte le plein écran, mode fenêtre, du 640×480 au 1280×960, les CD audio ou une playlist de mp3, etc…
Il est dispo sur Mandrake 8.x, il suffit d’installer chromium et chromium-setup, puis de lancer chromium-setup pour configurer le jeu et chromium pour lancer le jeu.

# urpmi chromium
# urpmi chromium-setup
# chromium-setup
# chromium

Troubleshootings ( en cas de problèmes )

Si par vous n’arrivez plus à relancer votre serveur X, ne vous inquietez pas. Tout d’abord faites une copie du fichier de log de XFree ( /var/log/XFree86.0.log ), en analysant ce fichier vous pourrer éventuellement trouver la cause la problême. Pour voir son contenu il faut être root. Vous pouvez commencer par copier le fichier dans un répertoire temporaire plus facil d’accès :

# cp /var/log/XFree86.0.log /tmp

Note : Sous la Mandrake 10.1 et ce depuis le passage à Xorg, le fichier de log du serveur graphique se nomme Xorg.0.log et non plus XFree86.0.log.

Ensuite éditer le fichier de configuration de XFree et remplacez dans la section Devices Driver “nvidia” par Driver “nv” ce qui vous permet de remettre l’ancien drivers de XFree.
Ensuite relancer XFree en tapant startx dans la console. Si vous vous logguiez avec kdm/gdm, il faut faudra d’abord basculer sur console pour faire tout cela. Pour cela appuyer en même sur CTRL+ALT+F1 pour basculer sur la première console.
Il existe plusieurs éditeurs de texte qui permettent de modifier des fichiers en mode console, il y a par exemple : vi, emacs, vim, joe, pico, nano, etc …

Lorsque vous êtes a nouveau sous X, ouvrez la copie du fichier de log de XFree que nous avons faites dans un éditeur de texte. Cette copie se trouve normalement dans le répertoire /tmp si vous avez suivi les instructions précédentes : /tmp/XFree86.0.log
Les lignes les plus intéressantes sont les lignes qui commencent par (EE) car elles indiquent qu’il y a eu une erreur lors du chargement de ce paramêtre.

1°/ Toutes les résolutions sont rejetées !

Si par exemple vous remarquez que XFree à refuser toutes vos résolutions d’affichage, alors qu’elles sont correctes avec le drivers de base de XFree, alors le problême vient du support DDC des drivers nvidia. Pour y remédier il suffit de le désactiver en ajoutant dans la section Devices : Option “NoDDC” “true”. Cela donne à peu près :

Section “Device”
Identifier “NVIDIA GeForce 256 (generic)”
VendorName “Unknown”
BoardName “Unknown”
Driver “nvidia”
# VideoRam 4096
# Clock lines
# Uncomment following option if you see a big white block
# instead of the cursor!
# Option “sw_cursor”
Option “DPMS” “on”
Option “NoDDC” “true”
EndSection

Il ne vous reste plus qu’a relancer et X pour voir si X se lance cette fois-ci avec les drivers nvidia. Normalement ca devrait passer. Croisez les doigts.

2°/ Mon système est instable depuis que j’ai installé les drivers nvidia. Notamment il freeze complètement !

Si au cours de vos utilisations vous remarquez que votre système est instable et ce depuis que vous avez mis les drivers nvidia, il serait bon alors de vous penchez vers le support AGP. Par défaut les drivers nvidia utilisent leurs propres drivers pour l’AGP.
Une bonne solution pour remédier aux problêmes d’instabilités est d’utiliser alors le drivers du kernel agpgart ou alors en dernier recours de désactiver l’AGP.
Tout d’abord il faut que le support AGP soit activé dans votre noyau ( section Character Devices ) et cela pour /dev/agpgart et votre chipset de carte mère. Pour le vérifier rapidement faites :

# grep -i AGP /usr/src/linux/.config

Note : Sous Mandrakelinux, un fichier config est placé aussi dans le répertoire /boot, donc vous pouvez faire aussi :grep -i AGP /boot/config

Chez moi ( Mandrake 8.0 avec kernel de base 2.4.3-20mdk non modifié ) cela donne :

CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y

Comme j’ai une carte mère avec un chipset Via, j’ai mis en gras les deux options nécessaires dans mon cas.

D’abord nous allons vérifier quel est le drivers agp utilisé par les drivers nvidia. Pour cela il suffit de regarde le contenu de /proc/driver/nvidia/agp/status :

# cat /proc/driver/nvidia/agp/status

Pour utiliser le drivers AGP du kernel Linux, il suffit de préciser dans le fichier de configuration de XFree que nous voulons qu’il utilise agpgart.
Il suffit d’ajouter dans /etc/X11/XF86Config-4 à la section Devices pour le drivers nvidia la ligne suivante : Option “NvAgp” “2” . Cela donne par exemple :

Section “Device”
Identifier “NVIDIA GeForce 256 (generic)”
VendorName “Unknown”
BoardName “Unknown”
Driver “nvidia”
# VideoRam 4096
# Clock lines
# Uncomment following option if you see a big white block
# instead of the cursor!
# Option “sw_cursor”
Option “DPMS” “on”
Option “NvAgp” “2”
EndSection

Si vous mettez 0, il va désactiver le support AGP. Si vous mettez 1, il utilisera le drivers interne de nvidia. Comme nous venon de le voir, 2 signifie qu’il va utliser le drivers du kernel.
Pour des options plus avancées, veuillez consulter README.txt de nvidia. Il contient aussi des infos concernant le support des différents chipset AGP.

Note : Vous pouvez aussi pour ceux qui possède un processeur AMD démarrer votre système avec comme option pour le noyau mem=nopentium. Plus d’infos dans l’Appendice F du README nvidia.

3°/ J’ai upgradé XFree et depuis la 3D ne marche plus.

Cette situation est due au fait que XFree dans ses dernières versions est désormais livrée avec les librairies Mesa. Or celles-ci entrent en conflit avec les libs OpenGL des drivers nvidia. pour régler les problème il suffit de procéder comme lors de l’installation des drivers. Il suffit tout simplement de réinstaller les drivers, ceux-ci devraient faire les nettoyages nécessaires.

4°/ J’ai upgradé mon kernel et depuis XFree ne marche plus

Tout d’abord vous devez vérifier les logs/journaux du serveur graphique. Normalement vous devriez y lire un message d’erreur selon lequel il n’arrive pas charger le module nvidia.
Cette situation est due au fait que le module kernel des drivers nvidia n’a pas été copié dans le nouveau répertoire de modules de votre kernel. Voici une explication rapide.

Le kernel cherche les modules qu’il chargent ( notamment ceux préciser dans /etc/modules.conf ) dans le répertoire /lib/modules/`kernel_version`/kernel/drivers . Par exemple la Mandrake 8.0 utilise par défaut un kernel 2.4.3-20mdk, donc les drivers nvidia sont dans le répertoire /lib/modules/2.4.3-20mdk/kernel/drivers/video .
Si vous passez par exemple au kernel 2.4.9, alors le kernel ira chercher ses modules dans /lib/modules/2.4.9/kernel/drivers .
Comment régler le problème pour les drivers nvidia ? C’est tout simple, il suffit de réinstaller les drivers nvidia et il ajoute le module dans le répertoire de modules du kernel courant.

Mieux on peut demander au drivers d’installer le module/pilote pour une version donnée du noyau avec l’option –kernel-name=’VERSION’, où VERSION désigne la version du noyau telle que la renverrait la commande uname -r :

# sh NVIDIA-Linux-x86-1.0-6111-pkg1.run –kernel-name=’2.6.3-13mdk’‹— installation du pilote pour le noyau de version 2.6.3-13mdk

Pour vérifier il suffit de faire :

# modprobe -l | grep nvidia

Tout devrait marcher impeccablement.

5°/ L’interface met plusieurs minutes à se lancer, voire j’ai un écran noir total !

Cette situation peut être dues à des problèmes au niveau des BIOS de la carte graphique, celle-ci essayant d’activer un deuxième moniteur qui n’existe pas. Si vous avez un seul écran connecté à la carte graphique ( écran CRT ), vous pouvez préciser manuellement que seul un écran CRT est connecté et qu’il n’y a pas d’écran TFT et TV connecté. pour cela il faut ajouter dans la section Devices “ConnectedDevices” “CRT” et “IgnoreDisplayDevices” “DFP, TV”.
Cela donne par exemple :

Section “Device”
Identifier “NVIDIA GeForce 256 (generic)”
VendorName “Unknown”
BoardName “Unknown”
Driver “nvidia”
Option “DPMS” “on”
Option “ConnectedDevices” “CRT”
Option “IgnoreDisplayDevices” “DFP, TV”
EndSection

Note : Vous trouverez plus d’informations à ce propos dans le README des drivers nvidia.

6°/ Les performances 3D sont décevantes ou je n’ai pas le support de l’AGP avec un noyau 2.6

Si l’interface se lance mais que vous avez de mauvaises performances 3D, il se peut que cela vienne du support de l’AGP qui n’est pas configuré correctement. Un symptome est notamment que la DRI ne marche pas. Pour le diagnostiquer, il suffit d’utiliser la commande glxinfo et de chercher la ligne direct rendering. Si jamais la DRI est désactivée, vous aurez la ligne suivante :

direct rendering: No

Pour charger le module qui gère votre port AGP, il faut préciser à linux de charger le pilote AGP au démarrage. Tout d’abord il faut vérifier que la gestion AGP est active ( sous les noyaux 2.6 de la mdk 10.0 le support AGP est sous forme de module ). Il suffit de vérifier dans le fichier de configuration du noyau gràce à la commande grep -i AGP /boot/config ou grep -i AGP /usr/src/linux/.config :

CONFIG_AGP=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_I810=m
CONFIG_AGP_VIA=m
CONFIG_AGP_AMD=m
CONFIG_AGP_SIS=m
CONFIG_AGP_ALI=m
CONFIG_AGP_SWORKS=m

Pour moi qui possède un chipset Via ( Northbridge ), il faut qu’il y ait le support pour mon chipset. Le nom du module qui gère mon chipset est via-agp. Pour voir la liste des pilotes disponibles, il suffit d’utilise la commande modprobe -l qui permet de lister les différents modules disponibles pour le noyau. Nous ne prendrons que ceux dont le nom contient agp :

# modprobe -lt char | grep agp‹— commande qui va lister les différents modules qui gèrent les périphériques de type character ( -t char ), ce qui comprend le port AGP, et pour laquelle on ne récupère que les modules qui contiennent agp dans le nom ( grep -i agp )

Ensuite il suffit de dire au système de charger le module au démarrage de l’ordinateur. Pour cela on préciser le nom du module à charger dans le fichier /etc/modules ( noyau 2.4 ) ou /etc/modprobe.preload ( noyau 2.6 ). On peut le faire, par exemple, avec la commande suivante :

# echo “via-agp” >> /etc/modules‹— pour un noyau 2.4
# echo “via-agp” >> /etc/modprobe.preload‹— pour un noyau 2.6

Ensuite il suffit de redémarrer ou de charger le module directement ( modprobe via-agp ) puis de lancer l’interface

7°/ Comment désinstaller les drivers Nvidia ?

Pour désinstaller les drivers nvidia vous devez d’abord arréter l’interface, puis enlever les fichiers du pilotes avec la commande suivante :

# nvidia-installer –uninstall

Ensuite vous devez faire l’inverse de ce que vous avez pour activer les drivers nvidia. C’est-à-dire remplacer nvidia par nv, virer/désactiver les options spécifiques à nvidia en les commentant.
Par exemple la section device ressemblera à ceci :

Section “Device”
Identifier “NVIDIA GeForce 256 (generic)”
VendorName “Unknown”
BoardName “Unknown”
Driver “nv”
Option “DPMS” “on”
#Option “ConnectedDevices” “CRT”
#Option “IgnoreDisplayDevices” “DFP, TV”
#Option “NvAgp” “2”
EndSection

8°/ Comment mettre à jour les drivers Nvidia ?

pour mettre à jour les pilotes nvidia, il suffit d’appeler le programme nvidia-installer avec l’option –upgrade. Il se connectera au site de nvidia, téléchargera la dernière version des pilotes, les compilera et si tout se passe bien les installera.

# nvidia-installer –upgrade

Les programmes de gravure sous Linux ne savent gérer que les périphériques SCSI. Mais rassurez vous. Pour faire fonctionner les graveurs IDE, le noyau linux a recours à une petite astuce : émuler le graveur IDE en graveur SCSI. Il faut d’abord vérifier si les bonnes options sont activées dans le noyau :

SCSI Support -> SCSI support = M
SCSI Support -> SCSI generic support = M
SCSI Support -> SCSI CDROM support = M
ATA/IDE/MFM/RLL support -> IDE, ATA and ATAPI Block devices -> SCSI emulation support = M

Si ces options ne sont pas activées, alors il faut les activer et recompiler le noyau. Normalement sous Mandrake 8.0+ ces options sont activées par défaut et le graveur a de fortes chances d’être préconfiguré.
Ensuite il faut configurer le chargeur de boot pour qu’il dise au noyau quel périphérique émuler en SCSI, pour cela il faut lui passer l’option hdx=ide-scsi , où hdx désigne le lecteur IDE à émuler.

Avec lilo

Il suffit de modifier /etc/lilo.conf et d’ajouter la ligne suivante : append=” hdx=ide-scsi”. Si vous avez déjà append, il suffit de rajouter juste hdx=ide-scsi à la suite.
N’oubliez pas de relancer lilo pour qu’il réenregistre sa configuration en tapant /sbin/lilo.
La ligne append doit être ajoutée dans la section relative de votre noyau par exemple juste après le label.
Cela donne quelquechose de similaire a ceci :

image=/boot/vmlinuz
label=linux
root=/dev/sdb1
append=” hdc=ide-scsi”
read-only

Encore une fois seule la ligne en gras importe. Le reste dépend de votre configuration.

Avec Grub

Il suffit de modifier /boot/grub/menu.lst et de passer en paramètre au noyau en l’ajoutant directement à la ligne kernel l’option : hdx=ide-scsi”
Cela donne par exemple :

kernel (hd2,0) /boot/vmlinuz root=/dev/sdb1  hdc=ide-scsi

Encore une fois seul ce qui est gras importe. Le reste dépend de votre configuration.

Comme je l’ai dit, hdx désigne le lecteur de CDROM IDE que vous voulez émuler en SCSI. Pour information je rapelle la nomenclature des lecteurs IDE sous Linux :
hda = primary master
hdb = primary slave
hdc = secondary master
hdd = secondary slave

Si vous ne le savez vraiment pas (bien qu’il suffit d’ouvrir au pire sa tour), voici une méthode empirique pour le retrouver :

$> grep -r CD /proc/ide/

Et exceptionellement sous Linux, il faut rebooter pour que les changement soient pris en compte.
Ensuite on vérifie si tout est ok :

$> lsmod | grep ide-scsi<- on vérifie si le module d’émulation scsi est bien chargé
$> cdrecord -scanbus<- on vérifie si cdrecord (programme de base de gravure sous Linux) le détecte

Si cdrecord le détecte, alors c’est ok.

Avant de commencer la gravure, il convient de modifier /etc/fstab. En effet, le lecteur étant émuler en SCSI, son nom de device à changer.
Pour nous y retrouver on va créer un répertoire pour monter le graveur, par exemple /mnt/graveur. Puis tester le device.
Le CDROM IDE est émulé en SCSI donc il faut tester les devices SCSI. Les CDROM SCSI sont nommés scdx (Scsi CDrom). Pour cela on met un CD de donnés dans le graveur ou le lecteur IDE qui a été émuler en SCSI et on essaie les commandes suivantes :

$> mount -t iso9660 /dev/scdx /mnt/graveur<-  avec x = 0, 1, 2, 3, ….

Dès que cela marche, vous avez trouvé le graveur. Souvent c’est /dev/scd0.
Ensuite il faut faire votre lien. Faites :

$> ls -l /dev/cdrom*

Prenez le lien qui pointe vers votre ex cdrom IDE et effacer le. Supposons que ce lien est /dev/cdrom, cela donne :

$> rm /dev/cdrom

Ensuite faites le pointer vers le le nouveau lecteur IDE émuler en SCSI :

$> ln -s /dev/scdx /dev/cdrom

Ensuite vous rajouter la ligne suivante dans /etc/fstab :

/dev/cdrom /mnt/cdrom iso9660 ro,nosuid,noauto,exec,user,nodev   0 0

ou

/dev/cdrom /mnt/cdrom auto ro,nosuid,noauto,exec,user,nodev   0 0

Les utilisateurs d’une Mandrake préféront peut être utilisé supermount :

/mnt/cdrom /mnt/cdrom supermount dev=/dev/cdrom,fs=iso9660,ro 0 0

Note : Ce cas ne s’applique bien sûr que lorsque le lien vers le lecteur émulé en SCSI s’apelle /dev/cdrom.

Vous pouvez aussi remplacer /mnt/cdrom qui est le point de montage pour accéder au graveur par le nom que vous voulez : /mnt/cdrom1 , /mnt/graveur , … Bien sûr il ne faut pas oublier de créer le répertoire correspondant.

Ensuite il ne reste plus qu’a configurer les programmes de gravure.
Les plus connus ayant une interface graphique sont : xcdroast, eroaster, k3b, konCD. Vérifier si ces programmes ne sont pas déjà dispobnibles sur les CD de votre distribution.
Une fois le programme de gravure choisi et configurer il ne vous reste plus qu’a graver. Nul besoin de redémarrer à ce stade.

Note : Si voulez faire de la Copie de CD à CD direct, il vous faudra aussi configurer votre lecteur de CD en l’émulant en SCSI pour avoir le graveur et le lecteur en SCSI.

Si vous voulez faire des pochettes de CD sachez qu’il existe des programmes comme cdlabelgen, gtkcdlabel, kcdlabel.
Faites un tour sur http://rpmfind.net pour éventuellement récupérer la version en rpm adaptée à votre distribution.

Le but de cet HOWTO est d’aider à installer les drivers nforce sous Mandrake 9.x. J’ai essayé de donner la méthode la plus propre qu’il soit pour que cela se passe sans encombres et ce en détaillant le plus possible.
Les commandes doivent être fait en tant que root ( super-utilisateur ).

Information :
Les pilotes nforce disponibles sur le site de nvidia sont nécessaires pour faire marcher l’interface réseau du chipset ( nvnet ). Ils servent aussi pour la carte sons, mais linux peut gérer la carte son du chipset nforce avec le pilote snd-intel8x0 en lieu et place du pilote de nvidia ( nvaudio ).

Préparation

REQUIS :
binutils, gcc, ed, kernel-source, glibc-devel, rpm-build

ed, kernel-source, glibc-devel se trouvent sur les CD de la distribution et peuvent être installé via urpmi/rpmdrake.
Vous devez installer la version de kernel-source qui correspond au noyau que vous utiliser !

$> urpmi binutils ed kernel-source rpm-build<- on install ed, binutils, kernel-source et rpm-build. glibc-devel est installé automatiquement lorsque l’on installe kernel-source
$> rpm -qa | grep kernel-source<- on vérifie la version de kernel-source, par exemple on peut avoir kernel-source-2.4.22-26mdk
$> uname -r<- on vérifie la version du noyau que l’on utilise. Celle-ci doit correspondre. Par exemple cela devrait donner dans mon cas 2.4.22-26mdk

Note :
Si votre noyau est plus ancien que la version des kernel-source que vous avez, cela signifie que vous avez installé la dernière version des kernel-source de votre distribution et qu’un nouveau noyau est disponible. Ceci arrive si vous avez configuré votre système pour récupérer les mises à jour de sécurité et corrections de bogues via internet. Pour récupérer la dernière version du noyau, il vous suffit alors de l’installer via urpmi.
Pour cela vous tapez soit :
$> urpmi -p kernel
qui vous donnera une liste des noyaux disponible, ou alors pour être sûr, vous taper directement le nom entier du noyau que vous voulez :
$> urpmi kernel-2.4.22-26mdk
Pour toujours utiliser la dernière version disponibles des noyaux pour votre système, mettez à jour vos sources updates :
$> urpmi.update -a
Puis récupérez les dernières version de votre noyau et de kernel-source avec urpmi.

1°/ Récupération des drivers :

Télécharger les drivers nvidia sur le site de nvidia. Vous sélectionnez “Linux IA32 Drivers” ( IA32 = Intel Architecture 32 bits, soit les processeurs Intel/AMD/Ciryx/Via 32 bits ). Si vous avez une connexion internet, vous pouvez procéder comme cela en console :

$> urpmi wget<- on install wget qui va nous permettre de télécharger les drivers
$> cd /tmp<- on va télécharger les drivers dans le répertoire /tmp
$> wget http://download.nvidia.com/XFree86/nforce/1.0-0261/NVIDIA_nforce-1.0-0261.src.rpm

2°/ Préparation des sources du noyau :

Vous avez différentes commandes à taper afin de pouvoir préparer les sources du noyau pour une compilation correcte des pilotes nforces. Ces commandes doivent être faites précisément ( respect casse et espces, … ). Si vous le pouvez faites juste un copier/coller.

$> cd /usr/src/linux<- on va dans le répertoire où se trouve les source du noyau. Il est crée lorsque vous installez le package kernel-source
$> make mrproper<- on nettoie les sources
$> cp /boot/config ./.config<- on récupère les options de configuration de l’ancien noyau ( ceux de mdk )
$> make oldconfig<- on compile selon cette version
$> make dep<- on initialise les dépendances entre modules/pilotes du noyau

 

Installation/Compilation

On va lancer la compilation des pilotes. Cela devrait aboutir à la création d’un rpm qu’il ne nous restera plus qu’a installer.

$> rpm –rebuild /tmp/NVIDIA_nforce-1.0-0261.src.rpm

Vous devriez obtenir la ligne suivante tous à la fin si tout s’est bien passé :

Wrote /usr/src/RPM/RPMS/i586/NVIDIA_nforce-1.0-0261.i586.rpm

Ensuite on installe le rpm crée qui contient les pilotes nforce compilé pour notre noyau

$> rpm -Uvh /usr/src/RPM/RPMS/i586/NVIDIA_nforce-1.0-0261.i586.rpm

 

Configuration

Carte son

Normalement la carte son peut être gére par le pilote alsa snd-intel8x0. Pour le vérifier, il suffit de lister les différentes cartes sons configurés et leurs pilotes gràace à la commande :

$> grep sound-slot /etc/modules.conf

Normalement vous devriez avoir ceci :

alias sound-slot-0 snd-intel8x0

Si vous avez plutôt ceci :

alias sound-slot-0 snd-intel8x0
alias sound-slot-1 nvaudio

c’est due au fait que le rpm qui a installé les pilotes nforce a configuré votre modules.conf. Il y a une entrée en trop. Si vous n’avez qu’une seule carte son, alors seul sound-slot-0 doit apparaitre.

Utiliser le pilote ALSA

pour utiliser le pilote ALSA, il faut enlever les références au pilote audio nvidia des nforce ( nvaudio ) et éventuellement à d’autres pilotes audio ( comme i810_audio qui est le pilote OSS ).
Pour cela il faut virer toutes les lignes contenant alias sound-slot-x nomdupilote et ne garder que la ligne contenant alias sound-slot-0 snd-intel8x0. Cette ligne signifie que la 1ère carte son ( sound-slot-0 ) est gérée par le pilote ALSA snd-intel8x0.
A la fin on doit avoir donc une ligne pour le pilote ALSA, et une ligne pour l’émulation OSS, soit :

alias sound-slot-0 snd-intel8x0
above snd-intel8x0 snd-pcm-oss

Note :
Si vous avez des lignes du type “above nompilote snd-pcm-oss” en plus de “above snd-intel8x0 snd-pcm-oss”, vous devez les virer afin d’éviter qu’elles n’entrent en conflit.

Utiliser le pilote nvaudio de NVIDIA

Si vous préférez utiliser le pilote nvaudio de NVIDIA, à ce moment il faut enlever toutes les références à d’autres cartes sons ( lignes commençant par sound-slot-x ou x est un numéro ), ainsi que les ligne du type above nompilote snd-pcm-oss.
Ensuite vous devez juste avoir une ligne disant que la 1ère carte son est gérée par le pilote nvaudio :

alias sound-slot-0 nvaudio

Vérification

On peut charger le pilote sans avoir à redémarrer, mais bon pour faire simple, vous redémarrer l’ordinateur et ensuite vous vérifiez que le pilote est bien chargé en tapant /sbin/lsmod | grep nompilote.
Ainsi pour vérifier si le pilote ALSA est bien utilisé vous faites :

alias sound-slot-0 nvaudio

Chez moi cela donne comme résultat :

[[email protected] admin]$ /sbin/lsmod | grep snd-intel8x0 snd-intel8x0     15296 1
snd-ac97-codec       52588 0 [snd-intel8x0]
snd-pcm           79652 0 [snd-pcm-oss snd-intel8x0]
snd-page-alloc     8628 0 [snd-intel8x0 snd-pcm]
snd-mpu401-uart    4704 0 [snd-intel8x0]
gameport          3284 0 [snd-intel8x0]
snd              43972 1 [snd-seq-oss snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-intel8x0 snd-ac97-codec snd-pcm snd-timer snd-mpu401-uart snd-rawmidi snd-seq-device]

Note :
Si vous utilisez le pilote ALSA, n’oubliez d’enlever la propriétés muet pour Vol et PCM dans votre mixeur audio ( unmute ).

Carte Réseau

La chipset nforce sous la Mandrake 9.2 n’est pas géré nativement par le noyau. Dans la mandrake 10.0, le chipset réseau pourra être géré de base par le noyau gràce au pilote forcedeth qui sera intégré dans le noyau 2.4 et 2.6. Donc ce qui suit ne s’applique vraiment qu’à ceux ayant une mandrake dont la version est inférieure à la 10.0.

Tout d’abord vous devez vérifier que dans votre /etc/modules.conf il est spécifié que votre carte réseau doit utiliser le pilote nvnet.
Si vous n’avez q’une carte réseau, alors la 1ère carte réseau ( eth0 ) doit être associée au pilote nvnet, ce qui donne :

alias eth0 nvnet

Ensuite il ne vous reste plus qu’à charger le pilote puis à utiliser les outils de configuration de la mandrake qui désormais verra votre carte réseau.
Pour charger le pilote, il suffit de taper la commande suivante :

$> modprobe nvnet

Liens :

Où prendre les drivers :
http://www.nvidia.com/object/linux.html

La plupart des démons se trouvent dans le répertoire /etc/rc.d/init.d . C’est là qu’il faut copier le script qui va gérer le démon/service ou l’appli que l’on veut lancer au démarrage.

Pour savoir les démons lancés selon la runlevel, il faut aller dans le sous répertoire correspondant. Ainsi il faut aller dans /etc/rc.d/rcx.d (avec x = numéro de runlevel ).
Après avoir choisi le runlevel dans lequel on veut lancer le démon/service, il suffit de faire un lien vers le script qui se trouve dans /etc/rc.d/init.d . Pour bien faire les choses il convient de respecter certaines conventions.

Conventions :

• Le nom doit commancer par S (= Start ) suivi d’un numéro d’ordre sur 2 chiffres au minimum. Cela donne un nom du type Sxynom.
• Si le script doit faire quelquechose de spécial à l’arrêt du système il faut rajouter un lien qui commence par un K (= kill).
• Il devrait accepter comme arguments start (pour être lancé), stop (pour être arrêter) et accessoirement restart (pour relancer) et status (pour savoir si le script tourne et avoir d’autres infos).
• Il convient de choisir correctement le numéro d’ordre. Il ne faut pas qu’il soit identique à celui d’un autre démon, et enfin il faut choisir le numéro d’ordre correct.
  En effet imaginons que notre démon utilise la carte réseau et que le script qui configure les cartes réseaux ait un numéro d’ordre de 10. Il faudra que notre démon ait un numéro d’ordre supérieur à 10, sinon comment pourrait il utiliser les cartes réseaux si elles ne sont pas configurées ?

Lancement/arrêt :

Pour lancer/arrêter un service il existe plusieurs possibilités :

Via drakxservices

Vous avez une Mandrake, alors vous pouvez utiliser drakxservices ( Mandrake Control center -> Système -> services ). Avec drakxservices vous pourrez lancer et arrêter chaque services, spécifier si vous voulez qu’ils se lancent au démarrage pour le runlevel courant et aussi avoir une description pour certains.

Manuellement

Vous pouvez le faire à la main en lançant directement le script qui gère le service. Ces scripts sont dans /etc/rc.d/init.d . Cela donne :

 /etc/rc.d/init.d/monservice stop<- Pour arréter le service
/etc/rc.d/init.d/monservice start<- Pour lancer le service
/etc/rc.d/init.d/monservice restart<- Pour relancer le service
/etc/rc.d/init.d/monservice status<- Pour connaitre l’état du service

Via la commande service

Vous pouvez aussi utiliser le programme nommé service. Ce programme est très simple à utiliser. Si vous connaissez le nom du service il suffit de faire :

 service monservice stop<- Pour arréter le service
service monservice start<- Pour lancer le service
service monservice restart<- Pour relancer le service
service monservice status<- Pour connaitre l’état du service
service monservice<- Pour connaitre les autres options que peut accepter ce service

Par exemple pour samba dont le nom de service est smb cela donne :

[[email protected] root]# service smb stop
Arrêt des services SaMBa : [ OK ]
Arrêt du service NMB : [ OK ]

[[email protected] root]# service smb start
Lancement du service SaMBa : [ OK ]
Lancement du service NMB : [ OK ]

[[email protected] root]# service smb restart
Arrêt des services SaMBa : [ OK ]
Arrêt du service NMB : [ OK ]
Lancement du service SaMBa : [ OK ]
Lancement du service NMB : [ OK ]

[[email protected] root]# service smb status
smbd (pid 31865) est en cours d’exécution…
nmbd (pid 31876) est en cours d’exécution…

[[email protected] root]# service smb
I need an action
Utilisation: /etc/init.d/smb {start|stop|restart|status| condrestart}

Administration :

On peut vouloir ensuite spécifier pour quel runlevel on veut que le script se lance automatiquement au démarrage et pour quel autre on ne veut pas. Pour cela il y a plusieurs possibilités.

Via drakxservices

Pour les utilisateurs de la Mandrake, ils pourront utiliser drakxservices (Mandrake Contriol Center -> Système -> Services ) pour définir si ils veulent lancer le service pour le runlevel courant au démarrage ou non. Ils pourront aussi disposer d’une description du service ( si celui-ci le supporte ) ainsi que de son état courrant ( démarré ou à l’arrêt )

Via ntsysv ou tksysv

Les utilisateurs de Red Hat et de Mandrake pourront aussi utiliser ntsysv voire tksysv qui sont des outils en mode console ou avec une interface graphique en tcl/tk pour gérer les services.
Pour le runlevel courant il suffit de lancer ntsysv sans arguments et de cocher les services que l’on veut lancer au démarrage :

$> ntsysv

Pour un autre runlevel il suffit de spécifier la runlevel visé :

$> ntsysv –level 3<- permet de gérer les services de la runlevel 3
$> ntsysv –level 35<- pour gérer plusieurs runlevel en même temps ( ici 3 et 5 )

En utilisant chkconfig

chkconfig est un utilitaire qui permet de gérer les services en ligne de commande. Il se révèle pratique dans le sens qui permet par exemple de gérer des services dans un script. Pour cela il faut que le script du service soit correctement formaté car les informations sur celui-ci ( runlevel par défaut pour lequel le script doit être activé, description ) sont directement intégrées au début de celui-ci.

Obtenir des informations sur un service

$> chkconfig –list<- fournit la liste de tous les services reconnus et précise pour chaque runlevel si ceux-ci sont lancés au démarrage

$> chkconfig –list service <- fourni la configuration actuelle du service nommé service pour tous les runlevel

Actriver/Désactiver un service sur un service

$> chkconfig –level 35 service on <- spécifie que service doit être lancé au démarrage pour les runlevel 3 et 5

$> chkconfig –level 35 service off <- spécifie que service ne doit pas être lancé au démarrage pour les runlevel 3 et 5

$> chkconfig –add service<- ajoute service comme étant un service pouvant être géré par chkconfig ( bien sûr le fichier du script doit être correctement formaté )

$> chkconfig –del service<- supprime le service

$> chkconfig service reset<- remet la configuration à celle par défaut définie dans le script

Exemple :

Je veux lancer le démon diablo dont le script s’apelle diablod. ce script doit être lancé au démarrage des runlevel 3 et 5 et son n° d’ordre est 99 et … qui ne fait rien de spécial

Manuellement

On va procéder manuellement notamment en ce qui concerne la configuration du démarrage du script.

$>  cp diablod /etc/rc.d/init.d/<- je copie le script diablod dans /etc/rc.d/init.d

$>  chmod +x /etc/rc.d/init.d/diablod<- Bien sûr il faut que le script soit exécutable

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc5.d/S99diablod <- Comme je suis toujours en runlevel 5 et que je veux qu’il soit lancé en runlevel 5, je vais mettre le lien  dans /etc/rc.d/rc5.d

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc3.d/S99diablod <- Je vais de temsp en temps en runlevel 3 et je veux qu’il se lance au boot, donc j’ajoute un lien pour la runlevel 3

$>  ln -s /etc/rc.d/init.d/diablod /etc/rc.d/rc5.d/K99diablod <- Comme il fait un truc spécial à l’arrêt du système je rajoute un script kill

Avec chkconfig

Voici comment il me faudrait gérer le script avec chkconfig. Vous allez voir cela simplifie pas mal de chose car chkconfig s’occupe de tout.

$>  cp diablod /etc/rc.d/init.d/<- Une nécessité : je copie le script diablod dans /etc/rc.d/init.d

$>  chmod +x /etc/rc.d/init.d/diablod<- Bien sûr il faut que le script soit exécutable

$> chkconfig –add diablod<- je demande à chkconfig de prendre en charge mon script

$> chkconfig –level 23 diablod on<- J’active mon script au démarrage pour le runlevel 2 et 3

$> chkconfig diablod reset<- Oups, je me suis trompé, il fallait que ce soit 3 et 5. Comme c’est précisé dans mon script je demande à chkconfig de mettre les valeurs par défaut définies dans le script

Comme je l’ai dit avant, il suffit de regarder dans /etc/inittab pour connaitre la signification de vos runlevel.

contenu d’un script de service type

Voici le squelette de ce à quoi devrait ressembler un script globalement :

#!/bin/bash
#
#  chkconfig: 35 99 9
#  description: démarre et arrête mon service personalisé diablo
#               qui ne fait rien de spécial

# on va tester les arguments donnés au script
case “$1” in
start)
#si on passe comme argument start
echo -n “Lancement de $(basename $0)”
…. ce qu’il faut faire….
;;
stop)
#si on passe comme argument stop
echo -n “Arrêt de $(basename $0)”
…. ce qu’il faut faire….
;;
restart)
#si on passe comme argument restart
echo -n “Redémarrage de $(basename $0)”
…. ce qu’il faut faire….
;;
*)
#Pour tous les autres cas
echo -n “Usage: $(basename $0) start| stop|restart”
#on rappelle la syntaxe du script et on quitte
exit 1
esac

La ligne chkconfig: 35 99 9 signifie que chkconfig doit configurer le service pour qu’il se lance au démarrage des runlevel 3 et 5 avec un n° d’ordre de 99.
la ligne description contient la description du script , telle que par exemple on la verra afficher dans drakxservices.

Il arrive souvent que l’on veuille installer 2 distributions Linux en parallèle et pouvoir booter sur l’un et l’autre.

Plusieurs solutions existent, et parmi ces solutions, il y a le chain-loading.

Le Chain Loading consiste à chaîner les boot loader. Ainsi le chargeur de boot de la première distribution ( li/grub ) chargera le chargeur de boot de la 2ème distribution ( lilo/grub ) lorsque l’on voudra démarrer la deuxième distribution.
Comment procéder ? il faut respecter plusieurs étapes. La 1ère distribution que l’on va installer va devenir la distribution principale. Les autres seront appelées des distribution secondaires.

Note : Toutes les modifications de fichiers système et/ou les commandes devront être lancées en tant qu’administrateur du système ( root ).

Note 2 : On va se baser sur le schéma de partitionnement suivant :
distribution principale : / = /dev/hda2 , /home = /dev/hda5 , swap = /dev/hda7
distribution principale : / = /dev/hda3 , /home = /dev/hda6 , swap = /dev/hda7

Note 3 : Il peut se révéler très intéressant et très pratique d’utiliser la même partition pour le /home de la distribution principale et le /home de la distribution secondaire.

1ère étape : Installer la distribution principale

Tout d’abord on installe la distribution principale. C’est le chargeur de boot de celle-ci qui permettra de lancer les chargeurs de boot des distributions secondaires.
Pour cela, il faut installer le chargeur de boot dans la MBR ( Master Boot Record ) du disque de démarrage. Souvent ce sera pour un système IDE le Primary Master qui s’apelle sous Linux hda.

Lilo

Normalement lors de l’installation de votre distribution vous devriez pouvoir choisir facilement le fait d’installer lilo dans la MBR. Cependant dans le cas où vous voudriez le faire manuellement, il vous suffit d’éditer le fichier /etc/lilo.conf et de modifier l’option boot. Cette option définie l’endroit où lilo doit s’installer. Dans notre cas, nous supposons que hda est notre disque de boot et donc il faudra avoir boot=/dev/hda pour que lilo s’installe dans la MBR. Voici un extrait d’un lilo.conf avec l’option boot correctement positionnée :
boot=/dev/hda
map=/boot/map
prompt
nowarn
timeout=100
keytable=/boot/fr-latin1.klt
message=/boot/message
image=/boot/vmlinuz
label=”linux”
root=/dev/hda2
initrd=/boot/initrd.img
append=”resume=/dev/hda7 hdc=ide-cd splash=silent”
vga=788
read-only

Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

Pour installer GRUB dans la MBR, il suffira de lancer la commande suivante :
grub-install /dev/hda
On peut aussi utiliser la notation native de grub ce qui fait que la commande précédente devient :
grub-install ‘(hd0)’

2ème étape : Installer la ou les distribution(s) secondaire(s)

Après avoir installée notre distribution principale et vérifier qu’elle bootait correctement, nous allons installer la distribution secondaire. En fait là où il faut faire attention, c’est le fait qu’il ne faut pas installer le chargeur de boot de la distribution secondaire dans la MBR !!!. Il faut installer le chargeur de boot dans une partition. Souvent on choisira la partition / ou /boot de la distribution secondaire. Dans notre cas nous choisirons la partition / ( /dev/hda3 ).

Lilo

Lors de l’installation, on peut normalement décider de l’endroit où l’on veut installer lilo. Sinon on peut modifier manuellement le fichier /etc/lilo.conf afin que lilo s’installe sur une partition. L’option boot devra être positionnée correctement, dans notre cas cela donne boot=/dev/hda3. Voici un extrait du lilo.conf de la distribution secondaire :
boot=/dev/hda3
map=/boot/map
prompt
nowarn
timeout=100
keytable=/boot/fr-latin1.klt
message=/boot/message
image=/boot/vmlinuz
label=”linux_sec”
root=/dev/hda3
initrd=/boot/initrd.img
append=”resume=/dev/hda7 hdc=ide-cd splash=silent”
vga=788
read-only

Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

Pour installer GRUB dans la partition / de la distribution secondaire, il suffira de lancer la commande suivante :
grub-install /dev/hda3
On peut aussi utiliser la notation native de grub ce qui fait que la commande précédente devient :
grub-install ‘(hd0,2)’

3ème étape : chainloader les autres chargeur de boot à partir du chargeur de boot de la distribution principale

Après avoir démarrer avec la distribution principale, on va ajouter les entrées nécessaires dans le fichier de configuration des chargeurs de boot afin de chainloader les autres chargeurs de boot.

Lilo

On va donc ajouter une entrée dans /etc/lilo.conf de type other, pointant vers le / de la secondaire ( /dev/hda3 ), qui permettra de charger lorsqu’on la sélectionnera le chargeur de boot de la distribution secondaire. Voic l’entrée que l’on ajoutera :
other=/dev/hda3
label=”distro_2″
Ensuite pour valider les changement, il ne faut pas oublier de lancer la commande lilo :/sbin/lilo

grub

De même pour grub, on va modifier le ficher /boot/grub/menu.lst et ajouter l’entrée suivante :
title Distro secondaire           root (hd0,2)
chainloader +1
les changements seront pris automatiquement en compte par GRUB.

Voilà ! Normalement au prochain démarrage, lorsque vous sélectionnerez l’entrée correspondant à la distribution secondaire, vous tomberez sur son chargeur de boot et celui-ci vous permettra de la démarrer.