Inhalt

5. Patchen des Kernels

Die Quelldateien des Linux-Kernels sind mittlerweile mit immerhin 6 MB sehr umfangreich und es wäre unbequem, sich mit jeder neuen Kernelversion die kompletten Dateien erneut zu besorgen. Stattdessen werden nur diejenigen Teile, die sich verändert haben, in Form eines inkrementellen Patches verbreitet. Wer also z.B. die vollständigen Kernel-Quellen der Version 2.0.0 besitzt und sich die Datei patch-2.0.1.gz besorgt, kann damit seinen Verzeichnisbaum auf die Version 2.0.1 upgraden, indem er diese Patch-Datei einspielt.

5.1 Einspielen eines Patches

Wer der Sache noch nicht so recht traut, kann zunächst mit

# cd /usr/src
# tar cvfz linux_old.tgz linux
eine Sicherungskopie der alten Version anlegen, bevor er den neuen Patch einspielt. Vorher empfiehlt es sich aber in jedem Fall, ein make clean durchzuführen.

Das eigentliche »Patchen« geschieht nun durch folgende Befehle:

# cd /usr/src
# zcat patch-2.0.1.gz | patch -p0 2>&1 | tee patch.out

Jetzt werden jede Menge Meldungen über den Bildschirm rasen über »hunks«, die eingespielt werden, und ob das erfolgreich war. Da es recht schwierig ist, in diesem vorbeirasenden Wirrwarr Fehlermeldungen zu entdecken, wurden im Beispiel die gesamten Meldungen zusätzlich in der Datei patch.out mitprotokolliert. Diese kann man nun nach der Zeichenkette fail durchsuchen, um festzustellen, ob alles glatt gegangen ist. Eine noch einfachere Möglichkeit ist es, patch mit der Option -s zu starten. Dadurch wird patch veranlaßt, nur noch bei Fehlern Meldungen am Bildschirm auszugeben.

Außer durch die Ausgabe von patch lassen sich gescheiterte Patch-Versuche auch folgendermaßen auffinden: Schlägt ein Patch-Versuch fehl, so werden die beanstandeten Abschnitte der zu patchenden Datei mit der Endung .rej versehen abgespeichert. Um diese »Reject«-Dateien (zurückgewiesenen Dateien) zu finden, kann man sich des Programmes find bedienen:

# find .  -name '*.rej' -print
Dieses listet alle Dateien mit der Endung .rej auf, die sich im aktuellen Verzeichnis und dessen Unterverzeichnissen befinden.

Sind keine Fehler aufgetreten, kann man die neue Kernelversion wie gewohnt kompilieren.

Wem das zu kompliziert ist - bitte, Linux wäre nicht Linux, wenn es dafür nicht auch eine Lösung gäbe. Im Verzeichnis /usr/src/linux/scripts steht ein Shell-Skript mit dem Namen patch-kernel, welches einem fast alle Arbeit abnimmt. Es erkennt automatisch die Versionsnummer der momentan installierten Kernel-Quellen und sucht dann im aktuellen Verzeichnis nach Patch-Dateien mit höheren Versionsnummern als der installierte Kernel. Diese werden dann automatisch eine nach der anderen eingespielt. Tritt ein Fehler auf, bricht das Skript selbstverständlich ab.

5.2 Was tun bei Fehlern?

Wer niemals selber in den Kernel-Quellen herumeditiert, für den sollten die Patches eigentlich immer ohne Probleme einspielbar sein. Lediglich in alten Kernel-Versionen gab es ein Problem, wenn eine Datei mit dem Namen config.in gepatcht werden sollte. Wurde diese aber verändert, um der eigenen Rechnerkonfiguration Rechnung zu tragen, so fand patch sich in dieser Datei nicht mehr zurecht und konnte den Patch nicht einspielen. Diese Probleme sind aber inzwischen berücksichtigt und sollten nicht mehr auftreten.

Kommt es dennoch einmal soweit, sollte man als erstes die »Reject«-Datei ansehen und sie dann mit der zu patchenden Datei vergleichen. Oft weicht die Originaldatei nur geringfügig von der Form ab, die die Patch-Datei erwartet. Da patch jeweils zeichenweise vergleicht, kann bereits ein fehlendes Leerzeichen oder eine Leerzeile zuviel ein erfolgreiches Einspielen des Patches verhindern.

Eine letzte mögliche Fehlerquelle besteht darin, daß man einen Patch außerhalb der Reihe einspielen will, also z.B. einen mit einer geringeren Versionsnummer als die bereits vorhandenen Kernel-Quellen. Dann hält patch zumeist mit folgender Meldung an:

previously applied patch detected: Assume -R?
Antwortet man darauf mit y, so versucht patch, die vorhandenen Quellen wieder auf den alten Stand zurückzusetzen, wird dabei aber ziemlich sicher scheitern. Dann wird man kaum umhinkommen, sich die vollständigen Kernel-Quellen neu zu besorgen. Ein Grund mehr also, das Skript patch-kernel zu verwenden, denn dieser Fehler tritt damit sicherlich nicht auf.

Hat man einen Patch versehentlich eingespielt, so kann er mit dem Befehl patch -R wieder rückgängig gemacht werden.

5.3 Diese lästigen .orig Dateien...

patch legt von allen veränderten Dateien Sicherungskopien mit der Endung .orig an. Diese nehmen bereits nach einigen eingespielten Patches einen nicht unerheblichen Platz ein; von 1.1.48 bis 1.1.51 waren es über ein halbes MB.

Auch hier hilft der find-Befehl, all diese Dateien auf einmal zu löschen:

# find .  -name '*.orig' -exec rm -f {} ';'

Alternativ kann auch das GNU-Programm xargs verwendet werden:

# find .  -name '*.orig' | xargs rm

Die Benutzer von patch-kernel sind wiederum im Vorteil, denn dieses Skript löscht automatisch alle .orig-Dateien.

5.4 Andere Patches

Es gibt außer den von Linus verwalteten Patches auch noch andere, nicht zur Standard-Kerneldistribution zugehörige Patches. Diese sind meist für spezielle Hardware und befinden sich oft noch im experimentellen Stadium. Viele dieser Patches werden vielleicht in späteren Kernel-Versionen in die Standard-Distribution aufgenommen. Quota und Unterstützung für den Iomega ZIP-Drive sind diesen Weg gegangen. Solange sie aber noch »exotisch« sind, können diese Patches dazu führen, daß die Standard-Patches von Linus nicht mehr fehlerfrei eingespielt werden können. In diesem Fall hat man dann nur die Möglichkeit, den Patch vor dem Kernel-Upgrade rückgängig zu machen, sich komplett neue Kernel-Quellen zu besorgen oder zu versuchen, die fehlgeschlagenen Patches von Hand zu korrigieren. Dies kann auf Dauer recht frustrierend sein. Wer nicht mit jedem neuen Kernel in den Quellen herumsuchen will, der sollte den externen Patch rückgängig machen (patch -R) bevor er den offiziellen Patch einspielt, oder gleich die volle Kernel-Version neu installieren. Erst danach kann man sehen, ob sich der inoffizielle Patch in die neuen Kernel-Quellen einspielen läßt. Ist dies nicht der Fall, kann man entweder mit dem alten Kernel weiterarbeiten und auf ein Upgrade verzichten, bis jemand anders diesen Patch an die neue Kernelversion angepaßt hat, oder aber selber in den Quellen und dem Patch herumsuchen und selber versuchen, ihn zum Laufen zu bekommen.

Wie viele dieser inoffiziellen Patches gibt es? Nun, es tauchen immer wieder welche auf, und wer die Newsgroups verfolgt, wird bald über sie stolpern. Auf der anderen Seite bieten die neuen Kernels durch die ladbaren Module eine viel elegantere Methode, um neue Treiber und ähnliches in den Kernel einzubinden, ohne daß dabei die Originalquellen verändert werden müßten. Aus diesem Grund wird die Anzahl der wirklichen Patches mit der Zeit zurückgehen.


Inhalt