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.
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
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
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:
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:
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:
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
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
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!):
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.
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.
Hallo,
vielen Dank für eure Hilfe :D - 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?
riepernet ist noch erreichbar.
greetz
devil
Quote from: "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.
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