Intro⌗

Es gibt Sachen, die man für selbstverständlich hält. Dazu gehört zum Beispiel, dass der eigene Computer nach einem Knopfdruck sofort hochfährt und einen mit seinem Lieblings-Hintergrundbild begrüßt.

Umso schlimmer, wenn das mal nicht funktioniert. Genauso ging es mir, als ich heute Morgen meinen treuen Laptop anwerfen wollte; Das Booten schlug fehl, ich konnte ihn einfach nicht mehr entschlüsseln. 🙃

Die Symptomatik⌗

Kurz zu meinem Setup: ich habe meine gesamte (Arch-Linux, btw.) root-Partition mit dm-crypt verschlüsselt und gebe die Passphrase beim Start immer in ein plymouth-prompt ein, welches nach dem UEFI-screen erscheint.

Konkreter: da steht immer “Enter password:”. Und potz blitz, auf einmal war das halt nicht mehr da. PANIK! Nun kann man den plymouth-screen ausblenden, wenn man kurz nach dem Erscheinen desselben die esc-Taste drückt. Und da stand bei mir dann halt folgendes:

ERROR: device '/dev/mapper/luksdev' not found. Skipping fsck.
mount: /new_root: special device /dev/mapper/luksdev does not exist.
You are being now dropped into an emergency shell.
sh: can't access tty; job control turned off

[rootfs ]$

Der absolute Albtraum, oder? Diese emergency-shell kann nämlich auch nicht wirklich irgendwas; es sind nur die absoluten GNU/Linux-Basics verfügbar. Beispielsweise blkid, womit man sich die UUIDs der verfügbaren Festplatten anzeigen lassen kann. (In dem Fall schon ein möglicher Punkt, an dem es scheitern kann. Gegebenenfalls reicht es, die UUIDs mit denen in den Kernel-parametern abzugleichen.)

Noch blöder aber, wenn man sich seinen Laptop vor Ewigkeiten (mehreren Jahren?) mittels eines archinstall-scripts aufgesetzt hat und nicht mehr wirklich einen Plan davon hat, was genau das eigene System zum ver- und entschlüsseln verwendet. (Denn tatsächlich scheint meine Arch-Installation einfach doch so stabil zu sein, dass ich sowas vergesse. Take that, haters!)

Es stellte sich heraus, dass ein Kernel-upgrade dafür gesorgt hat, dass die generierten initramfs-Images fehlerhaft waren. Deshalb, weil eine Hook während mkinitcpio nicht mehr gefunden wurde. In diesem Fall war das die plymouth-crypt-Hook. Und sowas steht so auch eigenlich in der Konsolenausgabe während mkinitcpio:

==> Warning: Error during initramfs generation, image may be incomplete

Oder so in der Art. Und die muss man halt lesen. Und das habe ich wohl nicht gemacht.

Leuten, die jetzt anfangen ihr System neu aufzusetzen, (auch ich habe mit dem Gedanken gespielt!) sei jetzt folgendes gesagt: es gibt andere Wege. 😉 Denn in dem Moment, in dem ihr einen USB-Stick mit einem Arch-Image besitzt, (der vielleicht eigentlich zum Neuaufsetzen des Systems gedacht war) hab ihr ein Werkzeug, welches die Tools zur Rettung eures verlorenen Systems mitbringt.

Falls man im Ausland sitzt und der besagte Computer die einzige Möglichkeit wäre, einen solchen Stick zu kreiren, säße man natürlich in der Pampe. In so einem Fall bleibt wohl wirklich nichts anderes übrig, als nach einem freundlichen Samariter Ausschau zu halten, welcher einem einen solchen Usb-Stick erstellen kann.

Jetzt aber genug reflektiert; Ran an die Lösung des Problems:

Die Medikation⌗

-> Den USB-Stick booten.

Sollte nicht allzu schwierig sein.

-> Festplatte entschlüsseln und einhängen.

$ cryptsetup luksOpen /dev/meineRootPartition luksDevice

Und Passphrase eingeben. Natürlich muss hier die im eigenen Fall richtige Datei angegeben werden; Also soetwas wie /dev/sda2 für Festplatten oder /dev/nvme0n1p2 für NVMe-SSDs.

$ mkdir luksMountpoint
$ mount /dev/mapper/luksDevice luksMountpoint

Somit wäre die root-Partition eingehängt. Da jetzt aber die initramfs-images auf der boot-Partition liegen, muss für mkinitcpio auch diese noch eingehängt werden:

$ mount /dev/meineBootPartition luksMountpoint/@/boot

In meinem Fall war das analog zu /dev/nvme0n1p2 für den ersten Schritt eben /dev/nvme0n1p1. Der Mountpoint ist in diesem Fall esp (hier: /boot) des neu eingehängten root-Verzeichnisses.

-> Ins neue root chroot-en

$ arch-chroot luksMountpoint/@/

Und schon ist man (quasi) wieder online und kann anfangen, sein eigentliches System zu debuggen.

-> mkinitcpio

$ mkinitcpio -P

Ist der bereits erwähnte Befehl zur Erzeugung der eventuell relevanten Fehlermeldungen. Für den Fall dass hier des Fehlers Ursprung liegt, kann man die angegebenen Hooks der mkinitcpio-Konfiguration anpassen:

config /etc/mkinitcpio.conf


HOOKS=(base udev plymouth plymouth-encrypt autodetect keyboard keymap modconf block filesystems fsck)

Wie schon erwähnt hat es bei mir gereicht, plymouth-encrypt durch encrypt zu ersetzen. Das rührt wohl daher, dass das encrypt-Modul einzug in den Kernel gehalten hat. Ein erneutes Ausführen von $ mkinitcpio -P sollte nun nicht mehr einen auf fehlerhafte Hooks Bezug nehmenden Fehler werfen. Bei mir gab es noch einen: Error: original root could not be found. Den habe ich ignoriert. 😜

-> Cleanup - wahrscheinlich wichtig!

Ein guter System-Hausmeister räumt hinter sich auf. Das geht in diesem Fall so:

$ exit                              # chroot verlassen
$ sync                              # immer gut bei externen medien
$ umount luksMountpoint/@/boot      # /boot aushängen
$ umount luksMountpoint             # / aushängen
$ cryptsetup luksClose luksDevice   # Gegenstück zu luksOpen