A kernel inkrementális frissítéseit patch (``folt'') formában terjesztik.
Például, ha neked a 2.0.30 verzió van meg, és észreveszed, hogy van hozzá
valahol egy `patch-2.0.31.gz', akkor ez azt jelenti, hogy upgrade-elhetsz
a 2.0.31 verzióra a patch alkalmazásával. Elõször talán készíts egy biztonsági
másolatot a forrásról. (`make clean' aztán
`cd /usr/src; tar zcvf old-tree.tgz linux'
csinál neked egy tömörített tar archivumot.)
A fenti példát folytatva, tegyük fel, hogy a `patch-2.0.31.gz'
az /usr/src-ben van. Menj át az /usr/src-be (cd)
és add ki a `zcat patch-2.0.31.gz | patch -p0' parancsot
(vagy `patch -p0 < patch-2.0.31.gz', ha a patch nincs tömörítve).
Egy csomó minden fog elsuhanni elötted a képernyõn (vagy épp elvánszorogni,
ha annyira lassú a gép).
Üzenetek jelennek meg arról, hogy a patch éppen mit csinál, és hogy sikerült-e
neki vagy nem.
Ez általában túl gyors ahhoz, hogy bármit is el lehessen olvasni. Ha nem vagy
biztos benne, hogy sikerült-e, használd a patch -s opcióját,
aminek hatására csak a hibaüzeneteket írja ki.
Menj be a /usr/src/linux-ba és keress .rej (``reject'')
kiterjesztésû fájlokat. A patch néhány verziója
(olyan régebbi verziók, amelyeket gyengébb fájlrendszerhez fordítottak)
# kiterjesztést ad a ``reject'' fájloknak. A `find'
parancsot használhatod a keresésre:
find . -name '*.rej' -print
Ez kiírja a standard outputra az összes olyan fájl nevét, amely az aktuális
könyvtárban, vagy az abból nyíló alkönyvtárakban van és .rej
a kiterjesztése.
Ha minden simán ment, akkor add ki a `make clean', `config',
és `dep' parancsokat a 3. és 4. fejezetben leírtaknak megfelelõen.
A patch parancsnak elég sok opciója van. Ahogy az elõbb is szó volt
róla, a patch -s kikapcsolja az üzeneteket, a hibák kivételével.
Ha a kernel forrását nem az /usr/src/linux-ben tartod, hanem valahol
másutt, akkor a patch -p1 (az adott könyvtárban) fogja helyesen
megpatchelni. A többi patch opció jól le van írva a manualban.
A fenti folyamat akár automatizálható is a patch-kernel scripttel,
ami szintén megtalálható a kernel forrásában. Meghatározza a kernel
aktuális verziószámát, majd minden patch-et alkalmaz rá amit megtalál,
s ami frissebb az aktuális kernel verziójánál.
cd /usr/src
. linux/scripts/patch-kernel
A kernelforrás alapértelmezett könyvtára a /usr/src/linux, de elsõ
argumentumként más is megadható. Továbbá a patch-eket az aktuális könyvtárban
keresi a script, hacsak a második argumantumban nem adsz meg egy másik
könyvtárat.
(Megjegyzés: ez a fejezet fõként nagyon régi kernelekre vonatkozik)
A leggyakrabban felmerülõ probléma régebben az volt, hogy a patch
módosított egy `config.in' nevû fájlt, és nem sikerült, mert
a felhasználó megváltoztatta az opciókat, hogy illeszkedjen a gépéhez.
Ezt azóta megoldották, de még lehet vele találkozni egy régebbi kibocsátás
esetében. A következõképpen lehet megjavítani: Nézz bele a
config.in.rej fájlba és keresd meg mi maradt az eredeti patch-bõl.
A változásokat általában sor eleji `+' and `-' jelek
jelzik. Nézd meg a körülötte lévõ sorokat és jegyezd emg, hogy az állásuk
`y' vagy `n'. Utánna szerkeszd át a config.in-t,
és változtasd meg a `y'-t `n'-ra és az `n'-t
`y'-ra a megfelelõ helyeken. Addj ki egy
patch -p0 < config.in.rej
parancsot, és ha sikerül (nincs hibaüzenet), akkor lehet folytatni a
konfigurálással és fordítással. A config.in.rej fájl megmarad, de
le lehet törölni.
Ha további problémák bukkannak elõ, akkor lehet, hogy rossz sorrendben
alkalmaztad a patch-okat. Ha azt mondja, hogy
`previously applied patch detected: Assume -R?', akkor lehet, hogy
az aktuális verzió elõtti patchot próbálsz
felrakni. Ha `y'-t válaszolsz, akkor megpróbálja lerontani a forrást,
és nagy valószínûséggel kudarcot vall. Így aztán szerezni kell egy teljes
vadonatúj forrást. (Lehet, hogy mindjárt ezzel kellett volna kezdeni.)
Egy patch-et visszacsinálni a `patch -R' parancsal lehet.
Ha a patch-ek tényleg nem mûködnek, akkor legjobban teszed, ha beszerzel
egy érintetlen forrást (például egy linux-x.y.z.tar.gz fájlt)
és elkezded elölrõl.
Már néhány patch után az .orig fájlok kezdenek felhalmozódni. Például
egyszer volt egy 1.1.51 forrásom, ami az 1.1.48. óta nem volt megtisztogatva.
Az .orig fájlok letörlése több mint fél megát szabadított fel. Egy
find . -name '*.orig' -exec rm -f {} ';'
elintézi. A patch azon verziói, amelyek #-al
jelölik a ``reject'' fájlokat, tildét használnak .orig kiterjesztés
helyett.
Van egy jobb módja is az .orig fájloktól való megszabadulásnak,
amihez kell a GNU xargs:
find . -name '*.orig' | xargs rm
vagy a ``hosszú de biztos'' módszer:
find . -name '*.orig' -print0 | xargs --null rm --
Linus Torvalds által terjesztette patch-eken kívül vannak másmilyenek is (nevezzük õket ``nem szabványos''-nak). Ha ezeket felrakod, akkor lehet, hogy a Linus féle patch-ek nem fognak jól mûködni, és akkor vagy visszacsinálod õket és megjavítod a forrást vagy a patchet, vagy felraksz egy új forrást, vagy a fentiek valamilyen kombinációja. Ez nagyon idegesítõ lehet, tehát ha nem akarod módosítani a forrást (kockáztatva egy nagyon rossz végkimenetelt), csináld vissza a nem szabványos patcheket mielõtt felrakod Linus-éit, vagy rakj fel egy új forrást. Így ellenõrízheted, hogy a nem szabványos patch-ek mûködnek-e még. Ha nem, akkor vagy be kell érned egy régi kernellel, vagy addig bütykölöd vagy a forrást vagy a patch-et amíg nem mûködik, vagy vársz (esetleg könyörögsz), hogy kijöjjön a patch egy új verziója.
Mennyire elterjedtek a nem szabványos patchek? Valószínûleg fogsz róluk hallani. Régebben használtam a noblink patchet a virtuális konzolokon, mert utálom a villogó kurzort. (Ezt gyakran frissítik (vagy legalábbis frissítették) a kernel új verzióihoz). De mivel a legtöbb új eszközmeghajtót betölthetõ modulnak fejlesztik, a nem szabványos patch-ek gyakorisága jelentõsen csökken.