[DE] 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]

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]

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]

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]


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