/usr/share/doc/HOWTO/de-html/DE-Kernel-HOWTO-5.html is in doc-linux-de 2003.10-5.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.65">
<TITLE>Linux Kernel HOWTO: Patchen des Kernels </TITLE>
<LINK HREF="DE-Kernel-HOWTO-6.html" REL=next>
<LINK HREF="DE-Kernel-HOWTO-4.html" REL=previous>
<LINK HREF="DE-Kernel-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="DE-Kernel-HOWTO-6.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-Kernel-HOWTO-4.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-Kernel-HOWTO.html#toc5"><IMG SRC="toc.png" ALT="Inhalt"></A>
<HR>
<H2><A NAME="DE-Kernel-HOWTO-kernel-patchen"></A> <A NAME="s5">5.</A> <A HREF="DE-Kernel-HOWTO.html#toc5">Patchen des Kernels </A> <!--Kernel!Patch--> <!--Patch des Kernels--></H2>
<P>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 <CODE>patch-2.0.1.gz</CODE>
besorgt, kann damit seinen Verzeichnisbaum auf die Version 2.0.1
upgraden, indem er diese Patch-Datei einspielt.</P>
<H2><A NAME="ss5.1">5.1</A> <A HREF="DE-Kernel-HOWTO.html#toc5.1">Einspielen eines Patches </A>
</H2>
<P>Wer der Sache noch nicht so recht traut, kann zunächst mit
<BLOCKQUOTE><CODE>
<PRE>
# cd /usr/src
# tar cvfz linux_old.tgz linux
</PRE>
</CODE></BLOCKQUOTE>
eine Sicherungskopie der alten Version anlegen, bevor er den neuen
Patch einspielt. Vorher empfiehlt es sich aber in jedem Fall,
ein <CODE>make clean</CODE> durchzuführen.</P>
<P>Das eigentliche »Patchen« geschieht nun durch folgende Befehle:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
# cd /usr/src
# zcat patch-2.0.1.gz | patch -p0 2>&1 | tee patch.out
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>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
<CODE>patch.out</CODE> mitprotokolliert. Diese kann man nun nach der
Zeichenkette <CODE>fail</CODE> durchsuchen, um festzustellen, ob alles glatt
gegangen ist. Eine noch einfachere Möglichkeit ist es, <CODE>patch</CODE>
mit der Option <CODE>-s</CODE> zu starten. Dadurch wird <CODE>patch</CODE>
veranlaßt, nur noch bei Fehlern Meldungen am Bildschirm auszugeben.</P>
<P>Außer durch die Ausgabe von <CODE>patch</CODE> 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 <CODE>.rej</CODE> versehen abgespeichert. Um diese
»Reject«-Dateien (zurückgewiesenen Dateien) zu finden, kann man
sich des Programmes <CODE>find</CODE> bedienen:
<BLOCKQUOTE><CODE>
<PRE>
# find . -name '*.rej' -print
</PRE>
</CODE></BLOCKQUOTE>
Dieses listet alle Dateien mit der Endung <CODE>.rej</CODE> auf, die sich im
aktuellen Verzeichnis und dessen Unterverzeichnissen befinden.</P>
<P>Sind keine Fehler aufgetreten, kann man die neue Kernelversion wie
gewohnt kompilieren.</P>
<P>Wem das zu kompliziert ist - bitte, Linux wäre nicht Linux, wenn es
dafür nicht auch eine Lösung gäbe. Im Verzeichnis
<CODE>/usr/src/linux/scripts</CODE> steht ein Shell-Skript mit dem Namen
<CODE>patch-kernel</CODE>, 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. </P>
<H2><A NAME="ss5.2">5.2</A> <A HREF="DE-Kernel-HOWTO.html#toc5.2">Was tun bei Fehlern? </A>
</H2>
<P>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 <CODE>config.in</CODE> gepatcht werden sollte. Wurde diese aber
verändert, um der eigenen Rechnerkonfiguration Rechnung zu tragen, so
fand <CODE>patch</CODE> 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.</P>
<P>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 <CODE>patch</CODE> jeweils zeichenweise vergleicht,
kann bereits ein fehlendes Leerzeichen oder eine Leerzeile zuviel ein
erfolgreiches Einspielen des Patches verhindern.</P>
<P>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 <CODE>patch</CODE> zumeist mit folgender Meldung an:
<BLOCKQUOTE><CODE>
previously applied patch detected: Assume -R?
</CODE></BLOCKQUOTE>
Antwortet man
darauf mit <CODE>y</CODE>, so versucht <CODE>patch</CODE>, 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 <CODE>patch-kernel</CODE> zu verwenden, denn dieser Fehler tritt
damit sicherlich nicht auf.</P>
<P>Hat man einen Patch versehentlich eingespielt, so kann er mit dem Befehl
<CODE>patch -R</CODE> wieder rückgängig gemacht werden.</P>
<H2><A NAME="ss5.3">5.3</A> <A HREF="DE-Kernel-HOWTO.html#toc5.3">Diese lästigen .orig Dateien... </A>
</H2>
<P><CODE>patch</CODE> legt von allen veränderten Dateien Sicherungskopien mit
der Endung <CODE>.orig</CODE> 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.</P>
<P>Auch hier hilft der <CODE>find</CODE>-Befehl, all diese Dateien auf einmal zu
löschen:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
# find . -name '*.orig' -exec rm -f {} ';'
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Alternativ kann auch das GNU-Programm <CODE>xargs</CODE> verwendet werden:</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
# find . -name '*.orig' | xargs rm
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die Benutzer von <CODE>patch-kernel</CODE> sind wiederum im Vorteil, denn
dieses Skript löscht automatisch alle <CODE>.orig</CODE>-Dateien.</P>
<H2><A NAME="ss5.4">5.4</A> <A HREF="DE-Kernel-HOWTO.html#toc5.4">Andere Patches </A>
</H2>
<P>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 (<CODE>patch -R</CODE>)
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.</P>
<P>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.</P>
<HR>
<A HREF="DE-Kernel-HOWTO-6.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-Kernel-HOWTO-4.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-Kernel-HOWTO.html#toc5"><IMG SRC="toc.png" ALT="Inhalt"></A>
</BODY>
</HTML>
|