Gradvisa uppgraderingar till kärnan distribueras som patchar. Om du t.ex. har
version 1.1.45 och du upptäcker att det finns en `patch46.gz' till
den, så innebär det att du kan uppgradera till version 1.1.46 genom att
lägga till patchen. Det kan vara bra att ta en säkerhets-kopia av
källkods-trädet först (`make clean' och sedan
`cd /usr/src; tar zcvf old-tree.tar.gz linux', vilket kommer att
skapa ett komprimerat tar-arkiv åt dig).
Om vi fortsätter på exemplet ovan, låt oss förutsätta att du har
`patch46.gz' i /usr/src. cd-a till
/usr/src och kör en `zcat patch46.gz | patch -p0'
(eller `patch -p0 < patch46', om patchen inte är packad). Du
kommer se saker flyga förbi (eller krypa förbi, om ditt system är så
långsamt), vilka talar om för dig att det försöker lägga till bitar,
och huruvida det lyckas eller ej. Vanligtvis går det här för fort för att du
ska hinna med att läsa, och du kan inte vara så säker på om det fungerade
eller ej, men om du använder -s-flaggan till patch så
kommer patch endast rapportera fel (du får inte lika mycket av den
där "hallå, min dator gör faktiskt saker, för en gångs skull!"-känslan, men
du kanske föredrar det här...). För att leta efter delar som inte har gått
så bra, cd-a till /usr/src/linux och leta efter filer med en
.rej-ändelse. Vissa versioner av patch (äldre versioner,
vilka kan har kompilerats på ett underlägset filsystem) lämnar dessa
misslyckanden med en #-ändelse. Du kan använda `find'
för att leta;
find . -name '*.rej' -print
skriver ut, till standard ut, vilka filer, i den aktuella katalogen eller
underkataloger, somhar .rej-ändelser
Om något gick fel, gör en `make clean', `config' och
`dep', som det beskrivs i avsnitt 3 och 4.
Det finns en hel del alternativ till patch-kommandot. Som nämnts
ovan så kommer patch -s att hålla tyst om allt utom fel. Om du
har ditt kärn-källkods-träd någon annanstans än i /usr/src/linux,
så patchar patch -p1 allt korrekt (i den katalogen). Andra
patch-alternativ finns väl-dokumenterade på man-sidan.
(Observera: detta avsnitt hänvisar mestadels till ganska gamla kärnor)
Det vanligaste problemet som brukade uppstå, var när en patch modifierade
en fil som heter `config.in', och den inte såg riktigt rätt ut,
eftersom du ändrade alternativen för att passa din maskin. Det här har man
tagit hand om, men man kan fortfarande stöta på det hos äldre utgåvor.
För att fixa det, ta en titt på config.in.rej-filen, och se efter
vad som finns kvar av original-patchen. Förändringarna är vanligtvis
markerade med `+' och `-' i början av raderna. Ta en titt
på raderna före och efter, och tänk efter om de var satta till `y'
eller `n'. Editera nu config.in, och ändra `y'
till `n' och `n' till `y', där det ska vara så.
Gör en
patch -p0 < config.in.rej
och om det rapporteras att det lyckades (inga fel), så kan du fortsätta med
konfigurering och kompilering. config.in.rej kommer finnas kvar,
men du kan ta bort den.
Om du stöter på vidare problem, så kan du ha lagt till en patch i fel ordning.
Om patch säger `previously applied patch detected: Assume -R?', så
försöker du antagligen lägga till en patch som är under ditt aktuella
versionsnummer; om du svarar `y', så kommer patch försöka
nedgradera din källkod, och kommer antagligen misslyckas; då kommer du alltså
behöva skaffa ett helt nytt källkodsträd (vilket kanske inte skulle ha varit
en så dum idé från början).
För att backa ut (ta bort) en patch, använd `patch -R' på
original-patchen.
Det bästa du kan göra när patchningar verkligen går snett är att börja om
igen, med ett rent och opatchat källkodsträd (från en av
linux-x.y.z.tar.gz-filerna, t.ex.) och börja om.
Efter bara några få patchar kommer .orig-filerna vara ganska många.
T.ex. så hade ett 1.1.51-källkodsträd jag hade blivit rensat vid 1.1.48.
Att ta bort .orig-filerna sparade mig mer än en halv meg.
find . -name '*.orig' -exec rm -f {} ';'
tar hand om det åt dig. De versioner av patch som använder
# för misslyckaden, använder en tilde istället för .orig.
Det finns bättre sätt att bli av med .orig-filerna, vilka är
baserade på GNU xargs:
find . -name '*.orig' | xargs rm
eller "ganska säker men en aning mer pratig"-metoden:
find . -name '*.orig' -print0 | xargs --null rm --
Det finns andra patchar (jag kallar dem "icke-standard") än de som Linus distribuerar. Om du lägger till dessa så kanske inte Linus patchar fungerar korrekt, och du blir tvungen att antagligen backa ut, fixa källkoden eller patchen, installera ett nytt källkodsträd eller en kombination av dessa saker. Detta kan bli väldigt frustrerande, så om du inte vill modifiera källkoden (med möjligheten av väldigt dåliga resultat), ta bort icke-standard-patcharna innan du lägger till Linus, eller installera helt enkelt ett nytt träd. Sen kan du se efter om icke-standard-patcharna fortfarande fungerar. Om de inte gör det, så är du antingen fast med en gammal kärna, och blir tvungen att greja en massa med patcharna eller källkoden, för att få det att fungera, eller tvingas vänta på (eller möjligtvis be om) en ny version av patchen.
Hur vanliga är patcharna, som inte ingår i standard-distributionen? Du kommer antagligen höra talas om dem. Jag brukade använda noblink-patchen för min virtuella konsoll, eftersom jag hatar blinkande markörer (denna patch blir (eller blev, åtminstone) uppdaterad för varje ny utgåva av kärnan). Eftersom de flesta nya enhets-drivrutiner utvecklas som laddningsbara moduler, så minskar dock antalet icke-standard-patchar en hel del.