Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / SUSE Linux Enterprise Server-Dokumentation / Verwaltungshandbuch / Booten eines Linux-Systems / Einführung in den Bootvorgang
Gilt für SUSE Linux Enterprise Server 15 SP4

16 Einführung in den Bootvorgang

 

Das Booten eines Linux-Systems umfasst verschiedene Komponenten und Tasks. Nach der Firmware- und Hardware-Initialisierung, die von der Computerarchitektur abhängt, wird der Kernel mithilfe des Bootloaders GRUB 2 gestartet. Anschließend wird der Bootvorgang vollständig vom Betriebssystem gesteuert und über systemd abgewickelt. systemd bietet eine Reihe von „Zielen“, mit denen Konfigurationen für den normalen Gebrauch, für Wartungsarbeiten oder für Notfälle gebootet werden.

16.1 Terminologie

 

In diesem Kapitel werden Begriffe verwendet, die unter Umständen nicht eindeutig sind. Aus diesem Grund stellen wir im Folgenden einige Definitionen bereit:

init

Derzeit gibt es zwei unterschiedliche Prozesse mit dem Namen „init“:

  • den initramfs-Vorgang, mit dem das root-Dateisystem eingehängt wird

  • den Betriebssystemprozess, mit dem alle anderen Prozesse gestartet werden und der über das echte root-Dateisystem ausgeführt wird

In beiden Fällen wird die jeweilige Aufgabe vom Programm systemd ausgeführt. Zunächst wird sie aus dem initramfs ausgeführt, sodass das root-Dateisystem eingehängt wird. Wurde dieser Vorgang erfolgreich abgeschlossen, wird der Vorgang als ursprünglicher Prozess erneut ausgeführt, diesmal aus dem root-Dateisystem. Damit keine Verwirrung entsteht, welcher der beiden systemd-Prozesse gemeint ist, bezeichnen wir den ersten als init auf initramfs und den zweiten als systemd.

initrd/initramfs

Eine initrd (ursprüngliche RAM-Festplatte) ist eine Imagedatei, die ein Image des root-Dateisystems enthält, das vom Kernel geladen und über /dev/ram als temporäres root-Dateisystem eingehängt wird. Für das Einhängen dieses Dateisystems ist ein Dateisystemtreiber erforderlich.

Ab Kernel 2.6.13 wurde initrd durch initramfs (ursprüngliches RAM-Dateisystem) ersetzt, für das kein Dateisystemtreiber eingehängt werden muss. SUSE Linux Enterprise Server verwendet ausschließlich ein initramfs. Da initramfs jedoch als /boot/initrd gespeichert ist, wird es auch häufig als „initrd“ bezeichnet. In diesem Kapitel verwenden wir ausschließlich den Begriff initramfs.

16.2 Der Linux-Bootvorgang

 

Der Linux-Bootvorgang besteht aus mehreren Phasen, von denen jede einer anderen Komponente entspricht:

  1. Abschnitt 16.2.1, „Initialisierungs- und Bootloader-Phase“

  2. Abschnitt 16.2.2, „Die Kernel-Phase“

  3. Abschnitt 16.2.3, „Die Phase init auf initramfs“

  4. Abschnitt 16.2.4, „Die systemd-Phase“

16.2.1 Initialisierungs- und Bootloader-Phase

 

Während der Initialisierungsphase wird die Computerhardware eingerichtet und die Geräte werden vorbereitet. Dieser Prozess verläuft, abhängig von der Hardwarearchitektur, bei jedem Gerät anders.

SUSE Linux Enterprise Server nutzt für alle Architekturen den Bootloader GRUB 2. Abhängig von Architektur und Firmware ist das Starten des Bootloaders GRUB 2 unter Umständen ein Prozess mit mehreren Schritten. Zweck des Bootloaders ist es, den Kernel und das ursprüngliche RAM-basierte Dateisystem (initramfs) zu laden. Weitere Informationen zu GRUB 2 finden Sie in Kapitel 18, Der Bootloader GRUB 2.

16.2.1.1 Initialisierungs- und Bootloader-Phase auf AArch64 und AMD64/Intel 64

 

Nach dem Einschalten des Computers initialisiert das BIOS oder das UEFI den Bildschirm und die Tastatur und testet den Hauptspeicher. Bis zu dieser Phase greift der Computer nicht auf Massenspeichergeräte zu. Anschließend werden Informationen zum aktuellen Datum, zur aktuellen Uhrzeit und zu den wichtigsten Peripheriegeräten aus den CMOS-Werten geladen. Wenn die Boot-Medien und deren Geometrie erkannt wurden, geht die Systemkontrolle vom BIOS/UEFI an den Bootloader über.

Auf einem mit traditionellem BIOS ausgestatteten Computer kann nur Code des ersten physischen 512-Byte-Datensektors (Master-Boot-Datensatz, MBR) der Boot-Festplatte geladen werden. Nur die minimalistische Version von GRUB 2 passt in den MBR. Seine einzige Aufgabe besteht darin, ein Core-Image von GRUB 2 zu laden, das die Dateisystemtreiber aus der Lücke zwischen MBR und erster Partition (MBR-Partitionstabelle) oder der BIOS-Boot-Partition (GPT-Partitionstabelle) enthält. Dieses Image enthält Dateisystemtreiber und ist somit in der Lage, auf /boot im root-Dateisystem zuzugreifen. /boot enthält zusätzliche Module für den Core von GRUB 2 sowie den Kernel und das initramfs-Image. Wenn GRUB 2 Zugriff auf diese Partition hat, lädt es den Kernel und das initramfs-Image in den Speicher und übergibt die Steuerung an den Kernel.

Wird ein BIOS-System aus einem verschlüsselten Dateisystem gebootet, das über eine verschlüsselte /boot-Partition verfügt, müssen Sie das Entschlüsselungspasswort zweimal eingeben. Zunächst benötigt es GRUB 2, um /boot zu entschlüsseln, die zweite Eingabe ermöglicht es systemd, die verschlüsselten Volumes einzuhängen.

Auf UEFI-Computern verläuft der Boot-Vorgang sehr viel einfacher als auf Computern mit herkömmlichem BIOS. Die Firmware kann eine FAT-formatierte Systempartition von Festplatten mit GPT-Partitionstabelle lesen. Diese EFI-Systempartition (im laufenden System eingehängt als/boot/efi) bietet ausreichend Platz für eine komplette GRUB 2-Anwendung, die unmittelbar von der Firmware geladen und ausgeführt wird.

Wenn das BIOS/UEFI Netzwerk-Booting unterstützt, ist es auch möglich, einen Boot-Server zu konfigurieren, der den Bootloader bereitstellt. Das System kann dann über PXE gebootet werden. Das BIOS/UEFI dient als Bootloader. Es erhält das Boot-Image vom Boot-Server und startet das System. Dieser Vorgang ist vollständig unabhängig von den lokalen Festplatten.

16.2.1.2 Initialisierungs- und Bootloader-Phase auf IBM Z

 

Bei IBM Z muss der Boot-Vorgang durch einen Bootloader namens zipl (ursprüngliches z-Programmladen) initialisiert werden. Obwohl zipl das Lesen unterschiedlicher Dateisysteme unterstützt, unterstützt es nicht das SLE-Standarddateisystem (Btrfs) oder das Booten aus Snapshots. SUSE Linux Enterprise Server nutzt somit einen zweistufigen Boot-Vorgang, der gewährleistet, dass Btrfs zum Boot-Zeitpunkt vollständig unterstützt wird:

  1. zipl bootet aus der Partition /boot/zipl, die mit dem Datensystem Ext2, Ext3, Ext4 oder XFS formatiert werden kann. Diese Partition enthält einen minimalistischen Kernel sowie ein initramfs, die in den Speicher geladen werden. Das initramfs enthält (unter anderem) einen Btrfs-Treiber und den Bootloader GRUB 2. Der Kernel wird mit dem Parameter initgrub gestartet, der ihm befiehlt, GRUB 2 zu starten.

  2. Der Kernel hängt das root-Dateisystem ein, sodass auf /boot zugegriffen werden kann. Jetzt wird GRUB 2 über initramfs gestartet. Die Anwendung liest ihre Konfiguration aus /boot/grub2/grub.cfg aus und lädt den letzten Kernel und das initramfs aus /boot. Der neue Kernel wird nun über Kexec geladen.

16.2.2 Die Kernel-Phase

 

Sobald der Bootloader die Systemsteuerung übergeben hat, läuft der Boot-Vorgang auf allen Architekturen gleich ab. Der Bootloader lädt sowohl den Kernel als auch ein ursprüngliches RAM-basiertes Dateisystem (initramfs) in den Speicher und der Kernel übernimmt die Steuerung.

Nachdem der Kernel die Speicherverwaltung eingerichtet und CPU-Typ und -Eigenschaften erkannt hat, wird die Hardware initialisiert und das temporäre root-Dateisystem aus dem Speicher eingehängt, der mit initramfs geladen wurde.

16.2.2.1 Die initramfs-Datei

 

initramfs (ursprüngliches RAM-Dateisystem) ist ein kleines cpio-Archiv, das der Kernel auf einen RAM-Datenträger laden kann. Zu finden ist es unter /boot/initrd. Es lässt sich mit einem Tool namens dracut erstellen – weitere Hinweise finden Sie unter man 8 dracut.

initramfs stellt eine minimale Linux-Umgebung bereit, die das Ausführen von Programmen ermöglicht, bevor das eigentliche root-Dateisystem eingehängt wird. Diese minimale Linux-Umgebung wird durch eine BIOS- oder UEFI-Routine in den Arbeitsspeicher geladen, wobei lediglich ausreichend Arbeitsspeicher zur Verfügung stehen muss; ansonsten gelten keine besonderen Anforderungen. Das initramfs-Archiv must stets eine ausführbare Datei mit der Bezeichnung init umfassen, die den systemd-Daemon auf dem root-Dateisystem ausführt, so dass der Bootvorgang fortgesetzt werden kann.

Bevor das root-Dateisystem eingehängt und das Betriebssystem gestartet werden kann, ist es für den Kernel erforderlich, dass die entsprechenden Treiber auf das Gerät zugreifen, auf dem sich das root-Dateisystem befindet. Diese Treiber können spezielle Treiber für bestimmte Arten von Festplatten oder sogar Netzwerktreiber für den Zugriff auf ein Netzwerk-Dateisystem umfassen. Die erforderlichen Module für das root-Dateisystem werden mithilfe von init oder initramfs geladen. Nachdem die Module geladen wurden, stellt udev das initramfs mit den erforderlichen Geräten bereit. Später im Boot-Vorgang, nach dem Ändern des root-Dateisystems, müssen die Geräte regeneriert werden. Dies geschieht über die systemd-Einheit systemd-udev-trigger.service.

16.2.2.1.1 Erneutes Generieren von initramfs
 

Da initramfs Treiber enthält, muss es aktualisiert werden, sobald neue Versionen der darin gespeicherten Treiber verfügbar sind. Dies geschieht automatisch bei der Installation des Pakets, das die Treiberaktualisierung enthält. YaST oder zypper informieren Sie über diesen Umstand, indem Sie den Output des Befehls anzeigen, mit dem initramfs generiert wird. Es gibt jedoch einige Situationen, in denen Sie initramfs manuell neu erzeugen müssen:

Hinzufügen von Treibern aufgrund von Änderungen an der Hardware

Wenn Hardwarekomponenten (z. B. Festplatten) ausgetauscht werden müssen und diese Hardware zur Bootzeit andere Treiber im Kernel erfordert, müssen Sie die Datei initramfs aktualisieren.

Öffnen oder erstellen Sie /etc/dracut.conf.d/10-DRIVER.conf und fügen Sie die folgende Zeile hinzu (achten Sie auf das führende Leerzeichen): 

force_drivers+=" DRIVER1 "

Ersetzen Sie dabei DRIVER1 durch den Modulnamen des Treibers. Sie können auch mehrere Treiber hinzufügen. In diesem Fall geben Sie eine durch Leerzeichen getrennte Liste der Modulnamen ein: 

force_drivers+=" DRIVER1 DRIVER2 "

Fahren Sie mit Prozedur 16.1, „Generieren eines initramfs“ fort.

Verschieben von Systemverzeichnissen auf RAID oder LVM

Wann immer Sie Auslagerungsdateien oder Systemverzeichnisse wie /usr in einem laufenden System auf RAID oder ein logisches Volume verschieben, müssen Sie ein initramfs erstellen, das Softwaretreiber für RAID oder LVM unterstützt.

Hierzu müssen Sie die entsprechenden Einträge in /etc/fstab erstellen und die neuen Einträge (beispielsweise mit mount -a und/oder swapon -a) einhängen.

Fahren Sie mit Prozedur 16.1, „Generieren eines initramfs“ fort.

Hinzufügen von Festplatten zu einer LVM-Gruppe/einem Btrfs-RAID mit root-Dateisystem

Wann immer Sie eine Festplatte zu einer logischen Volumegruppe oder einem Btrfs-RAID, die oder das das root-Dateisystem enthält, hinzufügen (oder daraus entfernen), müssen Sie ein initramfs erstellen, das das größere Volume unterstützt. Befolgen Sie die Anweisungen unter Prozedur 16.1, „Generieren eines initramfs“.

Fahren Sie mit Prozedur 16.1, „Generieren eines initramfs“ fort.

Ändern der Kernel-Variablen

Wenn Sie die Werte von Kernel-Variablen über die sysctl-Benutzeroberfläche ändern und dabei die zugehörigen Dateien ändern (/etc/sysctl.conf oder /etc/sysctl.d/*.conf), geht die Änderung beim nächsten Neubooten des Systems verloren. Die Änderungen werden selbst dann nicht in der initramfs-Datei gespeichert, wenn Sie die Werte zur Laufzeit mit sysctl --system laden. Aktualisieren Sie es, in dem Sie wie in Prozedur 16.1, „Generieren eines initramfs“ beschrieben vorgehen.

Vorgehen 16.1: Generieren eines initramfs
 

Beachten Sie, dass alle Kommandos des folgenden Verfahrens als root-Benutzer ausgeführt werden müssen.

  1. Geben Sie Ihr Verzeichnis /boot ein: 

    # cd /boot

  2. Erzeugen Sie eine neue initramfs-Datei mit dracut und ersetzen Sie dabei MY_INITRAMFS durch einen Dateinamen Ihrer Wahl: 

    # dracut MY_INITRAMFS

    Führen Sie alternativ dracut -f FILENAME aus und ersetzen Sie damit eine vorhandene init-Datei.

  3. (Überspringen Sie diesen Schritt, wenn Sie im vorangegangenen Schritt dracut -f ausgeführt haben.) Erstellen Sie einen symbolischen Link von der initramfs-Datei, die Sie im vorangegangenen Schritt erstellt haben, zu initrd: 

    #  ln -sf MY_INITRAMFS initrd

  4. Unter der Architektur IBM z müssen Sie zudem grub2-install ausführen.

16.2.3 Die Phase init auf initramfs

 

Das temporäre root-Dateisystem, das vom Kernel aus initramfs eingehängt wird, enthält die ausführbare Datei systemd (die wir im Folgenden als init auf initramfs bezeichnen, siehe auch Abschnitt 16.1, „Terminologie“). Dieses Programm führt alle erforderlichen Aktionen aus, mit denen das eigentliche root-Dateisystem eingehängt wird. Es bietet Kernel-Funktionen für das benötigte Dateisystem sowie Gerätetreiber für Massenspeicher-Controller mit udev.

Der Hauptzweck von init unter initramfs ist es, das Einhängen des eigentlichen root-Dateisystems sowie die Vorbereitung des Zugriffs darauf. Je nach aktueller Systemkonfiguration ist init unter initramfs für die folgenden Tasks verantwortlich.

Laden der Kernelmodule

Je nach Hardware-Konfiguration sind für den Zugriff auf die Hardware-Komponenten des Computers (vor allem auf die Festplatte) spezielle Treiber erforderlich. Für den Zugriff auf das eigentliche root-Dateisystem muss der Kernel die entsprechenden Dateisystemtreiber laden.

Bereitstellen von speziellen Blockdateien

Der Kernel generiert, abhängig von den geladenen Modulen, Geräteereignisse. udev verarbeitet diese Ereignisse und generiert die erforderlichen blockspezifischen Dateien auf einem RAM-Dateisystem im Verzeichnis /dev. Ohne diese speziellen Dateien wäre ein Zugriff auf das Dateisystem und andere Geräte nicht möglich.

Verwalten von RAID- und LVM-Setups

Wenn Ihr System so konfiguriert ist, dass das root-Dateisystem sich unter RAID oder LVM befindet, richtet init unter initramfs LVM oder RAID so ein, dass der Zugriff auf das root-Dateisystem zu einem späteren Zeitpunkt erfolgt.

Verwalten der Netzwerkkonfiguration

Wenn Ihr System für die Verwendung eines Netzwerk-eingehängten root-Dateisystems (über NFS eingehängt) konfiguriert ist, muss init sicherstellen, dass die entsprechenden Netzwerktreiber geladen und für den Zugriff auf das root-Dateisystem eingerichtet werden.

Wenn sich das Dateisystem auf einem Netzwerkblockgerät wie iSCSI oder SAN befindet, wird die Verbindung zum Speicherserver ebenfalls von init unter initramfs eingerichtet. SUSE Linux Enterprise Server unterstützt das Booten von einem sekundären iSCSI-Ziel, wenn das primäre Ziel nicht verfügbar ist. Weitere Details zur Konfiguration des Boot-iSCSI-Ziels finden Sie im Section 15.3.1, “Using YaST for the iSCSI initiator configuration”.

Anmerkung
Anmerkung: Umgang mit Einhängefehlern

Wenn beim Einhängen des root-Dateisystems in der Bootumgebung ein Fehler auftritt, muss es überprüft und repariert werden, bevor das Booten fortgesetzt werden kann. Die Dateisystemprüfung wird für Ext3- und Ext4-Dateisysteme automatisch gestartet. Der Reparaturvorgang findet für XFS- und Btrfs-Dateisysteme nicht automatisch statt und dem Benutzer werden Informationen angezeigt, die die verfügbaren Optionen zur Reparatur des Dateisystems beschreiben. Wenn das Dateisystem erfolgreich repariert wurde, versucht das System nach dem Beenden der Bootumgebung erneut, das root-Dateisystem einzuhängen. Falls dieser Vorgang erfolgreich ist, wird der Bootvorgang wie gewohnt fortgesetzt.

16.2.3.1 Die Phase init auf initramfs während des Installationsvorgangs

 

Wenn init unter initramfs im Rahmen des Installationsvorgangs während des anfänglichen Boot-Vorgangs aufgerufen wird, unterscheiden sich seine Tasks von den oben beschriebenen. Beachten Sie, dass das Installationssystem auch systemd aus initramfs nicht startet – diese Aufgaben werden von linuxrc übernommen.

Suchen des Installationsmediums

Beim Starten des Installationsvorgangs lädt der Rechner einen Installations-Kernel und eine besondere init mit dem YaST-Installationsprogramm. Das YaST-Installationsprogramm wird in einem RAM-Dateisystem ausgeführt und benötigt Daten über den Speicherort des Installationsmediums, um auf dieses zugreifen und das Betriebssystem installieren zu können.

Initiieren der Hardware-Erkennung und Laden der entsprechenden Kernelmodule

Wie bereits in Abschnitt 16.2.2.1, „Die initramfs-Datei“ erwähnt, beginnt der Boot-Vorgang mit einem Mindestsatz an Treibern, die für die meisten Hardware-Konfigurationen verwendet werden können. Bei Rechnern mit AArch64, POWER und AMD64/Intel 64 löst linuxrc zunächst eine Hardwareabfrage aus, durch die die Treiber ermittelt werden, die sich für Ihre Hardwarekonfiguration eignen. Unter IBM Z muss beispielsweise über linuxrc oder parmfile eine Liste der Treiber und deren Parameter bereitgestellt werden.

Diese Treiber werden zur Erstellung der zum Booten des Systems benötigten, benutzerdefinierten initramfs-Datei verwendet. Falls die Module nicht für „boot“, sondern für „coldplug“ benötigt werden, können sie mit systemd geladen werden. Weitere Informationen finden Sie unter Abschnitt 19.6.4, „Laden der Kernelmodule“.

Laden des Installationssystems

Wenn die Hardware ordnungsgemäß erkannt wurde, werden die entsprechenden Treiber geladen. Das udev-Programm erstellt die speziellen Gerätedateien und linuxrc startet das Installationssystem mit dem YaST-Installationsprogramm.

Starten von YaST

linuxrc startet schließlich YaST, das wiederum die Paketinstallation und die Systemkonfiguration startet.

16.2.4 Die systemd-Phase

 

Nachdem das „echte“ root-Dateisystem gefunden wurde, wird es auf Fehler geprüft und eingehängt. Wenn dieser Vorgang erfolgreich ist, wird das initramfs bereinigt, und der systemd-Daemon wird für das root-Dateisystem ausgeführt. systemd ist der System- und Servicemanager von Linux. Es handelt sich dabei um den übergeordneten Prozess, der als PID 1 gestartet wird und wie ein init-System agiert, das die Benutzerraumdienste startet und betreibt. Ausführliche Informationen finden Sie unter Kapitel 19, Der Daemon systemd.