Installation: LVM auf verschlüsselter LUKS-Partition

[photor]

Hallo Forum,

ich habe versucht meinen Desktop-Rechner neu aufzusetzen; die Festplatte war ungünstig aufgeteilt. Dabei habe ich versucht ein "voll"verschlüsseltes System zu realisieren:

• sdb1: ext2 als /boot
• sdb2: LUKS-verschlüsselt; darin sollen folgende Partitionen in einem LVM liegen
  • / (root) ext4
  • /var ext4
  • SWAP
  • /home ext4

Aufgesetzt habe ich das ganze mittels einer GRML-CD;

• sdb1 ist formatiert;
• sdb2 ist mittels cryptsetup luksFormat /dev/sdb2 Worf verschlüsselt
• ein LVM ist eingerichtet und die Partitionen formatiert
• die Partitionen sind entsprechend an /mnt zusammengemountet
• debootstrap --arch amd64 stable /mnt ftp://ftp.de.debian.org/debian/
• chroot /mnt /bin/bash und das Grund-System aufgebaut
• (dummerweise?) update auf testing

Soweit alles gut. Wenn ich aber jetzt versuche, das System zu booten, wird das rootfs nicht gefunden und ich lande in der busybox. Das passiert mit kernel 3.2 (von der stable-Installation als auch mit 3.9.1 aus testing). Ich habe einen Bug-Report gefunden, der genau das beschreibt - allerdings nur für Kernel 3.9.1, wenn ich das richtig verstanden habe. Daher der Versuch mit 3.2.

So langsam zweifle ich, ob sich das oben beschrieben Szenario (LVM auf LUKS) mit Debian realisieren lässt. In meinem Laptop tut ein ähnliches (LUKS auf einer LVM-Home-Partition) unter ArchLinux.

Dankbar für ein paar Tipps.

Photor

[Cae]

Kannst du in der initrd in die lvm-Shell gehen?

Code: Alles auswählen

(initrd)# lvm
lvs
... (nix zu sehen)
vgchange -ay
... (sinngemaess volume group blah started)
^D
(initrd)# ^D
... (bootet)

Wobei mir gerade einfaellt, dass du wohl vorher noch den LUKS-Container aussenrum aufmachen musst. Vielleicht hattest du das nicht in der /etc/crypttab eingestellt (oder wo auch immer das noetig ist).

Gruss Cae

[photor]

Hallo Cae,

danke für die schnelle Antwort. Hatte den Rechner schon in's Wochenende schalfen geschickt. Also nochmal schnell angeworfen, um den genauen "Wortlaut" der Fehlermeldung aufzuschreiben: nach dem Grub-Menu kommt folgendes:

Code: Alles auswählen

Loading, please wait ...
  Volume group "Worf" not found
  Skipping volume group Worf
Unable to find LVM volume Worf/root
Unlocking the disk /dev/sdb2 (Worf)
Enter passphrase:

Das scheint mir soweit auch sinnvoll. ROOT wird nicht gefunden, dafür ein LUKS-Device -> also das öffnen und weiter schauen. Also Passphrase eingeben.

Und jetzt wird es seltsam: nach Eingabe der Passphrase - bootet des System jetzt tatsächlich! Ich weiß nicht, warum er das jetzt tut, nachdem er vorher (= den ganzen Abend schon) genau das nicht tat und ich die grml-CD nutzen musste, um an das System zu kommen.

Ich probiere weiter. Wenn der Zustand jetzt stabil ist, trotzdem "Danke"; wenn nicht komme ich bestimmt mit mehr Infos wieder.

Schönes WE,

Photor

[schorsch_76]

Da fehlt der early cryptsetup.

/etc/crypttab anlegen

Code: Alles auswählen

sdxy_crypt UUID=xxxx-xxx-xxx none luks

Code: Alles auswählen

aptitude install lvm2 cryptsetup

Gruß
schorsch

[photor]

Hallo schorsch_76,

Jau. Tut auch mittlerweile - stabil, hoffe ich Zwischenzeitlich war das mal anders, warum kann ich Dir nicht sagen.

cryptsetup war installiert und die cryptab mittels grml angelegt.

Danke allen, für die Hilfe. Rechner läuft wieder; alles gut

Photor

[photor]

Hallo Forum,

da bin ich wieder, weil ich gerade festgestellt habe, dass unter Kernel 3.2.0-4-amd64 schön gebootet wird (mit Schlüsselabfrage etc), unter Kernel 3.9-1-amd64 lande ich wieder im oben beschriebenen Szenario Warum? Beide Kernel wurden mit Aptitude installiert und ich hätte gedacht, dass bei der Installation von Kernel-Paket 3.9 eine passende Initrd gebaut wird.

Die /etc/crypttab enthält folgendes für den LUKS-Container, der dann /, /var und SWAP beherbergt:

Code: Alles auswählen

# <target name> <source device>         <key file>      <options>
Worf            /dev/sdb2               none            luks

(Gott sei Dank hatte ich diesmal den 3.2er Kernel als Backup )

Ciao,

Photor

[NAB]

Ich verstehe nicht, warum du es dir so umständlich machst. LVM auf dm-crypt beherrscht der Debian-Installer seit etlichen Versionen.

Aber egal ... hilft dir ein "update-initramfs -u -k all"? (mit Start durch Kernel 3.2)

[photor]

Moin,

Nee - eher im Gegenteil: jetzt bootet auch der 3.2er Kernel nicht mehr, weil er das LUKS-Device nicht findet.

wenn ich mit fdisk auf die Platte schaue, muss ich ihm auch recht geben:

Code: Alles auswählen

# fdisk /dev/sdb
Device      Boot               Id       System
/dev/sdb1     *                 83      Linux
/dev/sdb2                       83      Linux

Ich frage mich, wie das passiert ist? Und ob es helfen würde, die Id auf "8e" "Linux LVM" zu setzen?

Die Daten sind gebackupt. Allerdings hat es schon gedauert, die wieder aufzuspielen; die Zeit würde ich mir gerne sparen. Mal abgesehen davon, dass ich immer noch nicht verstanden habe, warum der Rechner die Probleme mit dem LVM in einer verschlüsselten Partition hat.

Ciao,

Photor

[NAB]

Ehm ... nun mal langsam. Meines Wissens gibt es immer noch keinen Partitionstyp für "cryptsetup", insofern ist "linux" genau richtig. In sdb2 sollte ein Luks-Container stecken, kein LVM. Das LVM steckt im Luks-Container.

Aber zurück zu deinem Problem ... irgendwas muss dir bei der Installation von Kernel 3.9 die initramfstools gründlich zerschossen haben, was dann auch zu einer kaputten initramfs für den Kernel 3.2 führte. Ich weiß nicht genau, wie du das angestellt hast ... bei mir läuft der Kernel 3.9 aus den Backports völlig problemlos .. mit Raid und Crypto (aber ohne LVM).

Hast du noch ein Backup deiner alten initrd von Kernel 3.2? Sonst musst du wohl mit "cryptsetup luksOpen" und "lvchange" in dein System und die Sache mit chroot reparieren ...

[photor]

Hallo NAB,

stimmt. War mir auch später noch aufgefallen (war doch schon spät - und auf meinem Lappy ist es so eingerichtet).

Aber: der Fehler ist reproduzierbar. Ich hatte den Verdacht, dass es eventuell an der nicht mehr neuen Platte liegen könnte und habe mir eine neue zugelegt (hätte sowieso angestanden, also dann eben jetzt). Die habe ich diesmal so formatiert:

Code: Alles auswählen

/dev/sda1   /boot
/dev/sda2   LVM

Im LVM eine Partition für ROOT, /var, /home und SWAP (und noch einiges an freiem Platz). /home wird mit LUKS verschlüsselt.

Die Vorbereitung (Partitionierung, Formatieren, LUKS etc) wurde von GRML aus gemacht und dann ein Debian STABLE gebootstrapt. Dieses ließ sich auch ganz normal booten. Also bis hierher alles gut.

Dann habe ich ein dist-upgrade auf TESTING gemacht (kernel 3.2 wird auf 3.9 angehoben) und weiter installiert. Ein Reboot brachte wieder das Obige. Zu Fuß lässt sich das System "zusammen stöpseln" (ich schreibe den Eintrag von dem System). Aber ich würde schon gerne ganz normal booten können. Aber irgendwie scheint die Initrd nicht alle zum booten wichtigen Tools zu enthalten. Hat es Sinn, sich genauer mit den Configs für Initrd zu beschäftigen.

PS: grundsätzlich sollte die Kombi LVM, LUKS und Kernel 3.9 funktionieren; mein Lappy läuft unter ArchLinux genau in der Konfiguration.

Dankbar für jede Hilfe,

Photor

[NAB]

Photor, wie schon ganz am Anfang geschrieben ... mach es dir doch leicht! Nimm dir ne normale aktuelle Debian 7.1 Installations DVD und richte ein verschlüsseltes System ein (LVM packt er dir dann automatisch drauf).

Dann trägst du die Debian Backports für Wheezy in deine Quellen ein und installierst dir den Kernel 3.9.

Wie es mit Testing steht, weiß ich nicht, da kann ja alles mögliche vorrübergehend kaputt gehen. Aber die Entwickler freuen sich bestimmt über einen Bug-Report, ich tippe mal auf die initramfs-tools.

Wobei ... eigentlich gibt's da auch schon etliche passende:
http://bugs.debian.org/cgi-bin/pkgrepor ... amfs-tools

[photor]

Hallo NAB,

Wie es mit Testing steht, weiß ich nicht, da kann ja alles mögliche vorrübergehend kaputt gehen. Aber die Entwickler freuen sich bestimmt über einen Bug-Report, ich tippe mal auf die initramfs-tools.

Wobei ... eigentlich gibt's da auch schon etliche passende:
http://bugs.debian.org/cgi-bin/pkgrepor ... amfs-tools

Ich habe entschieden, erstmal so weiter zu "leben". Du hast recht, ich habe schließlich Testing installiert; da kann schon mal was kaputt gehen. Wenn ich weiß. dass es nicht an meiner Installation liegt, sondern ein Bug ist und irgendwann gefixt wird, kann damit auch leben.

Danke allen, die mir geholfen haben,

Photor

[NAB]

Du kannst es als Notlösung mit einem downgrade auf die initramfs-tools aus den Wheezy-Backports versuchen. Wohlgemerkt "versuchen" ... ich hab keine Ahnung, was bei Testing gerade kaputt ist, es kann auch sein, dass dieser Versuch deine Installation ins Nirvana schießt.

[photor]

Moin NAB,

und genau das ist mir zu unsicher. Der Rechner läuft eigentlich immer durch. Und die paarmal, die erbis zum Fix gebootet wird, mach ich das eben zu Fuß.

PS: vielleicht sehe ich das in ein paar Wochen ja anders

Ciao,

Photor