5. Mettre à jour le noyau

5.1 Appliquer un patch

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

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.

5.2 Si quelque chose ne fonctionne pas

(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

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).

5.3 Comment se débarasser des fichiers .orig ?

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 {} ';'

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

 find . -name '*.orig' -print0 | xargs --null rm --

5.4 Autres patches

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.