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 du noyau ("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 n'est pas
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 lire, et on ne sait pas trop si ça a
marché. Vous pouvez utiliser l'option -s de patch 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 quelque
chose...!"). Pour vérifier que tout s'est passé sans encombre, allez
dans /usr/src/linux et cherchez les fichiers ayant pour extension
.rej. Quelques versions de patch (vieilles versions) utilisent
# pour les fichiers rejetés. 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.
La commande patch possède quelques options. 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ésentait était lorsqu'un patch
modifiait le fichier "config.in" et que vous aviez 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 ("no fails"), 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 peut-être installé 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
de détruire votre source et il vous faudra récupérer un source complet (vous
auriez peut-être dû commencer par là).
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 du fichier
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
plus d'un demi 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 en utilisant 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 d'autres patches (je les appellerai "non-standards") que ceux distribués par 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 anciennes 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, vous pouvez revenir à l'ancienne version, ou essayer de modifier le patch pour le faire fonctionner, ou encore attendre qu'un nouveau patch arrive.
Vous entendrez probablement parler de ces patches non standards. J'utilisais 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). Les pilotes de périphériques étant de plus développés sous la forme de modules chargeables, le nombre de patches "non standards" décroît.