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.
Wer der Sache noch nicht so recht traut, kann zunächst mit
# cd /usr/src
# tar cvfz linux_old.tgz linux
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
.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.
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?
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.
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.
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.