Voraussetzungen
Bevor wir starten, müssen folgende Bedingungen erfüllt sein:
| Anforderung | Prüfbefehl |
|---|---|
| LUKS2 (nicht LUKS1) | cryptsetup luksDump /dev/nvme1n1p2 | grep "Version:" |
| TPM2-Chip vorhanden | systemd-cryptenroll --tpm2-device=list |
| Secure Boot aktiv (User Mode) | bootctl status | grep "Secure Boot" |
| systemd-boot als Bootloader | bootctl status |
| UKI-basierter Boot | ls /boot/EFI/Linux/*.efi |
⚠️ Wichtig: Diese Anleitung gilt speziell für Systeme, die Unified Kernel Images (UKI) verwenden – also
.efi-Dateien unter/boot/EFI/Linux/statt klassischer Loader-Entries unter/boot/loader/entries/. Bei klassischen Setups mit Loader-Entries weicht das Vorgehen ab.
Hintergrund: Warum UKI + sd-encrypt?
Ein Unified Kernel Image bündelt Kernel, Initramfs, Microcode und Kernel-Cmdline in einer einzigen signierten .efi-Datei. Zusammen mit Secure Boot entsteht so eine vollständige Vertrauenskette: Die Firmware prüft die Signatur des UKI, bevor der Kernel überhaupt startet.
Der TPM2-Chip nutzt sogenannte PCR-Register (Platform Configuration Registers), um den Systemzustand zu messen. Durch Bindung des LUKS-Keys an PCR 0 (Firmware-Integrität) und PCR 7 (Secure Boot State) wird der Schlüssel nur freigegeben, wenn das System im erwarteten Zustand bootet – also mit aktivem Secure Boot und unveränderter Firmware.
Der klassische encrypt-Hook in mkinitcpio unterstützt TPM2 nicht. Dafür ist der sd-encrypt-Hook nötig, der auf systemd-cryptsetup basiert und /etc/crypttab für seine Konfiguration nutzt.
Schritt 1: TPM2-Key enrollen
systemd-cryptenroll schreibt einen TPM2-gebundenen Key direkt in den LUKS2-Header. Das bestehende Passwort bleibt als Fallback immer erhalten.
| |
Enrollment prüfen:
| |
Erwartete Ausgabe:
| |
Schritt 2: /etc/crypttab befüllen
Dies ist der häufigste Fehler bei gescheiterten Setups: Der sd-encrypt-Hook liest zwingend aus /etc/crypttab – ist diese Datei leer, findet er die LUKS-Partition nicht und der Boot schlägt fehl.
Zuerst die UUID der LUKS-Partition ermitteln:
| |
Dann in /etc/crypttab eintragen:
| |
| |
⚠️ Den
name(hierroot) genau so wählen, wie die LUKS-Partition aktuell gemappt ist – prüfbar mitlsblk.
Schritt 3: Kernel-Cmdline bereinigen
Die Kernel-Parameter für UKIs werden aus /etc/kernel/cmdline eingebettet. Der cryptdevice=-Parameter gehört zum alten encrypt-Hook und muss entfernt werden – sd-encrypt kennt ihn nicht.
| |
Vorher:
| |
Nachher:
| |
⚠️ Alles muss in einer einzigen Zeile stehen, kein abschließender Zeilenumbruch.
Schritt 4: mkinitcpio Hooks anpassen
| |
Vorher:
| |
Nachher:
| |
Die Änderungen im Überblick:
| Alt | Neu | Grund |
|---|---|---|
udev | systemd | Basis für alle sd-*-Hooks |
keymap consolefont | sd-vconsole | systemd-äquivalent, liest aus /etc/vconsole.conf |
encrypt | sd-encrypt | TPM2-Unterstützung via systemd-cryptsetup |
Schritt 5: Nur das Haupt-UKI neu bauen
Wenn ein LTS-Kernel installiert ist, empfiehlt es sich, nur das Haupt-UKI neu zu bauen und das LTS-UKI als Fallback zu behalten. So kann man bei Problemen mit dem LTS-Kernel und Passwort booten.
| |
Schritt 6: UKI mit sbctl signieren
Da Secure Boot aktiv ist, muss das neu gebaute UKI signiert werden, bevor die Firmware es akzeptiert:
| |
Schritt 7: Neustart und Test
| |
Bei erfolgreichem Setup: kein Passwort-Prompt, direktes Booten durch TPM2-Unlock.
Falls doch ein Passwort abgefragt wird: Das ist der normale Fallback – der TPM hat den Key nicht freigegeben. Die häufigste Ursache ist ein falscher PCR-Zustand (z. B. Secure Boot deaktiviert oder Firmware-Update).
Schritt 8 (nach erfolgreichem Test): LTS-UKI ebenfalls aktualisieren
| |
Fehlerbehebung
TPM gibt den Key nicht frei
| |
Häufige Ursachen:
crypttableer oder falsch konfiguriertcryptdevice=noch in der Kernel-Cmdline vorhanden- Firmware-Update hat PCR 0 verändert → neues Enrollment nötig
Enrollment zurücksetzen und neu machen
| |
Das war’s. Das System bootet nun ohne Passwortabfrage – solange Secure Boot aktiv ist und die Firmware unverändert bleibt. Das LUKS-Passwort ist jederzeit als Fallback nutzbar.