101.2 Lektion 1

Die Prozeduren, die von x86-Maschinen ausgeführt werden, um den Bootloader zu starten, unterschieden sich je nachdem ob BIOS oder UEFI verwendet wird. Das BIOS, kurz für Basic Input/Output System, ist ein Programm, das in einem nichtflüchtigen Speicherchip auf der Hauptplatine gespeichert ist und jedes Mal ausgeführt wird, wenn der Computer eingeschaltet wird. Diese Art von Programm wird Firmware genannt und sein Speicherort ist von den anderen Speichergeräten, die das System möglicherweise hat, getrennt. Das BIOS geht davon aus, dass die ersten 440 Bytes des ersten Speichergeräts — entsprechend der im BIOS-Konfigurationsprogramm festgelegten Reihenfolge — die erste Stufe des Bootloaders (auch bootstrap genannt) sind. Die ersten 512 Bytes eines Speichergeräts werden bei Speichergeräten mit dem Standard-DOS-Partitionsschema als MBR (Master Boot Record) bezeichnet und enthalten neben der ersten Stufe des Bootloaders auch die Partitionstabelle. Wenn der MBR nicht die richtigen Daten enthält, kann das System nicht booten, es sei denn, es wird eine alternative Methode verwendet.

Im Allgemeinen sind die Vorbereitungsschritte zum Booten eines mit BIOS ausgestatteten Systems folgende:

UEFI, kurz für Unified Extensible Firmware Interface, unterscheidet sich in einigen wesentlichen Punkten vom BIOS. Wie das BIOS ist auch das UEFI eine Firmware, aber es kann Partitionen identifizieren und eine Vielzahl von Dateisystemen lesen, die sich darin befinden. UEFI ist nicht auf den MBR angewiesen und berücksichtigt nur die Einstellungen, die in ihrem nichtflüchtigen Speicher (NVRAM) gespeichert sind, der an die Hauptplatine angeschlossen ist. Diese Definitionen geben den Speicherort der UEFI-kompatiblen Programme, EFI-Anwendungen genannt, an, die automatisch ausgeführt oder über ein Bootmenü aufgerufen werden. EFI-Anwendungen können Bootloader, Betriebssystemselektoren, Werkzeuge für Systemdiagnose und -reparatur usw. sein. Sie müssen sich in einer konventionellen Speichergerätepartition und in einem kompatiblen Dateisystem befinden. Die standardmäßigen kompatiblen Dateisysteme sind FAT12, FAT16 und FAT32 für Blockgeräte und ISO-9660 für optische Medien. Dieser Ansatz ermöglicht die Implementierung viel ausgefeilterer Werkzeuge, welche mit einem BIOS möglich sind.

Die Partition, welche die EFI-Anwendungen enthält, wird EFI-System-Partition oder einfach ESP genannt. Diese Partition darf nicht mit anderen Systemdateisystemen, wie dem Root-Dateisystem oder Benutzerdatendateisystemen, geteilt werden. Das EFI-Verzeichnis in der ESP-Partition enthält die Anwendungen, auf welche die im NVRAM gespeicherten Einträge verweisen.

Im Allgemeinen sind die vor dem Betriebssystemstart durchzuführenden Schritte auf einem UEFI-System:

Der UEFI-Standard unterstützt auch eine Funktion namens Secure Boot, die nur die Ausführung von signierten EFI-Anwendungen erlaubt, d.h. von EFI-Anwendungen, die vom Hardwarehersteller autorisiert sind. Diese Funktion erhöht den Schutz vor bösartiger Software, kann aber die Installation von Betriebssystemen erschweren, welche nicht durch die Herstellergarantie abgedeckt sind.

Der beliebteste Bootloader für Linux in der x86-Architektur ist GRUB (Grand Unified Bootloader). Sobald er vom BIOS oder vom UEFI aufgerufen wird, zeigt GRUB eine Liste der zum Booten verfügbaren Betriebssysteme an. Manchmal erscheint die Liste nicht automatisch, aber sie kann durch Drücken von Shift aufgerufen werden, während GRUB vom BIOS aufgerufen wird. In UEFI-Systemen sollte stattdessen die Taste Esc verwendet werden.

Im GRUB-Menü ist es möglich zu wählen, welcher der installierten Kernel geladen werden soll und welche Parameter diesem übergeben werden. Die meisten Kernelparameter folgen dem Muster option=value. Einige der nützlichsten Kernelparameter sind:

Eine Änderung der Kernelparameter ist normalerweise nicht erforderlich, kann aber nützlich sein, um betriebssystembezogene Probleme zu erkennen und zu lösen. Kernelparameter müssen der Datei /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX hinzugefügt werden, um sie über Neustarts hinweg persistent zu machen. Eine neue Konfigurationsdatei für den Bootloader muss bei jeder Änderung von /etc/default/grub erzeugt werden, was durch den Befehl grub-mkconfig -o /boot/grub/grub.cfg erreicht wird. Sobald das Betriebssystem läuft, stehen die Kernelparameter, die zum Laden der aktuellen Sitzung verwendet werden, in der Datei /proc/cmdline zum Einlesen zur Verfügung.

Abgesehen vom Kernel hängt das Betriebssystem von weiteren Komponenten ab. Viele dieser Komponenten werden während des Systeminitialisierungsprozesses geladen und reichen von einfachen Shell-Skripten bis hin zu komplexeren Dienstprogrammen. Skripte werden oft verwendet, um kurzlebige Aufgaben auszuführen, die während des Systeminitialisierungsprozesses ausgeführt und beendet werden. Dienste, auch als Daemons bekannt, können die ganze Zeit aktiv sein, da sie für intrinsische Aspekte des Betriebssystems verantwortlich sein können.

Die Vielfalt der Möglichkeiten, Startskripte und Daemons mit den unterschiedlichsten Eigenschaften in eine Linux-Distribution einzubauen, ist riesig, eine Tatsache, die in der Vergangenheit die Entwicklung einer einzigen Lösung behindert hat, die die Erwartungen der Maintainer und Benutzer aller Linux-Distributionen erfüllt. Allerdings wird jedes Werkzeug, das die Maintainer einer Distribution für diese Funktion ausgewählt haben, zumindest in der Lage sein, Systemdienste zu starten, zu stoppen und neu zu starten. Diese Aktionen werden oft vom System selbst ausgeführt, z. B. nach einem Softwareupdate, aber der Systemadministrator wird den Dienst fast immer manuell neu starten müssen, nachdem er Änderungen an seiner Konfigurationsdatei vorgenommen hat.

Für einen Systemadministrator ist es auch praktisch, nach den jeweiligen Anforderungen einen bestimmten Satz von Daemons aktivieren zu können. Es sollte z.B. möglich sein, nur ein Minimum an Diensten laufen zu lassen, um Systemwartungsaufgaben durchzuführen.

Die Initialisierung des Betriebssystems beginnt, wenn der Bootloader den Kernel in den RAM-Speicher lädt. Dann übernimmt der Kernel die Kontrolle über die CPU und beginnt mit der Erkennung und Einrichtung der grundlegenden Aspekte des Betriebssystems, wie grundlegende Hardwarekonfiguration und Speicheradressierung.

Der Kernel öffnet dann das initramfs (initiales RAM-Dateisystem). Das initiale RAM Dateisystem ist ein Archiv, das ein Dateisystem enthält, das während des Bootvorgangs als temporäres Root-Dateisystem verwendet wird. Der Hauptzweck der Datei initramfs besteht darin, die erforderlichen Module bereitzustellen, damit der Kernel auf das “echte” Root-Dateisystem des Betriebssystems zugreifen kann.

Sobald das Root-Dateisystem verfügbar ist, wird der Kernel alle in /etc/fstab konfigurierten Dateisysteme einbinden und dann das erste Programm, ein Dienstprogramm namens init, ausführen. Das Programm init ist für die Ausführung aller Initialisierungsskripte und System-Daemons verantwortlich. Es gibt verschiedene Implementierungen solcher Systeminitiatoren neben dem traditionellen init, wie beispielsweise systemd und Upstart. Sobald das init-Programm geladen ist, wird das initramfs aus dem RAM entfernt.

Während des Bootvorgangs können Fehler auftreten, die jedoch möglicherweise nicht so kritisch sind, dass diese das Betriebssystem vollständig zum Stillstand bringen. Ungeachtet dessen können diese Fehler das erwartete Verhalten des Systems beeinträchtigen. Alle Fehler führen zu Meldungen, die für zukünftige Untersuchungen verwendet werden können, da sie wertvolle Informationen darüber enthalten, wann und wie der Fehler aufgetreten ist. Selbst wenn keine Fehlermeldungen erzeugt werden, können die während des Bootvorgangs gesammelten Informationen für Abstimmungs- und Konfigurationszwecke nützlich sein.

Der Speicherbereich, in dem der Kernel seine Meldungen, einschließlich der Bootmeldungen, speichert, wird als Kernel-Ringpuffer bezeichnet. Die Meldungen werden im Kernel-Ringpuffer gehalten, auch wenn sie während des Initialisierungsvorgangs nicht angezeigt werden, z.B. wenn stattdessen eine Animation angezeigt wird. Der Kernel-Ringpuffer verliert jedoch alle Nachrichten, wenn das System abgeschaltet wird oder der Befehl dmesg --clear ausgeführt wird. Ohne Optionen zeigt der Befehl dmesg die aktuellen Meldungen des Kernel-Ringpuffer an:

Die Ausgabe von dmesg kann Hunderte von Zeilen umfassen, daher enthält die vorherige Auflistung nur einen Auszug, der zeigt, wie der Kernel den systemd-Dienstmanager aufruft. Die Werte am Anfang der Zeilen sind die Anzahl der Sekunden relativ zum Beginn des Kernelladevorgangs.

In Systemen, die auf systemd basieren, zeigt der Befehl journalctl die Initialisierungsnachrichten mit den Optionen -b, --boot, -k oder --dmesg an. Der Befehl journalctl --list-boots zeigt eine Liste von Bootnummern relativ zum aktuellen Boot, ihren Identifikations-Hash, sowie die Zeitstempel der ersten und letzten entsprechenden Meldungen:

In Systemen, die auf systemd basieren, werden auch vorangegangene Initialisierungsprotokolle aufbewahrt, sodass Meldungen aus früheren Betriebssystemsitzungen noch eingesehen werden können. Wenn die Optionen -b 0 oder --boot=0 angegeben werden, werden Meldungen für den aktuellen Bootvorgang angezeigt. Die Optionen -b -1 oder --boot=-1 zeigen Meldungen von der vorherigen Initialisierung an. Die Optionen -b -2 oder --boot=-2 zeigen die Meldungen von der Initialisierung davor an und so weiter. Der folgende Ausschnitt zeigt, wie der Kernel den systemd-Dienstmanager für den letzten Initialisierungsprozess aufruft:

Initialisierung und andere vom Betriebssystem ausgegebene Meldungen werden in Dateien im Verzeichnis /var/log/ gespeichert. Wenn ein kritischer Fehler auftritt und das Betriebssystem nicht in der Lage ist, den Initialisierungsprozess nach dem Laden des Kernels und des initramfs fortzusetzen, könnte ein alternatives Bootmedium verwendet werden, um das System zu starten und somit auf das entsprechende Dateisystem zuzugreifen. Dann können die Dateien unter /var/log/ nach möglichen Gründen für die Unterbrechung des Bootprozesses durchsucht werden. Die Optionen -D oder --directory des Befehls journalctl können benutzt werden, um Logmeldungen in anderen Verzeichnissen als /var/log/journal/ zu lesen, welches der Standardort für Systemprotokollmeldungen ist. Da die Logmeldungen von systemd nicht im Rohtext gespeichert sind, ist der Befehl journalctl erforderlich, um sie zu lesen.