Statt nacheinander wie beim Staffellauf lassen alternative Bootsysteme viele Prozesse parallel anlaufen: ein Massenstart. Dabei benötigen sie manchmal nur die Hälfte der Zeit bis ins Ziel und bieten sich zudem oft noch als Servicemanager an, die ihre Klienten auch nach dem Start betreuen.
Zum Starten braucht ein Rechner Software. Um an Software zu kommen, muss er gestartet sein. Das klassische Henne-Ei-Problem. Jeder Rechner löst es, noch ehe der Benutzer den Finger vom Netzschalter nehmen kann. Und zwar mit Hilfe des Bios. Auf Unix-artigen Systemen gibt es den Startschuss zu einem Staffellauf, dessen Ziel der einsatzbereite Rechner ist. Inzwischen nehmen auf dem Weg dorthin jüngere Konkurrenten dem altgedienten System-V-Init wertvolle Sekunden ab. Zudem sind manche nicht nur schneller, sondern auch vielseitiger. Lohnt ein Wechsel?
Der Ausgangspunkt ist in jedem Fall das Bios. Das Bios kann auch Boot-ROM (Macintosh) heißen oder etwa Open-Boot-Environment (SPARC) - trotz der verschiedenen Namen sind die Funktionen im Prinzip identisch. Die Bootsoftware hat die stromlose Zeit seit dem letzten Shutdown in einem nicht-flüchtigen NVRAM-Speicher überlebt und wird durch die Energiezufuhr beim Einschalten wieder aktiv.
Da sie selbst nur sehr beschränkte Fähigkeiten besitzt, kümmert sie sich sofort um Verstärkung. In einer voreingestellten Reihenfolge sucht sie zunächst die verfügbaren Massenspeicher ab, findet in der Mehrzahl der Fälle eine Festplatte und liest deren erste 512 Byte, den so genannten Master Boot Record (MBR).
Der MBR enthält nämlich einen unverzichtbaren Helfershelfer, ein kleines Programm, das die im selben Speicherbereich abgelegte Partitionstabelle nach einer bootbaren Partition durchforstet. Ist die gefunden, lädt das Bios aus ihrem ersten Sektor den ersten Teil des Bootloaders, der sich danach selbst an den Haaren aus dem Sumpf zieht, indem er seinen eigenen zweiten Teil von der Festplatte nachlädt. Im Hauptspeicher angekommen holt er den großen Bruder des Bios, den Kernel des Betriebssystems, dorthin nach.
Prinzipiell könnte man den Kernel auch direkt durch das Bios laden lassen. Tatsächlich gibt es mit Linuxbios [1] ein solches Projekt. Derzeit unterstützt es aber noch nicht allzu viele Motherboards.
Kaum geladen übernimmt der Kernel Stab und Kommando, denn die Staffel ist noch lange nicht im Ziel: Nun gilt es, das laufende System zu initialisieren und alle erforderlichen Dienste zu aktivieren. Der Kernel delegiert diesen Schritt an den ersten Prozess, den er seinerseits mit der ID 1 ins Rennen schickt, den Urvater aller weiteren Prozesse: »init«. Wie »init« genau vorgeht, hängt ein wenig vom Unix-Derivat ab: Klassische BSD-Systeme sammelten alle Arbeitsanweisungen für »init« in einem einzigen Shellskript, die jüngeren BSD-Abkömmlinge verwenden wie alle System-V-Verwandten einen ganzen Satz aufeinander aufbauender Skripte.
System-V-Init fasst diese Skripte in nummerierten Verzeichnissen zusammen. Hat der Rechner jeweils einen dieser Ordnerinhalte komplett abgearbeitet, gelangt er in einen bestimmten Betriebszustand, auch als Runlevel bezeichnet. In der Regel entspricht Runlevel 1 dem Einzelnutzerbetrieb ohne Netzwerkkonfiguration. In Runlevel 2 kommt das Netzwerk hinzu, in Runlevel 3 der Mehrbenutzerbetrieb, in Runlevel 5 die grafische Oberfläche. Ein Wechsel in Runlevel 0 entspricht einem Shutdown, der Übergang zu Runlevel 6 einem Reboot. Eine Sonderstellung nimmt der Runlevel S ein, in dem nur die allernötigsten Dienste aktiv sind. Dieser Systemzustand wird hin und wieder für Wartungsarbeiten gebraucht.
Welchen Runlevel »init« ansteuern soll, kann ihm der Kernel beim Aufruf als Parameter übergeben. Ansonsten orientiert es sich an einer Tabelle im File »/etc/inittab«. Dort ist nicht nur der Default-Runlevel notiert, sondern beispielsweise auch der Name des Skriptverzeichnisses eines jeden Runlevels.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
