Hachja, das hat man davon, wenn man sich ein Geschoss kauft. Der arme Quad-Core kann gar nix dafür.
Ich hatte nämlich seit Einrichtung einiger verschlüsselter Partitionen das Problem, dass er mein Passwort nicht annehmen wollte, obwohl ich beim tippen genau aufgepasst hab, alles richtig einzugeben. Manchmal klappte es aber doch. Ich dachte das liegt nur am falschen Keyboard-Layout beim Booten, wobei ich dann einige Tasten im Kopf umbelegen musste, aber es stellte sich raus, dass auch mit richtigem Layout mein Passwort nicht sofort akzeptiert wurde.
Nach gut 2 Stunden googlen zu dem Thema und einem aufschlussreichem Bugreport, der mit meiner dmesg-Ausgabe korellierte, hatte ich die Lösung gefunden.
Denn dmesg sagte mir:
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-7112
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-7124
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-7124
Denn die Ursache ist udev. Udev schaut nämlich bei jedem auftauchenden Gerät irgendwo in /dev, ob es dazu eine Regel hat. Und in der Tat gibt es für den Device-Mapper spezielle rules, definiert in 64-device-mapper.rules.
Das Cryptsetup hat die Eigenart, jedes verschlüsselte Device bis zur Freigabe als /dev/mapper/temporary-cryptsetup-* anzulegen, was udev auch promt bemerkt, das Device nach /dev, nach z.B. /dev/dm-1 verlegt und in /dev/mapper einen Symlink dazu anlegt. Wenn das Passwort dann eingegeben wurde, erzeugt Cryptsetup das im Aufruf angegebene Device in /dev/mapper/ und löscht das temporäre Device wieder. Zumindest theoretisch. Denn udev hat das temporäre Device bereits wo anders hin verschoben und verlinkt. Somit lässt es sich nicht löschen und der Device-mapper meldet einen Fehler.
Abhilfe schafft ein Eintrag in die /etc/udev/rules.d/64-device-mapper.rules:
# ignore luks crypt devices while not fully up
ENV{DM_NAME}=="temporary-cryptsetup-*", NAME="", OPTIONS="ignore_device"
Dann klappts auch mit dem Verschlüsseln.
Scheinbar passiert das alles ganz kurz hintereinander und provoziert eine Race-Condition, denn so häufig ist der Bug noch nicht aufgefallen.
Update: Wie ich grade im Bugtracker von Gentoo gelesen habe, wurde mit device-mapper-1.02.22-r5 die rules-Datei etwas geändert, wodurch udev das Device nicht mehr nach /dev/dm* verschiebt, sondern nur noch per Symlink verlinkt. Das führt zwar zu ungültigen Links, wenn der Device-Mapper die temporären Devices wieder löscht, aber das ist besser als gar nicht zu funktionieren.
