Die Upgrade Warnung für User mit verschlüsselten Festplatten ist nach wie vor aktuell.
Deshalb möchte ich meinen Workaroud, den ich mit sachkundiger Unterstützung aus dem IRC-Channel gefunden hab, hier skizzieren.
Die Ausgangssituation: Eine Festplatte mit zwei physikalischen Partitionen (sda1 und sda2). sda1 ist eine kleine, unverschlüsselte Partition, die /boot/ beherbergt und sda1 den Rest der HD. Diese Partition ist verschlüsselt mit luks. In der verschlüsselten Partition verwaltet lvm den Platz und enthält mehrere logische Volumes, u.a. root / und swap.
Mein System bootete nach einem dist-upgrade nicht mehr, ich kam nicht einmal mehr bis zur Passwortabfrage. Die Lösung des Problems hat graver am 24.10.2014 in diesem thread veröffentlicht und verweist auf die Datei /usr/share/doc/crtyptsetup/README.initramfs. Allerdings ist sein Vorgehen etwas anders als in der angegebenen Datei: Graver fügt die Zeile
cryptroot /dev/mapper/vg-crypt none luks
in die Datei /etc/crypttab ein. In der o.a. Datei README.initramfs sieht die Zeile so aus:
cryptroot /dev/sda2 none luks
Warum die von graver angegebene Zeile die richtige ist, weiß ich nicht, aber bei mir hat es funktioniert.
Ich beschreibe nun das Vorgehen, mit dem ich mein System wieder zum Laufen bekam, ausgehend von einem gebooteten Live-System.
1. Man werde in einer shell (ich hab ein tty benutzt) zum superuser:
$ su
2. Das root-Verzeichnis aus dem verschlüsselten Container einbinden:
# cryptsetup luksOpen /dev/sda2 geheim
Dabei ist geheim der Name, mit dem der verschlüsselte Container beim mapper angemeldet wird. Es wird später wichtig, dass hier der selbe Name gewählt wird wie im regulären System. Falls man diesen Namen nicht parat hat: In den Ausgaben und Fehlermeldungen beim (erfolglosen) Bootvorgang des darniederliegenden regulären Systems findet man den Namen. Ist nun die Entschlüsselung vollzogen, müssen noch die logischen Volumes aktiviert werden:
# vgscan
# vgchange -a y
Nun sollte man in /dev/mapper neben dem Cryptocontainer auch die logischen Volumes finden und mounten können.
# mount /dev/mapper/meinevolumegroup-meine_rootpartition /mnt
Eventuell müssen hier noch spezielle Optionen fürs Dateisystem angegeben werden, bei den ext-Dateisystemen ist das aber meist nicht nötig.
3. Das reguläre System mit chroot betreten
Die root-shell ins reguläre System will gut vorbereitet sein, /sys/, /proc/, /dev/ und /boot müssen eingebunden werden:
# mount /dev/sda1 /mnt/boot/
Die physikalische Bootpartition muss auch dann eingebunden werden, wenn sie nach dem Einbinden des Volumes mit dem rootverzeichnis vorhanden zu sein scheint, selbst dann wenn /boot/ bzw. /mnt/boot/ gefüllt ist/gefüllt zu sein scheint mit allem, was man in /boot/ erwartet.
# mount -o bind /dev/ /mnt/dev/
# mount -o bind /proc/ /mnt/proc/
# mount -o bind /sys/ /mnt/sys/
Nun kann man das reguläre System betreten:
# chroot /mnt/
4. Die eigentliche "Reparatur"
In die Datei /etc/crypttab trägt man die folgende Zeile ein:
cryptroot /dev/mapper/geheim none luks
Der vorletzte Eintrag steht für ein mögliches keyfile, bei mir eben keins.
In der root-shell muss nur dieser eine Befehl abgesetzt werden:
# update-initramfs -c -k 3.15-1.towo-siduction-amd64
Für update-initramfs kann man -c für create oder -u für update verwenden. Bei -c versagt update-initramfs den Dienst, wenn für den Kernel schon ein entsprechendes initrd-file vorhanden ist, man müßte also das alte initrd-file verschieben/umbenennen.
Hat man bereits update-initramfs -c -k eingegeben, funktioniert die aus der shell bekannte und beliebte tab-kompletion, so dass man aus der Liste der vorhandenen Kernel auswählen kann.
Es kommt hier zu Fehlermeldungen, wenn der Container in /etc/crypttab nicht genauso heißt wie der in /dev/mapper/, weshalb beim Einhängen mit cryptsetup (s.o.) der gleiche Name wie im Standardsystem verwendet wurde.
update-initramfs gibt auch im Erfolgsfall Warnungen von mdadm aus, die aber getrost ignoriert werden können, sofern man kein raid-system oder ähnliches hat, auf jeden Fall aber, wenn man nur eine HD im Rechner hat.
Kommen also nur diese Warnungen von mdadm, dann kann man die rootshell und das Live-System verlassen und wie gewohnt das reguläre System booten.