1 files changed, 61 insertions, 61 deletions
diff --git a/linux-basics/boot-process/handout_boot-process_de.tex b/linux-basics/boot-process/handout_boot-process_de.tex
index 0b36a61..40b62c8 100644
--- a/linux-basics/boot-process/handout_boot-process_de.tex
+++ b/linux-basics/boot-process/handout_boot-process_de.tex
@@ -4,99 +4,99 @@
 
 \subsubsection{Aufgaben des Bootloaders}
 
-Hauptaufgabe des Bootloaders ist die rudimentäre Initialisierung der
+Hauptaufgabe des Bootloaders ist die rudiment"are Initialisierung der
 Hardware, so dass mindestens das RAM benutzt werden kann. Dazu ist auf den
 meisten Boards die Initialisierung eines (S)DRAM-Controllers erforderlich.
 
-Soll das Board aus einem NAND-Flash booten können, so muss auch dessen
+Soll das Board aus einem NAND-Flash booten k"onnen, so muss auch dessen
 Controller initialisiert werden.
 
 Viele Prozessoren beinhalten PLLs, die aus dem Prozessortakt andere Clocks
-für verschiedene Peripherie-Einheiten generieren. Auch diese müssen
+f"ur verschiedene Peripherie-Einheiten generieren. Auch diese m"ussen
 initialisiert werden.
 
-Anschließend müssen die Peripherie-Einheiten initialisiert werden, die
-der Bootloader benötigt, um den Kernel laden zu können. Für TFTP-Boot wäre
+Anschlie\ss end m"ussen die Peripherie-Einheiten initialisiert werden, die
+der Bootloader ben"otigt, um den Kernel laden zu k"onnen. F"ur TFTP-Boot w"are
 dies beispielsweise der Netzwerk-Chip.
 
-Meist ist es auch erwünscht, dass der Bootloader eine serielle Schnittstelle
-initialisiert. Dies ermöglicht nicht nur hilfreiche Meldungen aus dem
-Bootloader, es ermöglicht auch dem Kernel bereits im frühen Stadium des
+Meist ist es auch erw"unscht, dass der Bootloader eine serielle Schnittstelle
+initialisiert. Dies erm"oglicht nicht nur hilfreiche Meldungen aus dem
+Bootloader, es erm"oglicht auch dem Kernel bereits im fr"uhen Stadium des
 Bootvorgangs die Ausgabe von Meldungen (und nicht erst nach dem Laden seines
 UART-Treibers und der Konsole). Viele Bootloader bieten ausserdem eine Art
 Monitorprogramm, mit dem man mit Hilfe eines Terminalprogramms interaktiv
-Einstellungen ändern oder Speicher lesen und schreiben kann.
+Einstellungen "andern oder Speicher lesen und schreiben kann.
 
-Nach erfolgreicher Initialisierung lädt der Bootloader von der gewählten
+Nach erfolgreicher Initialisierung l"adt der Bootloader von der gew"ahlten
 Quelle das komprimierte Kernel-Image ins RAM. Am Anfang eines komprimierten
-zImage steht (natürlich unkomprimiert) der Dekompressor-Code. Der Bootloader
+zImage steht (nat"urlich unkomprimiert) der Dekompressor-Code. Der Bootloader
 springt diese Adresse an und hat damit seine Arbeit beendet. Alles weitere
-läuft im Kernel ab.
+l"auft im Kernel ab.
 
-\subsubsection{Gängige Bootloader}
+\subsubsection{G"angige Bootloader}
 
 Die Wahl des Bootloaders ist weitgehend eine Geschmacksfrage. Die
 verbreiteten Bootloader U-Boot und Redboot bieten im Wesentlichen die gleiche
-Funktionalität. Die Bedienung unterscheidet sich zwar deutlich, aber der
-ohnehin nötige Einarbeitungsaufwand dürfte bei beiden etwa gleich sein.
+Funktionalit"at. Die Bedienung unterscheidet sich zwar deutlich, aber der
+ohnehin n"otige Einarbeitungsaufwand d"urfte bei beiden etwa gleich sein.
 
 Auch beim Kompilieren dieser Bootloader sind die Unterschiede nicht gross.
 Beide zeichnen sich durch schwer durchschaubaren Sourcecode und ein
 eigenwilliges Buildsystem aus.
 
-Es gibt aber auch die Möglichkeit, ganz auf einen derartigen Bootloader zu
+Es gibt aber auch die M"oglichkeit, ganz auf einen derartigen Bootloader zu
 verzichten. Statt dessen verwendet man einen minimalen \emph{Initial Program
-Loader (IPL)}, der lediglich die rudimentären Initialisierungsaufgaben
-erfüllt und danach einen minimalen Bootkernel lädt und ausführt. Dieser
-lädt wiederum den eigentlichen Produktiv-Kernel nach.
+Loader (IPL)}, der lediglich die rudiment"aren Initialisierungsaufgaben
+erf"ullt und danach einen minimalen Bootkernel l"adt und ausf"uhrt. Dieser
+l"adt wiederum den eigentlichen Produktiv-Kernel nach.
 
-Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilität und die
+Vorteile der letztgenannten Vorgehensweise sind hohe Flexibilit"at und die
 Tatsache, dass man im Bootkernel schon nach wenigen hundert Millisekunden
-jeden gewünschten Treiber zur Verfügung hat. Dadurch können in elegante
+jeden gew"unschten Treiber zur Verf"ugung hat. Dadurch k"onnen in elegante
 Weise Anforderungen wie das Anzeigen eines Bildes auf einem TFT (500
-Millisekunden nach dem Einschalten) gelöst werden. Wollte man dies mit
-einem der oben erwähnten Bootloader erreichen, müsste man zunächst die
-für das TFT benötigten Treiber vom Kernel in den Bootloader portieren und
-dort zum Laufen bringen. Ähnliches gilt für andere gängige Forderungen,
+Millisekunden nach dem Einschalten) gel"ost werden. Wollte man dies mit
+einem der oben erw"ahnten Bootloader erreichen, m"usste man zun"achst die
+f"ur das TFT ben"otigten Treiber vom Kernel in den Bootloader portieren und
+dort zum Laufen bringen. "Ahnliches gilt f"ur andere g"angige Forderungen,
 wie das Booten von einem USB-Stick.
 
-Es erscheint als überflüssige Mühe, einen im Kernel bereits
-funktionierenden Treiber in den Bootloader portieren zu müssen. Mit IPL und
-Bootkernel sind ausserdem komplexe Aufgaben während des Bootvorgangs,
+Es erscheint als "uberfl"ussige M"uhe, einen im Kernel bereits
+funktionierenden Treiber in den Bootloader portieren zu m"ussen. Mit IPL und
+Bootkernel sind ausserdem komplexe Aufgaben w"ahrend des Bootvorgangs,
 beispielsweise automatisierte und sichere Firmware-Updates leicht
 realisierbar.
 
 \subsubsection{Bootprobleme: Im Bootloader}
 
-Während der Entwicklungsphase sind Probleme im Bootloader besonders
-unangenehm. Falls dieser bereits abstürzt, ehe er die serielle Schnittstelle
+W"ahrend der Entwicklungsphase sind Probleme im Bootloader besonders
+unangenehm. Falls dieser bereits abst"urzt, ehe er die serielle Schnittstelle
 initialisieren konnte, so sieht man schlichtweg gar nichts. Aber auch bei
-späteren Fehlern ist der Entwicklungszyklus mühsam, da man den Bootloader
-meist erst mit einem JTAG-Adapter oder ähnlichen Werkzeugen ins Flash des
-Boards befördern muss, bevor man den nächsten Versuch machen kann. Bei
-Änderungen am Bootloader-Code ist daher große Sorgfalt geboten. Wenn möglich,
-sollte man zu zweit an solchem Code arbeiten und sich ständig gegenseitig
+sp"ateren Fehlern ist der Entwicklungszyklus m"uhsam, da man den Bootloader
+meist erst mit einem JTAG-Adapter oder "ahnlichen Werkzeugen ins Flash des
+Boards bef"ordern muss, bevor man den n"achsten Versuch machen kann. Bei
+"Anderungen am Bootloader-Code ist daher gro\ss e Sorgfalt geboten. Wenn m"oglich,
+sollte man zu zweit an solchem Code arbeiten und sich st"andig gegenseitig
 kontrollieren.
 
-Häufige Problemquellen im Bootloader sind beispielsweise:
+H"aufige Problemquellen im Bootloader sind beispielsweise:
 
 \begin{itemize} 
 \item Der Bootloader wurde nicht korrekt ins Flash geschrieben. In einem Fall
 	passierte dies beispielsweise, wenn der Compiler ein Binary mit
-	ungerader Länge erzeugte. Aber auch falsche Konfiguration des JTAGer
-	kann zu solchen Problemen führen.
-\item Im Bootloader wurden die Timings für Bus-Schnittstellen wie RAM oder
+	ungerader L"ange erzeugte. Aber auch falsche Konfiguration des JTAGer
+	kann zu solchen Problemen f"uhren.
+\item Im Bootloader wurden die Timings f"ur Bus-Schnittstellen wie RAM oder
 	Flash nicht korrekt eingestellt. Gerade wenn die Timings nicht ganz
 	falsch, sondern nur grenzwertig sind, kann es zu schwer
 	reproduzierbaren Bootproblemen kommen.
-\item Die Ladeadresse für den Kernel ist nicht korrekt. Bei manchen
+\item Die Ladeadresse f"ur den Kernel ist nicht korrekt. Bei manchen
 	Bootloadern kann es leicht zu Verwechslungen zwischen physikalischen
 	und virtuellen Adressen kommen. Weder U-Boot noch Redboot melden
-	einen Fehler, wenn man den Kernel an eine Adresse lädt, an der
-	sich überhaupt kein RAM befindet...
-\item Beim Laden des Kernels per TFTP kann es zusätzlich weitere Probleme
-	geben, die mit dem Netzwerk zusammenhängen. Diese reichen von falsch
-	aufgesetzten TFTP-Servern über falsch konfigurierte DHCP-Server oder
+	einen Fehler, wenn man den Kernel an eine Adresse l"adt, an der
+	sich "uberhaupt kein RAM befindet...
+\item Beim Laden des Kernels per TFTP kann es zus"atzlich weitere Probleme
+	geben, die mit dem Netzwerk zusammenh"angen. Diese reichen von falsch
+	aufgesetzten TFTP-Servern "uber falsch konfigurierte DHCP-Server oder
 	falschen IP-Adressen bis hin zu Treiber- oder Hardware-Problemen.
 \end{itemize} 
 
@@ -104,46 +104,46 @@ Häufige Problemquellen im Bootloader sind beispielsweise:
 
 Bootprobleme im Kernel sind vergleichsweise einfach zu finden, sobald man
 eine Konsole auf der seriellen Schnittstelle hat. Der Kernel gibt meist recht
-aussagekräftige Fehlermeldungen und bietet viele zusätzliche Debug-Funktionen,
+aussagekr"aftige Fehlermeldungen und bietet viele zus"atzliche Debug-Funktionen,
 die man in der Kernel-Konfiguration aktivieren kann. Falls sich der Kernel
-bereits früher aufhängt, so dass man nach der Meldung
+bereits fr"uher aufh"angt, so dass man nach der Meldung
 
 \cmd{Uncompressing Linux.....}
 
-überhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zunächst
-überprüfen, ob die im Bootloader vorgegebene Commandline für den Kernel
-korrekt ist, insbesondere die Einstellung der für die Konsole verwendeten
+"uberhaupt nichts mehr sieht, dann wird es schwieriger. Man sollte zun"achst
+"uberpr"ufen, ob die im Bootloader vorgegebene Commandline f"ur den Kernel
+korrekt ist, insbesondere die Einstellung der f"ur die Konsole verwendeten
 seriellen Schnittstelle (\cmd{console=tty...}).
 
-Ein weiteres gängiges Problem ist, dass der Kernel am Ende des Bootvorgangs
+Ein weiteres g"angiges Problem ist, dass der Kernel am Ende des Bootvorgangs
 kein Root-Filesystem mounten kann. Dies kann daran liegen, dass man bei der
-Kernelkonfiguration vergessen hat, dass \emph{alle} für das Rootfs nötigen
-Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein müssen
+Kernelkonfiguration vergessen hat, dass \emph{alle} f"ur das Rootfs n"otigen
+Hardware- und Dateisystem-Treiber in den Kernel einkompiliert sein m"ussen
 und nicht etwa als Module gebaut wurden. Bei Medien, die erst detektiert
-werden müssen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht
+werden m"ussen (z.B. SD-Karten) kann es passieren, dass das Medium noch nicht
 bereit ist, wenn der Kernel es mounten will. In diesem Fall hilft der
 Parameter \cmd{rootwait}.
 
 Falls der Kernel zwar das Rootfs mounten kann, aber danach mit einer
-Fehlermeldung hängen bleibt, anstatt \cmd{/sbin/init} zu starten, dann
+Fehlermeldung h"angen bleibt, anstatt \cmd{/sbin/init} zu starten, dann
 liegt dies oft an fehlenden Device-Nodes im Verzeichnis \cmd{/dev}.
-Überprüfen Sie dies.
+"Uberpr"ufen Sie dies.
 
 \subsubsection{Bootprobleme: In den Startskripten}
 
 Wenn der Kernel erfolgreich das Rootfs mounten und \cmd{/sbin/init} starten
 konnte, wird letzteres versuchen, die in \cmd{/etc/inittab} angegebenen
-Anweisungen auszuführen. Dies ist normalerweise zunächst der Aufruf eines
+Anweisungen auszuf"uhren. Dies ist normalerweise zun"achst der Aufruf eines
 Startskripts, das in der Regel weitere Skripte und Programme aufruft. Je
 nach Art der aufgerufenen Programme kann es hier zu weiteren Problemen
-kommen. Dazu gehören etwa fehlerhafte Konfigurationsdateien, fehlende
-Device-Nodes oder Ähnliches.  
+kommen. Dazu geh"oren etwa fehlerhafte Konfigurationsdateien, fehlende
+Device-Nodes oder "Ahnliches.  
 
 Ausserdem kommt es bei Startskripten vor, dass diese nicht auf jede Situation
 sauber und fehlertolerant reagieren. Man sollte vermeiden, dass sich das
-Skript zur Konfiguration des Netzwerks aufhängt, wenn kein DHCP-Server
+Skript zur Konfiguration des Netzwerks aufh"angt, wenn kein DHCP-Server
 gefunden wurde oder kein Netzwerkkabel eingesteckt ist. Des weiteren sollte
-das Skript selber erkennen, wenn über die Netzwerkschnittstelle das Rootfs
+das Skript selber erkennen, wenn "uber die Netzwerkschnittstelle das Rootfs
 per NFS gemountet wurde, und dann eine Neukonfiguration tunlichst unterlassen.
 
 \input{tailhandout}