Periodieke upgrades van de kernel worden als patches gedistribueerd.
Als je bijvoorbeeld versie 1.1.45 hebt, en je merkt dat er een
`patch46.gz
' voor is, betekent het dat je naar versie
1.1.46 kunt upgraden door toepassing van de patch.
Misschien wil je eerst een backup van de sourcetree maken
(`make clean
' en vervolgens
`cd /usr/src; tar zcvf old-tree.tar.gz linux
'
zal een gecomprimeerd tar-archief voor je maken).
Dus, verdergaand met het voorbeeld van hierboven, laten we ervan uitgaan
dat je `patch46.gz
' in /usr/src
hebt. cd
naar
/usr/src
en doe een `zcat patch46.gz | patch -p0
'
(of `patch -p0 < patch46
'
als de patch niet is gecomprimeerd). Je zult van alles voorbij zien
vliegen (of fladderen als je systeem zo langzaam is) om je te laten
weten dat het aan het proberen is om brokken toe te passen en of het
daarin slaagt of niet. Meestal gaan deze acties te snel voorbij om
ze te kunnen lezen, en ben je er niet helemaal zeker van of het wel of
niet werkte, dus misschien wil je de
-s
flag aan patch
opgeven, welke patch
aangeeft
alleen de foutmeldingen te rapporteren (je krijgt niet zoveel als bij het
``hé, mijn computer doet eindelijk eens wat voor de verandering!''
gevoel, maar het kan zijn dat je hier de voorkeur aan geeft ..).
Om die onderdelen te bekijken die misschien niet zo soepel zijn verlopen,
cd je naar /usr/src/linux
en
zoek je naar bestanden met een .rej
extensie.
Een aantal versies van patch
(oudere versies welke kunnen zijn gecompileerd met een inferieur
bestandssysteem) laat de verwerpingen met een #
extensie achter.
Je kunt `find
' gebruiken om ze voor je op te sporen;
find . -name '*.rej' -printdrukt alle bestanden in de huidige directory of elke subdirectory met de
.rej
extensie naar standaarduitvoer af.
Als alles goed ging, doe je een `make clean
', `config
',
en `dep
' zoals in sectie 3 en 4 werd beschreven.
Er zijn heel wat opties voor het patch
commando. Zoals hierboven
genoemd, zal patch -s
alle berichten behalve de foutmeldingen
onderdrukken. Als je je kernelsource op een andere plaats dan
/usr/src/linux
bewaart, zal er met patch -p1
(in die directory) een zuivere patch worden uitgevoerd.
Andere patch
opties zijn goed gedocumenteerd in de manual page.
(Opmerking: deze sectie refereert voornamelijk naar nogal oude kernels)
Het meest voorkomende probleem dat zich voordeed was wanneer een patch
een bestand met de naam `config.in
' wijzigde en het er niet helemaal
goed uitzag, omdat je de opties wijzigde om aan je computer aan te passen.
Dit is verholpen, maar het kan zijn dat je het met een oudere release
nog aan zult treffen.
Bekijk het bestand config.in.rej
om het te herstellen, en zie
wat er van de originele patch over is gebleven.
Kenmerkend is dat de wijzigingen aan het begin van de regel
met een `+
' en een `-
' worden gemarkeerd.
Kijk naar de regels die erdoor worden omsloten, en denk eraan terug of ze
met `y
' of `n
' werden ingesteld. Wijzig nu
je config.in
, en verander daar waar van toepassing de
`y
' in een `n
' en de `n
' in een `y
'
Tik in
patch -p0 < config.in.rejen als het rapporteert dat het succesvol was (zonder gebreken), dan kun je verdergaan met de configuratie en compilatie. Het bestand
config.in.rej
blijft behouden, maar je kunt het
verwijderen.
Als je verdere problemen tegenkomt, kan het zijn dat je een patch in de
verkeerde volgorde hebt geïnstalleerd.
Als patch de melding `previously applied patch detected: Assume
-R?
' geeft, ben je waarschijnlijk aan het proberen om een patch
toe te passen welke lager is dan het huidige versienummer;
als je `y
' antwoordt, zal het proberen je source te degraderen,
en zal hier waarschijnlijk niet in slagen; dus je zult een volledige nieuwe
versie van de source tree nodig hebben
(wat in eerste instantie niet eens zo'n slecht idee zou zijn geweest).
Om een patch achteraf te verwijderen, gebruik je
`patch -R
' op de originele patch
(het toepassen ongedaan maken).
Als patches echt verkeerd blijken te zijn, kun je het beste
opnieuw beginnen met een nog onaangetaste source tree (bijvoorbeeld
vanuit één van de linux-x.y.z.tar.gz
bestanden).
Na slechts een paar patches, zullen de .orig
bestanden zich beginnen
op te stapelen. Een 1.1.51 tree die ik bijvoorbeeld ooit had, was voor het
laatst bij 1.1.48 opgeschoond.
Het verwijderen van de .orig bestanden bespaarde me meer dan een halve meg.
find . -name '*.orig' -exec rm -f {} ';'zal dit voor je regelen. Versies van
patch
die
#
gebruiken voor verwerpingen, maken gebruik van een tilde
in plaats van .orig
.
Er zijn betere manieren om af te geraken van de .orig
bestanden,
die afhankelijk zijn van GNU xargs
:
find . -name '*.orig' | xargs rmof de ``heel veilige maar een beetje uitgebreidere'' methode:
find . -name '*.orig' -print0 | xargs --null rm --
Er zijn andere patches (Ik zal ze ``nietstandaard'' noemen) dan die Linus distribueert. Als je deze toepast, kan het zijn dat de patches van Linux niet correct werken en dan zul je ze alsnog moeten verwijderen, de source of de patch moeten herstellen, een nieuwe sourcetree moeten installeren, of een combinatie van het bovenstaande. Dit kan erg frustrerend worden, dus als je de source niet wilt wijzigen (met de kans op een zeer slechte uitkomst), verwijder dan de niet-standaard patches voordat je die van Linux toepast, of installeer gewoon een nieuwe tree. Vervolgens kun je zien of de niet-standaard patches nog steeds werken. Als dat niet zo is, zit je vast aan een oude kernel, het spelen met de patch of de source om het aan het werk te krijgen, of zul je moeten wachten (of bedelen) tot er een nieuwe versie van de patch uitkomt.
Hoe algemeen zijn de patches die zich niet in de standaarddistributie bevinden? Je zult waarschijnlijk van ze horen. Ik was gewend de noblink patch voor mijn virtuele consoles te gebruiken, omdat ik een hekel heb aan knipperende cursors. (Deze patch wordt (of tenminste werd) vaak bijgewerkt voor nieuwe kernelreleases). Van de meeste nieuwe devicedrivers, die als laadbare modules worden ontwikkeld, is de frequentie van "niet-standaard" patches echter aanmerkelijk aan het afnemen.