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' -printvous 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.rejet 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 rmou 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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:25