Moderne Betriebssysteme schreiben sich eine möglichst allumfassende Anwenderfreundlichkeit auf die Fahnen. Der Nutzer soll nach Möglichkeit gar nicht mehr mit widerspenstiger Hardware und daraus resultierenden Treiber-Problemen in Berührung kommen. Zudem soll direkt nach dem Systemstart eine komplett vorkonfigurierte Arbeitsoberfläche zur Verfügung stehen. Allerdings hat dieses Ansinnen auch einen gravierenden Nachteil: Durch das Abfangen aller Eventualitäten beim Start laden die Systeme beim Booten eine ganze Reihe unnötiger Treiber und Dienste, die häufig nur Zeit kosten und wertvolle Ressourcen fressen.
Proprietären Betriebssysteme wie Windows Vista versuchen hier mit Hardware-Gimmicks wie "Readyboost" nachzubessern. Für Linux stehen einige freie Softwarepakete zur Verfügung, die den Bootvorgang ohne den Kauf kostspieliger Flashspeicher spürbar beschleunigen. Das kleine Helferlein Readahead [1] ist eines dieser Tools, erfordert aber einige Vorbereitungen. Vor allem Ubuntu, das hier als Beispiel dient, dankt das manuelle Feintuning aber mit einer deutlich schnelleren Bootzeit. Damit das Tool möglichst effizient arbeitet, gilt es jedoch, zunächst die Systemkonfiguration genau zu analysieren und überflüssigen Ballast zu entfernen.
Der SysV-Init-Prozess
Um Ansatzpunkte für eine Beschleunigung des Bootvorgangs zu finden, sollten Sie sich zunächst mit dem Startvorgang von Linux vertraut machen. Nach dem Einschalten des Rechners und dem anschließenden POST (Power On Self Test) des BIOS liest der Bootmanager (Grub oder Lilo) den Bootsektor der ersten Festplatte aus. Findet er die gewünschte Linux-Partition, so lädt er zunächst den Kernel und anschließend – sofern vorhanden – die initiale Ramdisk. Der Kernel identifiziert dabei bereits die Hardware und lädt die passenden Module; fehlen welche, lädt er die benötigten Treiber aus der initialen Ramdisk nach.
Im Anschluss mountet er die Root-Partition und führt das Programm /sbin/init aus. Dieses aktiviert zunächst alle im Verzeichnis /etc/rcS.d (Startup) aufgeführten Skripte und verzweigt danach in das vorgegebene Runlevel-Directory. Aus diesem heraus starten weitere Prozesse, wovon einige aber bald wieder stoppen, da sie nur temporär gebraucht werden oder abhängige Daemons fehlen.
Diesen SysV-Init- oder Init-V genannten Prozess nutzen in ähnlicher Form die meisten Unix-artigen Betriebssysteme. Neben dem Vorteil höchster Stabilität hat diese Technik jedoch den gravierenden Nachteil des sequenziellen Ladens von Prozessen: Ein Prozess startet erst dann, wenn der von ihm abhängige Prozess initialisiert wurde. Dadurch ergeben sich für den Prozessor Warteschleifen, die so genannten Idle-Loops. Deswegen planen die Entwickler von Ubuntu, den SysV-Init-Prozess durch einen neuen Bootprozess namens Upstart abzulösen, haben ihn bislang allerdings noch nicht konsequent in das Betriebssystem implementiert.
Ballast abwerfen
Um herauszufinden, welche Dienste auf dem Rechner laufen, bietet Ubuntu unter dem Menüpunkt System | Systemverwaltung | Dienste eine Übersicht. Sie lässt zwar bereist erste Rückschlüsse auf unnötigen Ballast zu, zeigt jedoch längst nicht alle geladenen Dienste an. Als wesentlich auskunftsfreudiger erweist sich der Boot-Up-Manager, den Sie in den Repositories von Ubuntu finden. Sie installieren ihn mit dem Aufruf sudo apt-get install bum. Danach finden Sie im Menü System | Systemverwaltung den Eintrag BootUp-Manager, mit dem Sie ihn starten.
Nach dem Aktivieren der Checkbox neben Erweitert am linken unteren Rand des Programmfensters zeigt der Boot-Up-Manager Ihnen detaillierte Informationen auch zu den beim Systemstart ausgeführten Prozessen. Sie deaktivieren überflüssige Dienste durch das Entfernen des Häkchens in der Checkbox vor dem Eintrag. Im Reiter Dienste ändern Sie darüber hinaus die Priorität der Prozesse: Das bewirkt, dass sie in der Reihenfolge früher oder später starten. Nach dem Deaktivieren überflüssiger Dienste übernehmen Sie die Änderungen durch das Anklicken des Buttons Anwenden unten links im Programmfenster. Der Boot-Up-Manager entfernt diese dann aus den entsprechenden Runlevel-Verzeichnissen (Abbildung 1).



