Ein ausgeschalteter Computer kennt keine Datei, kein Laufwerk C: und kein Betriebssystem. Beim Druck auf den Knopf existieren zunächst nur elektrische Zustände und Logik in der Firmware. Der Startvorgang ist deshalb eine Kette von Kompetenzübergaben: Jede Stufe schafft gerade genug Umgebung, um die nächste zu prüfen und auszuführen.
Null: Energie wird zu definiertem Zustand
Stromversorgung und Takt stabilisieren sich, der Prozessor verlässt den Reset und beginnt an einer architekturseitig festgelegten Adresse. Dort liegt Firmwarecode. Er initialisiert so viel Chipsatz, Speicher und Ein-/Ausgabe, dass weitere Firmwaremodule laufen können.
Der oft genannte POST ist kein einzelner magischer Test. Hersteller prüfen und konfigurieren Komponenten in verschiedenen Phasen. Ein Bildschirmbild ist bereits ein relativ spätes Komfortmerkmal; Fehlercodes oder LEDs können früher sichtbar werden.
UEFI baut eine temporäre Werkstatt
UEFI definiert Datenstrukturen, Protokolle sowie Boot und Runtime Services. [2] Treiber erschließen Geräte, die Firmware erzeugt eine Speicherkarte und bietet dem Boot-Manager Zugriff auf geeignete Dateisysteme. Diese Umgebung ist mächtig, aber noch kein allgemeines Betriebssystem.
Boot-Einträge in nichtflüchtigen Variablen verweisen typischerweise auf eine EFI-Anwendung auf einer EFI-Systempartition. Der UEFI-Boot-Manager probiert die konfigurierte Reihenfolge und kann in Setup, Recovery oder einen anderen Loader verzweigen. [1]
Secure Boot prüft Signaturen, nicht Güte
Secure Boot kann vor der Ausführung prüfen, ob ein EFI-Binary von einem akzeptierten Schlüssel signiert wurde und nicht gesperrt ist. Das schützt den Pfad gegen bestimmte unautorisierte Änderungen. Es beweist weder Fehlerfreiheit noch Vertrauenswürdigkeit jeder späteren Aktion.
Der Schutz ist eine Kette: Firmware vertraut einem Loader, der Loader einem Kernel oder weiteren Komponenten. Falsche Schlüssel, deaktivierte Prüfung oder verwundbarer signierter Code verändern das Risikomodell. Firmware gehört deshalb zur Sicherheitsarchitektur und nicht bloß zum Startkomfort. [5]
Die Übergaben im Überblick
| Stufe | Kennt bereits | Übergibt an |
|---|---|---|
| Firmware | Hardware, NVRAM, UEFI-Protokolle | EFI-Boot-Anwendung |
| Boot-Manager | Boot-Einträge und auswählbare Systeme | systemspezifischen Loader |
| OS-Loader | Kerneldatei, Parameter, ggf. initramfs | geladenen Kernel |
| Kernel | Speicher, Scheduler, Treibergrundlage | frühen Userspace |
| Init/Systemmanager | Dateisysteme, Dienste, Ziele | Anmeldung und laufendes System |
Der Kernel übernimmt die Maschine
Der Loader platziert Kernel und gegebenenfalls eine initiale RAM-Umgebung im Speicher. Beim Übergang enden viele UEFI Boot Services; der Kernel verwaltet Speicher, Interrupts und Geräte selbst. Linux dokumentiert diesen frühen Ablauf und die Rolle der initramfs. [3]
Unter Windows bilden Boot Manager und OS Loader ebenfalls getrennte Stationen, bevor Kernel und Systemprozesse starten. [4] Was als Logo mit kreisenden Punkten erscheint, überdeckt also mehrere Verantwortungswechsel.
Fehler nach der letzten sichtbaren Stufe suchen
- Keine Lebenszeichen: Energie, Board, Reset oder sehr frühe Firmware.
- Firmwareoberfläche erreichbar, kein Boot-Eintrag: Konfiguration, Datenträgererkennung oder EFI-Systempartition.
- Loader meldet Fehler: Signatur, Konfiguration, Kerneldatei oder verschlüsselter Datenträger.
- Kernel startet und stoppt: Treiber, Root-Dateisystem oder früher Userspace.
- Anmeldeoberfläche fehlt: Systemdienste oder grafischer Stack, nicht mehr UEFI.
Firmware-Spezifikation und Systemdokumentation
- UEFI Specification – Boot Manager (standard-primary)
- UEFI Specification 2.11 (standard-primary)
- Linux Kernel Documentation – Booting (technical-primary)
- Microsoft Learn – Windows Boot Architecture (technical-primary)
- NIST CSRC – Embedded Computer (standard-reference)
Recherche- und Redaktionsstand: 15. August 2026. Redaktionell verantwortlich: Benjamin Metzig.