Im letzten Beitrag dieser Serie

Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – I – Vorüberlegungen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – II – Vorüberlegungen zur Virtualisierung
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – III – Zugriffs-Layer
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IV – Disk-Layout
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – V – kryptierte Partitionen und Alignment
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VI – Key-Slots, PBKDF2- und MK-Iterationen
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – VII – Grundinstallation für LUKS on LVM

hatte ich beschrieben, dass wir während einer Opensuse-Installation mit selbst konfigurierten LUKS-Volumes (LUKS on LVM) manuell dafür sorgen müssen, dass die Datei “/etc/crypttab” im künftigen “/”-FS existiert, bevor der Installer gegen Ende der Installation “dracut” aufruft. Der Opensuse-Installer unterstützt uns dabei leider nicht :-(.

Sollte das jedoch schief gegangen sein oder sollte die selbst verfasste “/etc/crypttab” einen falschen Eintrag aufweisen, schlägt der erste Systemstart nach der Installation fehl. Ich gehe davon aus, dass das zu bootende LUKS-Volume mit LUKS1 (und nicht LUKS2) für die Verschlüsselung formatiert wurde, so dass Grub2 es ansprechen kann. Man wird dann zwar noch von Grub2 nach der Passphrase für das LUKS-Volume mit dem “/”-FS” gefragt und erhält auch noch das grafische Grub-Menu mit einer Auswahl an bootbaren Systemen. Der nachfolgende systemd-Start aus dem initramfs schlägt jedoch fehl. Die Fehler münden nach einem längeren Warten auf einen Time-Out schließlich in den Start einer “dracut”-Emergency-Shell mit zugehörigem Prompt.

Hier kann man aber manuell einen Versuch zur Korrektur der unvollständigen Konfiguration von initramfs und systemd unternehmen – ohne die langwierige Installation komplett wiederholen zu müssen.

Das, was ich nachfolgend beschreibe, kann aber auch nützlich sein, wenn man in späteren Stadien irgendwelche Fehler in die “/etc/crypttab” eingebracht hat – und man das System nicht mehr vollständig von seinen verschlüsselten LUKS-Volumes booten kann.

Mit FS kürze ich nachfolgend “Filesystem” ab.

Das Problem – “systemd-cryptsetup@luks.service not found”

Wurde die “/etc/crypttab” während der Installation nicht im (künftigen) “/”-FS angelegt oder hat sie fehlerhafte Einträge, so erhält man im nachfolgenden Boot-Vorgang Fehler-Meldungen der Art:

Failed to start systemd-cryptsetup@luks.service : Unit systemd-cryptsetup@luks.service not found.

Siehe auch die folgende Abbildung:
r

Nach einer länglichen Wartezeit (ca. 1 Minute) wiederholen sich (viele) Fehlermeldungen; nach weiteren 1 -2 Minuten erfolgt ein Schirmwechsel und man starrt auf einen blinkenden Cursor. Mit Ctrl-Alt-F7 wechselt man zurück zur grafischen Konsole und landet auf einem Dracut-Emergency-Shell Prompt. (Warum SuSE den Wechsel an dieser Stelle nicht selbst veranlasst, darf man mich nicht fragen …).

Diese Fehler sind auf einen fehlerhafte Konfiguration des initramfs, zugehörigem systemd und der systemd-Services im “/”-FS zurückzuführen. Ursache ist, dass “dracut” während der Installation im Zuge der von mkinitrd veranlassten Konfigurationsschritte keine Datei “/etc/crypttab” entdecken konnte.

Ich habe die oben dargestellte Situation übrigens erzwungen, indem ich aus einem voll boot- und lauffähigen System die “/etc/crypttab” gelöscht und danach mkinitrd ausgeführt habe. Ein nachfolgender Boot-Vorgang entspricht im Wesentlichen dem, was man bei einer fehlenden oder fehlerhaften “/etc/crypttab” im “/”-FS auch nach einer Installation erhält. Der Unterschied ist der, dass am Ende der Installation “mkinitrd” im Zuge eines chroot-Wechsels in das künftige “/”-FS ausgeführt wird (und nicht direkt im laufenden System).

Anlage oder Korrektur der “/etc/crypttab” im “/”-FS – Erneutes Ausführen von mkinitrd

Nun hat man zwei Möglichkeiten:

Alternative 1:Booten eines anderen Opensuse Systems und Erstellen der “/etc/crypttab” im künftigen “/”-FS der Installation
Diese Alternative hat den Vorteil, dass man auch ohne chroot vorab prüfen kann, was sich tatsächlich im initramfs befindet und was nicht. Oder man kann auch Sicherungen durchführen. Die Dracut-Emergency-Shell bietet dafür keinen hinreichenden Befehlsvorrat. Der Ablauf der Korrektur stellt sich dann wie folgt dar:

Ablauf: Booten eines anderen lauffähigen Systems (in unserem Fall von der vorhandenen internen SSD/HD des Laptops) => Öffnen des kryptierten LUKS-Volumes für das “/”-FS => Mounten des “/”-FS auf /mnt => Check des Inhalts des initramfs – ist eine /etc/crypttab vorhanden? => Anlage einer “/etc/crypttab” mit korrekten Einträgen > chroot /mnt => Ausführen von mkinitrd

mytux:~ # cryptsetup open /dev/vga/lva1 cr-root
Enter passphrase for /dev/vga/lva1: 
mytux:~ # # Mounten des kuenftigen Root-Filesystem auf /mnt - das Filesystem weist die nötigen Mount-Punkteauf 
mytux:~ # mount /dev/mapper/cr-root /mnt
mytux:~ # lsinitrd /mnt/boot/initrd -f /etc/crypttab
mytux:~ # lsinitrd /mnt/boot/initrd | less 
mytux:~ # # Nun wird die Datei /etc/crypttab angelegt  
mytux:~ # vi /mnt/etc/crypttab
mytux:~ # # Vorbereitung chroot-Umgebung 
mytux:~ # mount --rbind /dev /mnt/dev
mytux:~ # mount --rbind /proc /mnt/proc
mytux:~ # mount --rbind /sys /mnt/sys
mytux:~ # # chroot !
mytux:~ # chroot /mnt
sh-4.4# mkinitrd
....
DRACUT_MELDUNGEN
.....
sh-4.4# exit
mytux:~ # init 6 

Hinweis: Die Mapper-Bezeichnung sollte identisch zu der gewählt werden, die man während der Installation (s. den letzten Beitrag) gewählt hatte – und die Eingang in die Grub2-Konfiguration gefunden hatte (s. hierzu die Datei “mnt/boot/grub2/grub.conf”). In unserem Fall war das “cr-
root”.

Alternative 2:Direktes Arbeiten in der Dracut-Emergency Shell – Erstellen der “/etc/crypttab” im künftigen “/”-FS
Diese Alternative ist sehr ähnlich zur ersten. Man muss aber in einen chroot-Übergang in das künftige “/”-FS durchführen, um Befehle wie “lsinitrd” zur Inspektion des “initramfs” überhaupt nutzen zu können.

Ablauf: Anlage eines Verzeichnisses /mnt => Öffnen des kryptierten LUKS-Volumes für das “/”-FS => Mounten des “/”-FS auf /mnt => chroot => Inspektion initrd => Anlage einer “/etc/crypttab” mit korrekten Einträgen > mkinitrd

dracut/:# mkdir /mnt
dracut/:# cryptsetup open /dev/vga/lva1 cr-root
Enter passphrase for /dev/vga/lva1: 
dracut/:# mount /dev/mapper/cr-root /mnt
dracut/:# mount --rbind /dev /mnt/dev
dracut/:# mount --rbind /proc /mnt/proc
dracut/:# mount --rbind /sys /mnt/sys
dracut/:# chroot /mnt
sh-4.4# lsinitrd /boot/initrd -f /etc/crypttab
sh-4.4# lsinitrd /boot/initrd | less 
sh-4.4# vi /etc/crypttab
sh-4.4# mkinitrd
....
DRACUT_MELDUNGEN
.....
sh-4.4: /# exit
dracut/:# init 6

Der Inhalt der “/etc/crypttab” sollte in unserem Testfall wie folgt aussehen; siehe hierzu den vorhergehenden Beitrag:

cr-root    /dev/vga/lva1    none

Man erinnere sich daran, dass wir in dem bislang beschriebenen Vorgehen ein kryptiertes SWAP-Volume nicht benutzt haben (weder in Grub2 per resume-Parameter für den Kernel, noch in der /etc/fstab). Sollte dies bei euch anders sein, müsst ihr selbstverständlich auch einen passenden, konsistenten Eintrag zum SWAP-Volume in der “/etc/crapttab” verankern (z.B.: cr-swap    /dev/vgs/lvs1    none); siehe hierzu den nächsten Artikel dieser Serie.

Hinweise:
Auch hier ist die Mapper-Bezeichnung (cr-root) konsistent zu den Einträgen in der Grub2-Konfiguration zu wählen!

Reboot

Nach unseren Korrekturen sollte ein korrekter Reboot möglich sein:

Zwischenfazit

Leider unterstützt Opensuses Installer eine Installation von Leap 15 auf ein selbst vorbereitetes LUKS-Volume (LUKS on LVM) nicht vollständig; eine manuell angelegte Datei “/etc/crypttab” in der Installationsumgebung wird ignoriert und nicht in das künftige “/”-FS kopiert. Das führt zu Fehlern in der Konfiguration des “initramfs” und der dortigen systemd-Konfiguration (wie auch der systemd-Konfiguration im “/”-FS).
Wir können die Defizite des Installers aber im Nachhinein noch über die Dracut-Emergency-Shell korrigieren. Dabei
müssen wir auf korrekte Mapper-Bezeichnungen für die LUKS-Volumes in der manuell nachgeschobenen “/etc/crypttab” achten: Die “/etc/crypttab”-Einträge müssen konsistent zur Grub2-Konfiguration sein!

Im nächsten Beitrag
Laptop – SSD mit dm-crypt/Luks -Verschlüsselung und Opensuse Leap 15 – IX – Verschlüsselter SWAP
erweitern wir unsere Installation um einen kryptierten SWAP-Bereich.

Links

https://bugzilla.opensuse.org/show_bug.cgi?id=904987
https://lists.opensuse.org/opensuse/2017-08/msg00211.html
https://lists.opensuse.org/opensuse-factory/2016-02/msg00071.html
https://bugzilla.redhat.com/show_bug.cgi?id=1085562
https://github.com/systemd/systemd/issues/6381
https://unix.stackexchange.com/questions/43426/how-to-salvage-a-lvm-luks-install-from-custom-install