Les nouvelles versions du noyau sont distribuées sous la forme de patches.
Par exemple, si vous possédez la version 1.1.45, et que vous remarquez qu'il
existe un "patch46.gz", cela signifie que vous pouvez passer
à la version 1.1.46 en appliquant ce patch. Vous devriez faire avant une
sauvegarde de votre arborescence des sources de Linux
("make clean" puis
"cd /usr/src; tar zcf old-tree.tar.gz linux"
va produire une archive compressée).
Poursuivons avec cet exemple et supposons que vous ayez mis le fichier
"patch46.gz" dans /usr/src. Allez dans
/usr/src et faites un "zcat patch46.gz | patch -p0"
(ou "patch -p0 < patch46" si le patch est compressé).
Vous verrez alors une liste de messages vous indiquant
les essais de modifications. Cela marche ou pas. (En principe oui !).
Généralement, cela va trop vite pour les lire, et on ne sait pas trop
si ça a marché. Dans ce cas, vous devriez ajouter l'option
-s à patch, ce qui lui indique qu'il ne doit afficher que
les erreurs. (Vous n'avez pas grand chose à faire des "héhé, mon ordinateur
est en train de faire des quelque chose...!").
Pour regarder ce qui se passe, allez dans
/usr/src/linux et cherchez les fichiers ayant pour extension
.rej. Quelques versions de patch (vieilles versions) laissent
les fichiers rejetés avec # pour extension. Vous pouvez utiliser
"find" pour les trouver :
find . -name '*.rej' -print
vous en donnera la liste avec le chemin pour y accéder.
Si tout a marché, faites un "make clean", "config,"
et "dep" comme décrit dans les sections 3 et 4.
Il y a quelques options pour la commande patch.
Comme indiqué ci-dessus, patch -s supprime tous les messages
sauf les erreurs. Si vous
stockez les sources de votre noyau dans un autre répertoire que
/usr/src/linux, un patch -p1 dans ce répertoire
fera les choses proprement. Les autres options sont bien documentées dans
les pages de manuel.
(Note : cette section traite plutôt des noyaux assez anciens)
Le problème le plus fréquent qui se présente est lorsqu'un patch modifie le
fichier "config.in". Dans ce cas, ça ne marche pas très bien,
car vous avez changé les options pour mieux coller à votre machine.
En principe, ça ne devrait plus trop se produire, mais avec les
anciennes versions... Pour résoudre ce problème, jetez un coup d'oeil au
fichier config.in.rej et regardez son contenu.
Le changement sera indiqué par "+" et "-" au début
d'une ligne. Regardez ces lignes et retenez si elles sont marquées
"y" ou "n". Maintenant, éditez config.in,
et changez les "y" en "n" et les "n" en
"y" lorsque cela est nécessaire. Faites un
patch -p0 < config.in.rej
et si cela fonctionne, alors vous pouvez continuer avec la configuration
et la compilation. Le fichier config.in.rej restera, mais vous
pouvez le détruire.
Si vous avez d'autres problèmes, vous avez dû installer un patch défectueux.
Si la commande patch indique "previously applied patch detected: Assume
-R?", vous êtes probablement en train d'appliquer un patch déjà appliqué.
Si vous répondez "y", cela risque détruire votre source (chose
qui peut ne pas être une mauvaise idée dans un premier temps...).
Pour revenir en arrière (dépatcher), faites un "patch -R" sur le
patch original.
La meilleure chose à faire lorsqu'un patch détruit tout, est de repartir
d'un noyau initial tout neuf ! (par exemple, à partir des fichiers
linux-x.y.z.tar.gz).
Après avoir appliqué quelques patches, les fichiers .orig
vont commencer à s'empiler. Par exemple, j'en étais à la version
1.1.51 et la dernière fois que j'avais fait le ménage, c'était avec la version
1.1.48 (je crois...). Détruire les fichiers .orig a permis de récupérer
près d'un Méga octets.
find . -name '*.orig' -exec rm -f {} ';'
fera cela pour vous. Quelques versions de patch qui utilisent
# pour les rejets utilisent un tilde à la place
de .orig.
Il y a d'autres manières (meilleures ?) pour se débarrasser des fichiers .orig
qui utilisent le programme GNU xargs :
find . -name '*.orig' | xargs rm
ou la méthode sûre mais un peu plus verbeuse :
find . -name '*.orig' -print0 | xargs --null rm --
Il y a toujours d'autres patches (je les appellerais "non-standards") que ceux que distribue Linus. Si vous les appliquez, les patches Linus risquent de ne plus marcher correctement et vous serez obligé soit de les enlever, soit d'adapter les patches. C'est généralement un travail assez pénible pour les novices, aussi revenir aux anciens sources avant d'appliquer les patches de Linux semble être une bonne solution. Après, vous pouvez regarder si les patches non standards fonctionnent. S'ils ne fonctionnent pas, soit revenez à l'ancienne version, soit essayez de modifier le patch pour le faire fonctionner, ou alors attendez qu'un nouveau patch arrive.
Quelle est l'utilité des patches qui ne trouvent pas dans les distributions standards ? Vous le saurez en écoutant les autres. J'ai l'habitude d'utiliser le patch "noblink" car j'ai horreur des curseurs qui clignotent (Ce patch est (ou bien était) mis à jour fréquemment pour les nouveaux noyaux). Avec les gestionnaires de périphériques étant de plus développés sous la forme de modules chargeables, le terme patch "non standards" a de moins en moins de signification.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre