Verder Terug Inhoud

6. Patchen van de kernel

6.1 Toepassen van een patch

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' -print
drukt 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.

6.2 Als er iets fout gaat

(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.rej
en 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).

6.3 De .orig bestanden zien kwijt te raken

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 rm
of de ``heel veilige maar een beetje uitgebreidere'' methode:
    find . -name '*.orig' -print0 | xargs --null rm --

6.4 Andere patches

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.


Verder Terug Inhoud