# [SOVED]Verschlüsseltes System startet nach Update nicht mehr

## Niethi

Hallo 

Im Moment habe ich ein größeres Problem:

Seit dem heutigen "emerge -uDN world" lässt sich mein komplett mit cryptsetup und Luks verschlüsseltes System nicht mehr starten.  :Sad: 

Zunächst nimmt er noch das erste Passwort für die root Partition an, auf der dann der key für die restlichen Partitionen liegt.

Danach verabschiedet er sich jedoch für die folgenden Partitionen mit dem Fehler

 *Quote:*   

> failed to setup dm-crypt key mapping
> 
> Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sdax contains at least 258 sectors.
> 
> Failed to read from key storage
> ...

 

was natürlich dann eine Fehlerlawine folgen lässt.   :Evil or Very Mad: 

Ich wäre sehr dankbar, wenn mir jemand weiterhelfen könnte.Last edited by Niethi on Tue Dec 18, 2007 1:57 pm; edited 1 time in total

----------

## Anarcho

War bei deinem update auch ein Kernelupdate dabei? Wenn ja, vielleicht ist dort bei der Konfiguration was fehlerhaftes drin bzw. was vergessen?

----------

## Finswimmer

 *Niethi wrote:*   

> Hallo 
> 
> Im Moment habe ich ein größeres Problem:
> 
> Seit dem heutigen "emerge -uDN world" lässt sich mein komplett mit cryptsetup und Luks verschlüsseltes System nicht mehr starten. 
> ...

 

Evtl hat sich auch einfach "nur" das Device für die Root Partition geändert?

BTW: Welches init Skript verwendest du? Geht bei dir der Splash?

Tobi

----------

## WiredEd

Exakt das gleiche Problem hatte ich auch, nachdem ich damals auf 2.6.22-r9 upgedatet habe: Ich hatte 3 verschlüsselte Partitionen (sowohl SATA- als auch PATA-Platten). Die Keyeingabe lief bei mir manuell, d.h. beim booten wartete das System immer geduldig auf meine Passphrase. Nach dem Kernel-Update war es sporadisch dann so, dass LUKS oft für eine  der drei Partitionen genau den gleichen Fehler wie bei Dir meldete. Bisweilen waren 3 Bootvorgänge notwendig, bis mal keine der Partitionen Fehler meldete. Danach lief das System aber ganz normal und stabil.

Da ich den Fehler nicht nachvollziehen konnte und es mir auch vorkam, dass ich der einzige Mensch auf der Welt mit dieser Fehlermeldung war, habe ich durch Umkopieren eine Partition nach der anderen wieder "entschlüsselt". Das war mir dann doch zu heikel. Seit dem warte ich selber auf eine Erklärung dafür. Es waren aber sicher nicht vertauschte Devices oder so. Das konnte ich schon ausschliessen.

BTW: Booten von Knoppix/Ubuntu-Live-CD und manuelles mounten der verschlüsselten Partitionen hat bei mir immer ohne Fehler funktioniert. Die Chancen stehen also gut, dass Deine Daten nicht verloren sind.

----------

## Niethi

Ersteinmal vielen Dank für die Antworten.

Ich habe jetzt mehrmals das System neu gestartet, da mir aufgefallen war, dass er wohl doch einen Teil der Partitionen entschlüsselt hat.

Welche das sind scheint jedoch zufällig zu sein. 

Geradeeben habe ich einmal händisch

cryptsetup -d /keyfile luksOpen /dev/sdax decryptusr 

versucht. Dieses führte beim ersten Versuch zu obiger Fehlermeldung, beim gleich folgenden zweiten (alte Windowskrankheit alles mehrmals zu probieren wenn es nicht tut    :Rolling Eyes:  ) kam dann 

"key slot 1 unlocked"   :Surprised: 

Nachdem ich nun nach einigen Fehlversuchen auch endlich an die Dateien und Logfiles komme zu euren Fragen:

Die neuen gentoo-sources 2.6.23r3 sind zwar emerged worden, jedoch zeigt ein eselect kernel bzw. ls -l /usr/src/, dass der symlink noch auf den alten 2.6.20r8 kernel zeigt, der auch vom initscript aufgerufen werden sollte.

Mit dem initscript kenne ich mich leider nicht aus.

Ich bin beim Aufsetzen des Systems folgender Anleitung gefolgt, wobei ich den raid und evms Part weggelassen habe.

http://gentoo-wiki.com/HOWTO_Setup_fully_crypted_Gentoo_on_EVMS#Genkernel

Die Startzeile in der grub.conf lautet

 *Quote:*   

> kernel /kernel-2.6.20-gentoo-r8-bridge root=/dev/ram0 init=/linuxrc ramdisk=8192 crypt_root=/dev/sday real_root=/dev/mapper/root
> 
> initrd /initramfs-genkernel-x86_64-2.6.20-gentoo-r8

 

----------

## schachti

Welche Version von cryptsetup hast Du installiert? Welche Pakete wurden denn neu installiert, seitdem es das letzte Mal ohne Probleme ging?

Evtl. mal die aktuelle Version von cryptsetup emergen und anschließend einen aktuellen Kernel kompilieren und die initrd neu bauen (mit der aktuellen Version von cryptsetup).

----------

## Niethi

Tja das letzte Upadte beinhaltete 316 Merges   :Shocked:  - hatte bis dahin immer nur die GLSAs durchgeführt ... 

cryptsetup-luks ist nun momentan in der Version 1.0.4-r3 installiert und war nach einem schnellen Blick mittels

grep cryptsetup-luks /var/log/emerge.log

komischerweise nicht vom Update betroffen. 

Werde trotzdem einmal einen neuen Kernel kompillieren und die initrd neu bauen.

Dazu noch eine kurze Frage: Sollte ich das per live CD machen oder geht das auch in dem halb gestarteten "kaputten" System nach manuellem mounten der Partitionen ohne Bedenken?

----------

## zworK

Ich hatte vor längerem ähnliche Probleme mit verschlüsselten Partitionen.

Root-Partition eingebunden über initramfs. Die restlichen Partitionen werden über /etc/conf.d/cryptfs eingehängt.

Nach einem World-Update hätte ich sporadisch die gleichen Fehlermeldungen wie du. Mal wurden alle Partitionen durch LUKS geöffnet, mal nur eine, mal keine.

Die Wurzel des Übels war das sys-fs/device-mapper Update von Version 1.02.19-r1 auf 1.02.22-r5.

Zum Glück hatte mein Update nur 4-5 Pakete, daher war es leicht, den Schuldigen zu finden  :Smile: 

Nach einem Downgrade auf 1.02.19-r1 war das Problem wieder verschwunden.

Daher mein Tipp: Downgrade von device-mapper auf Version 1.02.19-r1.

----------

## Niethi

Vielen Dank für den Tipp zworK!

Das war's! Merge Nr. 5 von 316 als Übeltäter entlarvt!  :Laughing: 

Der Downgrad auf device-mapper-1.02.19-r1 hat das Problem jedenfalls behoben und es funktioniert wieder alles   :Very Happy: 

Habe gerade noch unter bugs.gentoo.org nachgeschaut und da gibt es wohl ein Problem mit udev 115-r1 - das Merge Nr. 42 bei mir war ...

https://bugs.gentoo.org/show_bug.cgi?id=201085

Werde also erstmal keinen Bugreport ausfüllen, da das Problem ja wohl unter anderem Namen schon bekannt ist   :Razz: 

Nochmal vielen Danke für eure Hilfe!

----------

