Problem mit lvm-full-disk-encryption bei sidux "DebianW

[kuchenfreund_in]

Hallo,

wir versuchen seit 3 Tagen sidux-2010-01 mit der Installationsanleitung vom sidux-wiki (http://sidux.com/index.php?module=Wikula&lang=de&tag=deFullDiskEncryptionTheDebianWay) auf ein Netbook zu installieren.

Beim reboot (nach Vorbereitung, Installation von sidux und Installationsnachbereitung) wird weder die Volume group "cryptVG" gefunden noch das LVM volume "cryptVG/root", bzw. fragt auch gar nicht erst nach dem Passwort. nur ein blinkender Curser erscheint wo wir zwar irgendetwas hinschreiben können, was jedoch keine Auswirkungen hat. Schreiben wir nix hin und warten, kommt irgendwann "Gave up waiting for root device..." und es erscheint "job control turned off" und (initramfs) mit blinkendem curser...

Unsere Versuche, eine Fehlerbehandlung dann über die Live-CD nachträglich vorzunehmen sind alle gescheitert. Wir haben bereits etliche Zusätze zu der sidux-Anleitung ausprobiert, doch bisher erfolglos. Wir finden auch trotz Recherche in Wikis, Foren etc. kein gleiches Problem, bzw. keine wirkliche Lösungsmöglichkeit bisher.

Über Hilfe würden wir uns freuen. Für weitere Infos, die von unserer Seite aus kommen sollen, sagt bitte was gebraucht wird zur Analyse.

:?:  :?:  :?:

--> Wir haben eine Lösung gefunden. Dieser Thread gilt damit vorerst als gelöst
Infos, wie wir das denn gemacht haben, dass es doch klappte, stellen wir bald rein.

[devil]

wiki ist userbased, veraltet schnell, wird oft nicht gepflegt.
wir haben vom team her keine kapazitäten, das zu ändern.
soviel zu wiki.
mit deinem problem würde ich mal mein glück im irc in #aptosid versuchen.
ich habe keine ahnung von encryption

greetz
devil

[bluelupo]

Hallo kuchenfreund_in,
ist den VG bzw. das LV wirklich angelegt? Schau doch mal vor dem ersten Reboot (im Live-Modus) mit den Kommandos vgdisplay bzw. lvdisplay nach.

EDIT: Hier noch ein paar alternative Links zur Verschlüsselung von Disks.

http://www.andreas-janssen.de/cryptodisk.html
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2006/10/Mobiler-Datentresor
http://wejn.org/how-to-make-passwordless-cryptsetup.html

[kuchenfreund_in]

Hallo,
danke für die Antworten.
Im irc ist uns noch unklar, wer wann welches Thema anfangen kann...(haben damit null Erfahrung)

So, wir haben jetzt die sidux-Live CD wieder eingeworfen und haben folgendes getan:

Code Select Expand

root@sidux:~# mkdir /media/sidux
root@sidux:~# cryptsetup luksOpen /dev/sda2 sda2_crypt

Dann haben wir einen pvscan und einen vgscan gemacht; hier die Resultate:

Code Select Expand

root@sidux:/home/sidux# pvscan
 PV /dev/dm-0   VG cryptVG   lvm2 [148,79 GiB / 0    free]
 Total: 1 [148,79 GiB] / in use: 1 [148,79 GiB] / in no VG: 0 [0   ]
root@sidux:/home/sidux# lvscan
 inactive          '/dev/cryptVG/swap' [2,00 GiB] inherit
 inactive          '/dev/cryptVG/root' [146,79 GiB] inherit


vgdisplay und lvdisplay kannten wir noch nicht, haben es aber im Anschluss ausgeführt:

Code Select Expand

root@sidux:/home/sidux# vgdisplay
 --- Volume group ---
 VG Name               cryptVG
 System ID            
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  3
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                2
 Open LV               0
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               148,79 GiB
 PE Size               4,00 MiB
 Total PE              38089
 Alloc PE / Size       38089 / 148,79 GiB
 Free  PE / Size       0 / 0  
 VG UUID               GOXTrK-raP8-KEEK-DPIE-1601-Hb9e-AtnITI
 
root@sidux:/home/sidux# lvdisplay
 --- Logical volume ---
 LV Name                /dev/cryptVG/swap
 VG Name                cryptVG
 LV UUID                OZlUl1-mjOV-ovRq-tnQ0-iLQR-N65N-mkSEGS
 LV Write Access        read/write
 LV Status              NOT available
 LV Size                2,00 GiB
 Current LE             512
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 
 --- Logical volume ---
 LV Name                /dev/cryptVG/root
 VG Name                cryptVG
 LV UUID                Q2cneN-v6RQ-CZQ2-ThEB-Bk0T-fNh3-FcZigu
 LV Write Access        read/write
 LV Status              NOT available
 LV Size                146,79 GiB
 Current LE             37577
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 

Anscheinend haben wir VG und LV angelegt, doch was die Ausgabe bedeutet...keine Ahnung.
Das problem ist, dass beim booten das Passwort nicht abgefragt, bwz. die groups nicht gefunden werden.
Fehlt etwas im /boot?

Vielen Dank,
kuchenfreund_in

[devil]

im irc sagt man nett:
guten tag, ich hätt mal gern ein problem mit verschlüsselung.
dann sagt ein gut gelaunter supporter: wir verschlüsseln keine probleme.
und schon gehts los...

greetz
devil

[hefee]

naja dieses problem besteht leider schon seit mehreren Wochen *grmpf*

Das Problem ist, das udev/LVM oder irgendso ein schnösel ( im debian bugtracking sind sie sich auch nicht sicher wer hier das fixen muss) erstellt für das gestartete System den entsprechenden Eintrag unter /dev/disk/by-uuid nicht! Also prüfe nach, ob alle UUIDs unter /dev/disk/by-uuid da sind.

Ein Workaround ist (UUID ist die UUID der root platte- entschlüsselt!):

Code Select Expand


cd /dev/disk/by-uuid
ln -s /dev/cryptVG/root UUID
update-initramfs -u -k all


Da leider jedes update-initramfs fehl schlägt ist es empfelenwert, das erstellte initramfs auch nochmals auf die bootfestplatte zu kopieren um nach einem du wieder starten zu können.

[vuj]

Kann es nicht bestätigen, das es mit verschlüsselten Systemen unter sidux-2010-01 (32 und 64) Probleme gab das einzige was sich zum wikieintrag geändert hat war das vor dem ausführen des installers  von sidux (aptosid) noch ein vgscan ausgeführt werden muss.

[kuchenfreund_in]

Hallo,

vielen Dank für eure Hilfe - aus den Bruchstücken von vielen Ideen und Infos, klappt es doch meist ganz gut einer Lösung auf die Spur zu kommen (keine Ahnung ob das so immer der eleganteste Weg ist, aber immerhin...).

Schätzungsweise wäre es noch ganz gut, zu schildern,  wie wir diese Lösung produziert haben. Dies wird in den nächsten Tagen nachgeholt! (Hoffentlich...)

Ich weiß zwar nicht ob es überhaupt noch interessant ist, da durch Erscheinen von aptosid-2010.02 alles wieder anders sein kann (wir nahmen ja noch sidux-2010.01; als wir anfingen war ja das neue Image noch nicht da ... erst am nächsten Tag), doch wenn sich in der Hinsicht der Probleme nichts geändert hat, stellt das doch vielleicht eine Hilfe dar.

Vielleicht komme ich auch noch dazu in den nächsten Wochen das mal mit aptosid-2010.02 zu testen. Dementsprechend könnte ja auch der sidux-wiki-Eintrag von <riepernet> auf aptosid.de wandern und gegebenenfalls aktualisiert werden. Ist <riepernet> noch aktiv bzw. erreichbar für Rückfragen zum wiki-beitrag?

[devil]

riepernet ist noch erreichbar.

greetz
devil

[hefee]

Kann es nicht bestätigen, das es mit verschlüsselten Systemen unter sidux-2010-01 (32 und 64) Probleme gab das einzige was sich zum wikieintrag geändert hat war das vor dem ausführen des installers  von sidux (aptosid) noch ein vgscan ausgeführt werden muss.

naja bei mir ging auch alles gut, bis ich eine neue Platte eingebaut habe und damit natürlich die UUIDs sich geändert haben. Obwohl ich brav in der fstab und crypttab die UUIDs angepasst habe, hat er sich trotzdem geeweigert zu booten.

Hier mal einer der bugs, die das problem sind: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595157