Boot und Kernel: die Startkette und ihre Rettungswege

Der Host kommt nach dem Neustart nicht wieder. Auf der Fernwartungskonsole steht ein Anmeldeprompt — SSH antwortet trotzdem nicht. Ein anderer bleibt in einer Notfall-Shell stehen, weil ein Storage-Umbau vor drei Wochen das Startsystem nie erreicht hat. Zwischen dem Einschalten und einer nutzbaren Anmeldung liegen fünf Übergaben, und die Kunst besteht darin, in Sekunden zu sehen, an welcher es klemmt. Dieses Modul zeigt dir die Kette, warum es das Initramfs überhaupt gibt, wie du über die Kernel-Kommandozeile für genau einen Start ausweichst — und warum ein Kernelwechsel seinen Rückweg braucht, bevor du neu startest.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-03

Fünf Übergaben zwischen Strom und Anmeldeprompt

Ein Server, der „nicht hochkommt“, ist keine Diagnose. Zwischen dem Einschalten und einer nutzbaren Anmeldung liegen fünf Stationen, und jede gibt an die nächste ab. Wer weiß, wie weit der Start gekommen ist, hat den Fehler schon auf ein Fünftel eingegrenzt.

Firmware: UEFI oder BIOS. Prüft die Hardware und sucht ein startfähiges Gerät. Fehler hier: gar kein Bild, kein Bootgerät gefunden.
Bootloader: Liest sein Menü, lädt Kernel und Initramfs in den Speicher und übergibt. Fehler hier: kein Menü, oder eine Fehlermeldung noch vor jeder Kernelausgabe.
Kernel: Erkennt Hardware, lädt Treiber. Fehler hier: eine Panik mit Kernelmeldungen auf dem Bildschirm.
Initramfs: Ein Mini-System im Speicher, dessen einzige Aufgabe es ist, das echte Wurzeldateisystem zu finden und einzuhängen. Fehler hier: eine Notfall-Shell, die den Root-Mount nicht schafft.
systemd: Übernimmt vom Initramfs und startet die Dienste bis zum Zielzustand. Fehler hier: der Host läuft, aber etwas fehlt.

Die wichtigste Frage überhauptBekommst du eine Konsole? Dann ist der Start bis mindestens Station vier gekommen, und alles davor ist als Ursache ausgeschlossen. Ohne Konsolenzugriff — etwa über die Fernwartung des Servers — rätst du bei einem Bootproblem; mit ihm liest du ab.

Warum es das Initramfs überhaupt gibt

Initramfs — Ein kleines, komplettes Dateisystem, das der Bootloader zusammen mit dem Kernel in den Arbeitsspeicher lädt. Es enthält genau die Treiber und Werkzeuge, die nötig sind, um an das eigentliche Wurzeldateisystem heranzukommen.

Das klingt umständlich und löst ein echtes Henne-Ei-Problem: Um das Wurzeldateisystem einzuhängen, braucht der Kernel Treiber — für den RAID-Controller, für LVM, für die Verschlüsselung. Diese Treiber liegen aber auf dem Wurzeldateisystem, an das er ohne sie nicht herankommt.

Deshalb wird das Initramfs beim Erzeugen an das jeweilige System angepasst: Es bekommt genau die Module mit, die dieser Host braucht. Und genau daraus folgt die häufigste selbstgemachte Boot-Störung — wer die Speicherkonfiguration ändert, ohne das Initramfs neu zu erzeugen, hat ein Startsystem, das den neuen Weg zur Platte nicht kennt.

Wann ein Initramfs neu erzeugt gehörtNach jedem Wechsel an der Speicherkette: neuer Controller, neues RAID, LVM- oder Verschlüsselungsänderung, geändertes Wurzeldateisystem. Auch beim Einspielen eines Kernels passiert das — deshalb fällt eine kaputte Speicherkonfiguration oft erst beim nächsten Kernelupdate auf, Wochen nach der eigentlichen Änderung.

Die Kernel-Kommandozeile: der Hebel für den Notfall

Der Bootloader übergibt dem Kernel eine Zeile mit Parametern. Was gerade aktiv ist, liest du auf dem laufenden System unter `/proc/cmdline` — das ist der erste Griff, wenn du wissen willst, womit dieser Host tatsächlich gestartet wurde.

Diese Zeile lässt sich im Bootmenü für einen einzelnen Start bearbeiten, ohne irgendetwas auf der Platte zu ändern. Das ist der wichtigste Rettungsweg, den ein Linux-System hat: Du änderst nichts, du probierst nur — und ein Neustart stellt den alten Zustand wieder her.

systemd.unit=<ziel>: Startet in ein anderes Ziel als das voreingestellte. Der allgemeine Fall, aus dem sich die folgenden ableiten.
rescue: Kurzform für das Rettungsziel — entspricht systemd.unit=rescue.target.
emergency: Kurzform für das Notfallziel.
Parameter mit rd.-Präfix: Wirken in der Initramfs-Phase, also bevor das echte System übernimmt — etwa rd.emergency für eine Shell noch vor dem Root-Mount.

Der Unterschied, auf den es ankommtEin Parameter mit rd.-Präfix greift im Initramfs, alles andere erst danach. Wenn der Start schon am Root-Mount scheitert, hilft dir ein Ziel ohne dieses Präfix nicht — das System kommt ja nie so weit, es auszuwerten.

Rescue und Emergency sind nicht dasselbe

Beide führen zu einer Shell statt zum normalen Betrieb, aber sie unterscheiden sich in dem, was vorher passiert — und diese Unterscheidung entscheidet, welches du brauchst.

rescue.target: Zieht das Basissystem einschließlich der Systemmounts hoch und startet dann eine Rettungs-Shell. Du hast deine Dateisysteme, aber keine regulären Dienste.
emergency.target: Startet eine Notfall-Shell auf der Hauptkonsole und zieht weder weitere Dienste noch Mounts hoch. Der minimalste Zustand, den es gibt.

Praktisch heißt das: Für eine kaputte Dienstkonfiguration oder ein vergessenes Passwort reicht rescue — die Dateisysteme sind da, du kannst arbeiten. Wenn dagegen der Mount selbst das Problem ist, landest du ohnehin in emergency, und dort musst du erst von Hand einhängen, bevor du irgendetwas reparieren kannst.

Das reguläre Ziel heißt default.target und ist üblicherweise nur ein anderer Name für multi-user.target — ein System ohne grafische Oberfläche, der Normalfall für Server. graphical.target zieht multi-user.target mit hoch und ergänzt die Oberfläche.

Ein Kernelwechsel ist kein Update wie andere

Ein neuer Kernel unterscheidet sich in einem Punkt von jedem anderen Paket: Er wirkt erst nach einem Neustart, und wenn er nicht funktioniert, merkst du es genau dann — wenn der Host schon aus ist.

Die gute Nachricht ist, dass Distributionen das eingeplant haben. Ein Kernelupdate ersetzt den alten Kernel nicht, sondern legt den neuen daneben; im Bootmenü stehen danach beide. Das ist der eingebaute Rückweg, und er kostet nichts — außer dass jemand ihn kennen und im Ernstfall erreichen muss.

Kernelwechsel auf einem Host mit nur einem Wartungsfenster

Szenario

Ein Treiberfehler soll mit einem neueren Kernel behoben werden. Der Host trägt einen kundennahen Dienst. Fernwartungszugang ist vorhanden, ein Testsystem gibt es nicht.

Anforderungen

Der Rückweg steht fest, bevor neu gestartet wird
Ein Fehlschlag ist ohne Anfahrt behebbar
Der Erfolg wird belegt, nicht angenommen

Schritte

Prüfen, dass der alte Kernel installiert bleibt und im Bootmenü erscheint — das ist der Rückweg, und er wird vorher angesehen, nicht vorausgesetzt.
Zugriff auf die Fernwartungskonsole testen, bevor der Neustart passiert. Ein Rückweg, den man nicht erreicht, ist keiner.
Neu starten und die Startkette auf der Konsole mitlesen, statt auf die Erreichbarkeit über das Netz zu warten.
Nach dem Start belegen, dass der laufende Kernel der erwartete ist und der Treiberfehler tatsächlich weg ist — beides getrennt prüfen.
Schlägt es fehl: im Bootmenü den alten Kernel wählen. Das ist ein einzelner Start, keine Änderung — der Host ist danach wieder da, und die Analyse hat Zeit.

Merksatz: Der Rückweg eines Kernelwechsels ist ein Menüeintrag und ein Konsolenzugang. Beides ist vorher zu prüfen, weil beides nachher nicht mehr zu beschaffen ist.

Kernel-Module: Treiber, die zur Laufzeit dazukommen

Ein Linux-Kernel bringt nicht alle Treiber fest eingebaut mit. Das meiste liegt als Modul vor und wird geladen, wenn die passende Hardware auftaucht — deshalb funktioniert derselbe Kernel auf sehr unterschiedlichen Maschinen.

Kernel-Modul — Ein Stück Kernelcode, das im laufenden Betrieb nachgeladen und meist auch wieder entfernt werden kann — typischerweise ein Gerätetreiber oder ein Dateisystem. Was gerade geladen ist, listet lsmod; geladen und entladen wird mit modprobe.

Im Betrieb wird das dann relevant, wenn ein Treiber nicht geladen werden soll: eine fehlerhafte Version, ein Gerät, das ein anderer Treiber übernehmen soll, oder eine Funktion, die aus Sicherheitsgründen wegbleibt. Dafür gibt es Konfigurationsdateien unter /etc/modprobe.d/.

Warum eine Sperre oft nicht wirktDas übliche Schlüsselwort dafür sorgt laut Dokumentation dafür, dass die internen Aliase eines Moduls ignoriert werden — es ist keine unbedingte Sperre. Ein ausdrücklicher Alias an anderer Stelle setzt sich darüber hinweg, und ein Modul, das ein anderes als Abhängigkeit nachzieht, lädt es trotzdem. Wer wirklich verhindern will, dass etwas geladen wird, braucht dafür das Schlüsselwort, das statt des Ladens ein Kommando ausführt.

Und es gibt einen zweiten Grund, warum eine Sperre scheinbar ignoriert wird: Wird das Modul schon im Initramfs geladen, kommt die Datei unter /etc/modprobe.d/ gar nicht zum Zug — sie liegt auf dem Wurzeldateisystem, das zu diesem Zeitpunkt noch nicht eingehängt ist. Damit die Regel früh genug greift, muss das Initramfs neu erzeugt werden.

Die Bootloader-Konfiguration wird erzeugt, nicht geschrieben

Ein klassischer Fehlgriff: Man findet die Konfigurationsdatei des Bootloaders, ändert dort einen Kernelparameter, startet neu — und die Änderung ist verschwunden. Beim nächsten Kernelupdate erst recht.

Der Grund ist, dass diese Datei bei den gängigen Distributionen erzeugt wird. Es gibt eine Quelldatei mit den Vorgaben und ein Werkzeug, das daraus das fertige Menü baut — inklusive aller installierten Kernel. Wer die erzeugte Datei bearbeitet, schreibt in ein Zwischenergebnis, das beim nächsten Lauf des Generators überschrieben wird.

Einmalig, für einen Start: Im Bootmenü die Kernel-Kommandozeile bearbeiten. Ändert nichts auf der Platte, überlebt keinen Neustart — genau richtig zum Ausprobieren.
Dauerhaft: Die Quelldatei ändern und die Konfiguration neu erzeugen lassen. Überlebt Kernelupdates, weil der Generator sie jedes Mal wieder einbaut.
Falsch: Die erzeugte Menüdatei direkt bearbeiten. Funktioniert bis zum nächsten Generatorlauf und ist dann spurlos weg.

Die praktische ReihenfolgeErst im Bootmenü ausprobieren, ob der Parameter das gewünschte Ergebnis bringt. Erst wenn er es tut, in die Quelldatei übernehmen und neu erzeugen lassen. Wer die Reihenfolge umdreht, macht eine dauerhafte Änderung, deren Wirkung er noch gar nicht kennt — und muss sie im Zweifel über die Konsole zurücknehmen.

Was ein Symptom belegt — und was nicht

Bei Bootproblemen wird häufiger falsch geschlossen als irgendwo sonst, weil eine Beobachtung mehr zu sagen scheint, als sie tut. Zwei Beispiele, die im Alltag ständig vorkommen:

Konsole zeigt einen Anmeldeprompt, SSH antwortet nicht: Belegt: Der Start ist komplett durchgelaufen. Offen: Netzwerk, Firewall, Namensauflösung, der SSH-Dienst selbst. Der Bootpfad ist als Ursache ausgeschlossen.
Host ist per Ping erreichbar, aber ohne Dienst: Belegt: Kernel und Netzwerk sind oben. Offen: alles, was systemd danach starten sollte.

Die Regel dahinterEin Symptom belegt immer nur die Schicht, die es sichtbar macht — und alle darunter. Aus „ich sehe eine Konsole“ folgt, dass der Start weit gekommen ist; daraus folgt nichts über die Erreichbarkeit über das Netz. Beides sind getrennte Pfade, und sie werden getrennt geprüft.

Kurzcheck

Nach einem Neustart zeigt die Fernwartungskonsole einen normalen Anmeldeprompt, aber SSH antwortet nicht. Wo suchst du?

Im Netzwerk- und Dienstpfad — der Start ist durchgelaufen, sonst gäbe es keinen Prompt.
Im Initramfs — der Root-Mount könnte teilweise fehlgeschlagen sein und Dienste ohne ihre Dateien gelassen haben.
In der Kernel-Kommandozeile — ein Parameter könnte den Host in ein Ziel ohne Netzwerk gestartet haben.

Treffer. Genau. Der Prompt belegt, dass die gesamte Startkette bis zum Zielzustand gekommen ist. Was fehlt, liegt danach: Adresse, Route, Paketfilter oder der SSH-Dienst selbst.

UEFI, Secure Boot und die signierte Kette

Auf heutiger Serverhardware ist die Firmware UEFI. Für den Betrieb bedeutet das vor allem eines: Die Firmware kennt eine eigene, kleine FAT-Partition auf der Platte, in der die Startprogramme liegen, und sie führt eine eigene Liste von Starteinträgen. Ein Host kann also startfähig sein, ohne dass die Firmware ihn in ihrer Liste hat — und umgekehrt.

Darauf setzt Secure Boot auf: Die Firmware führt nur Startprogramme aus, deren Signatur sie kennt. Der Bootloader ist signiert, prüft seinerseits den Kernel, und so entsteht eine Kette bis zum laufenden System.

Wo das im Betrieb weh tutDie Kette bricht, sobald etwas Unsigniertes hinein soll — ein selbst gebauter Kernel oder ein Treibermodul, das nicht aus der Distribution stammt. Das Symptom ist dann kein Boot-Abbruch, sondern ein Modul, das sich schlicht nicht laden lässt. Wer stundenlang eine Treiberkonfiguration sucht, ohne diesen Zusammenhang zu kennen, sucht an der falschen Stelle.

Die drei Wege daraus sind: das Modul signieren lassen, einen eigenen Schlüssel in der Firmware hinterlegen, oder Secure Boot abschalten. Alle drei sind vertretbar — der dritte nur dann, wenn jemand die Entscheidung bewusst trifft und dokumentiert, statt sie im Wartungsfenster nebenbei zu fällen.

Wenn der Start langsam ist statt kaputt

Nicht jedes Bootproblem ist ein Abbruch. Ein Host, der statt in dreißig Sekunden erst nach vier Minuten erreichbar ist, hat auch ein Problem — nur eines, das niemand meldet, bis es im Notfall stört.

systemd bringt dafür eigene Auswertungen mit. Die eine listet alle Units nach ihrer Startdauer — nützlich, um den größten Einzelposten zu finden. Die andere zeigt die zeitkritische Kette als Baum: welche Unit auf welche gewartet hat und wie lange. Die zweite ist fast immer die aufschlussreichere, weil eine langsame Unit nur dann den Start verzögert, wenn andere auf sie warten.

Der häufigste FundMeistens steht am Ende ein Dienst, der auf etwas wartet, das gar nicht kommt — ein Netzlaufwerk ohne nofail, eine Namensauflösung ohne Antwort, ein Dienst mit fester Wartezeit statt deklarierter Abhängigkeit. Der Startpfad ist damit auch eine Prüfung der Abhängigkeiten, die jemand modelliert hat.

Ein Sonderfall lohnt eigene Aufmerksamkeit: Dienste, die auf ein fertig konfiguriertes Netzwerk warten. Es gibt dafür ein eigenes Ziel, und es bedeutet nicht, was viele annehmen — nicht „das Netzwerk funktioniert“, sondern „die Konfiguration ist abgeschlossen“. Eine Adresse per DHCP kann danach immer noch fehlen, und ein Dienst, der sich auf eine bestimmte Adresse bindet, scheitert trotzdem.

Die häufigste Verzögerung überhauptWenn ein Host konstant um eine auffällig runde Zeitspanne langsamer startet — anderthalb Minuten, zwei Minuten —, wartet fast immer etwas in ein Zeitlimit statt in einen Fehler. Ein Zeitlimit ist ein Hinweis auf eine Abhängigkeit, die niemand erklärt hat; die Lösung ist, sie zu deklarieren oder den Dienst nicht mehr auf sie warten zu lassen.

Die Reihenfolge bei einem Bootproblem

Konsole holen — ohne Bild rätst du→Bestimmen, wie weit der Start gekommen ist→Nur die Station untersuchen, an der er stehen blieb→Über die Kernel-Kommandozeile für einen Start ausweichen, nichts dauerhaft ändern→Nach der Reparatur den Bootpfad einmal vollständig durchlaufen lassen

Der vierte Schritt ist der, der am meisten Ärger spart. Eine Änderung im Bootmenü gilt für einen einzigen Start; eine Änderung an der Konfiguration auf der Platte gilt für immer — auch wenn sie falsch war. Im Zweifel probiert man erst und schreibt danach.

Der fünfte klingt nach Formalie und ist es nicht. Ein Host, den man aus einer Notfall-Shell heraus repariert hat, ist damit nicht als startfähig belegt — belegt ist nur, dass er in diesem einen Zustand bedienbar war. Ein vollständiger Neustart im Wartungsfenster ist der einzige Test, der die Frage beantwortet, und er ist erheblich billiger als derselbe Neustart um drei Uhr nachts nach einem Stromausfall.

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Ein Symptom belegt nur seine eigene Schicht und alle darunter — aus einer Konsole folgt nichts über SSH. Das Initramfs ist an den Host angepasst und gehört nach jeder Änderung an der Speicherkette neu erzeugt. Die Kernel-Kommandozeile ist der Rettungsweg, der nichts verändert. Und ein Kernelwechsel braucht seinen Rückweg vorher — im Bootmenü liegt er schon, der Konsolenzugang muss vorher getestet sein.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-03