[Gelöst] Verschlüsseltes System einhängen.

[ottonormal]

Hallo,

manchmal muss ich auf die Daten eines verschlüsselten Debians auf diesem Rechner von einem anderen Debian auf dem selbem Rechner aus zugreifen. Wenn ich dann in Thunar, oder einem anderen Dateimanager, die verschlüsselte Partition einhängen will, werde ich zur Eingabe der Passphrase und anschließend des root-Passwortes aufgefordert. Anschließend bekomme ich die Meldung:

Code: Alles auswählen

Der Datenträger "20 GB verschlüsselt" konnte nicht eingehängt werden.
Das entsperrte Gerät enthält kein erkennbares Dateisystem.

Mache ich das in Linux-Mint auf diesem Rechner, funktioniert das problemlos. Ebenso von einer Ubuntu-Live-DVD aus.
Warum geht das bei Debian nicht?

Es geht mir dabei um die Sicherung der Daten, bzw. ein Backup, welches ich von außen von dem System machen möchte.
Ich habe mich deshalb mal etwas mit qt4-fsarchiver beschäfftigt, das gefällt mir recht gut. Ist es eigentlich auch möglich mit diesem Programm aus dem laufenden Betrieb heraus eine Datensicherung durchzuführen?

Gruß, ottonormal

[smutbert]

Was ist denn für ein Dateisystem drauf?
Was sagen nach dem Versuch die letzten Zeilen von dmesg?

Ist es eigentlich auch möglich mit diesem Programm aus dem laufenden Betrieb heraus eine Datensicherung durchzuführen?

Ja (steht zumindest im Ubuntu-Wiki [1]) auch wenn es wohl ratsam ist, während des Backups möglichst wenig an den zu sichernden Dateisystemen zu verändern. fsarchiver macht zwar (vor allem beim Wiederherstellen) mehr als andere Tools, so kann es zB die Dateisysteme vor der Wiederherstellung anlegen, aber bei der Sicherung greift es wie tar, rsync, cp,… ganz normal auf die zu sichernden Dateien zu.

[1] https://wiki.ubuntuusers.de/qt4-fsarchiver/

[ottonormal]

Danke für Deine Antwort.
Es handelt sich um eine ganz normal verschlüsselte Installation mit ext4 als Dateisystem.
Hier die Ausgabe von dmesg: http://nopaste.debianforum.de/39217
Und hier nach dem Versuch: http://nopaste.debianforum.de/39218

[smutbert]

Nanu, demnach hat er gar nicht versucht zu mounten... was sagt denn

Code: Alles auswählen

# lsblk --fs

(ev. vor und nach dem Mountversuch, nachher ist aber wichtig)

[ottonormal]

Das hat keine Änderung gebracht, gleiche Fehlermeldung

[smutbert]

Änderung war ja keine zu erwarten, aber an der Ausgabe von »lsblk --fs« (als root) erkannt man, ob dass der Luks-Header erkannt wurde, ob die verschlüsselte Partition entsperrt worden ist und wenn ja ob darauf ein Dateisystem erkannt wurde. Wenn du das also nach einem Versuch ausführst sieht man an welchem Punkt es scheitert (hoffe ich zumindest).

[ottonormal]

So sieht lsblk --fs vor dem Mountversuch aus:

Code: Alles auswählen

root@debian:/home/ottonormal# lsblk --fs
NAME           FSTYPE      LABEL        UUID                                 MOUNTPOINT
sda                                                                          
├─sda1         ext4        1-Mint17     077de529-6eae-45c7-a471-ecafc2c43a6c 
├─sda2         ext4        2-Deb-Zimt   9913aab3-0848-40f7-969c-2e4638c30c1e 
├─sda3         ext4        3-DebiOBox   35c22600-cfbf-4a8c-bdeb-a0e1d5d90614 /
└─sda4         ext4        4-Deb-Studio 5eef452f-6862-4900-ab55-c15bae0c4413 
sdb                                                                          
├─sdb1         ntfs        Windows-Boot 24F4F88E3B808EF5                     
├─sdb2                                                                       
│ └─truecrypt1 ext3                     841e3d41-018c-4703-a8bb-6b2063f694e8 /media/truecrypt1
├─sdb3                                                                       
│ └─truecrypt2 ntfs                     4002BC6F02BC6C12                     /media/truecrypt2
├─sdb4                                                                       
├─sdb5         ntfs        Windows-7    672F4A220EB25E50                     
├─sdb6                                                                       
├─sdb7         ext2        Sparky-Boot  e0566621-47d7-426f-a203-6c19ac4140d1 
└─sdb8         crypto_LUKS              f19f6c95-0ad2-4f16-ab74-4433a2d480e4 
sr0                                                                          
root@debian:/home/ottonormal# 

und so danach:

Code: Alles auswählen

root@debian:/home/ottonormal# lsblk --fs
NAME                                          FSTYPE      LABEL        UUID                                   MOUNTPOINT
sda                                                                                                           
├─sda1                                        ext4        1-Mint17     077de529-6eae-45c7-a471-ecafc2c43a6c   
├─sda2                                        ext4        2-Deb-Zimt   9913aab3-0848-40f7-969c-2e4638c30c1e   
├─sda3                                        ext4        3-DebiOBox   35c22600-cfbf-4a8c-bdeb-a0e1d5d90614   /
└─sda4                                        ext4        4-Deb-Studio 5eef452f-6862-4900-ab55-c15bae0c4413   
sdb                                                                                                           
├─sdb1                                        ntfs        Windows-Boot 24F4F88E3B808EF5                       
├─sdb2                                                                                                        
│ └─truecrypt1                                ext3                     841e3d41-018c-4703-a8bb-6b2063f694e8   /media/truecrypt1
├─sdb3                                                                                                        
│ └─truecrypt2                                ntfs                     4002BC6F02BC6C12                       /media/truecrypt2
├─sdb4                                                                                                        
├─sdb5                                        ntfs        Windows-7    672F4A220EB25E50                       
├─sdb6                                                                                                        
├─sdb7                                        ext2        Sparky-Boot  e0566621-47d7-426f-a203-6c19ac4140d1   
└─sdb8                                        crypto_LUKS              f19f6c95-0ad2-4f16-ab74-4433a2d480e4   
  └─luks-f19f6c95-0ad2-4f16-ab74-4433a2d480e4 LVM2_member              fdTjMe-MIQA-i3sh-ab5c-V2Ku-MMbF-JK4Xek 
sr0                                                                                                           
root@debian:/home/ottonormal# 

[ottonormal]

Ich habe das eben noch mal in Linux-Mint gemacht.
Da sieht es vor dem Versuch so aus:

Code: Alles auswählen

├─sdb4                                         
├─sdb5                ntfs        Windows-7    /media/otto/Windows-7
├─sdb6                                         
├─sdb7                ext2        Sparky-Boot  /media/otto/Linux-5
└─sdb8                crypto_LUKS              
sr0   

und danach so:

Code: Alles auswählen

├─sdb4                                                                        
├─sdb5                                               ntfs        Windows-7    /media/otto/Windows-7
├─sdb6                                                                        
├─sdb7                                               ext2        Sparky-Boot  /media/otto/Linux-5
└─sdb8                                               crypto_LUKS              
  └─luks-f19f6c95-0ad2-4f16-ab74-4433a2d480e4 (dm-2) LVM2_member              
    ├─sparky-Linux (dm-3)                            ext4                     /media/otto/1c2359ef-0067-4bb5-8e54-48d63b9388a7
    └─sparky-swap (dm-4)                             swap                     
sr0  

Es ist übrigens ein reines Debian, auch wenn da Sparky steht. Das ist aus einem Sparky entstanden, hat aber außer dem Namen von Sparky nichts mehr.

[smutbert]

Ach darauf liegt auch noch lvm. Hast du auf dem System, auf dem es nicht funktioniert, überhaupt lvm2 installiert?

[ottonormal]

Das hatte ich nicht, wusste auch nicht dass das installiert sein muss.
Jetzt ist es installiert, hat aber, auch nach einem Neustart, keine Auswirkungen.

[smutbert]

Ok, dann einmal kurz zu Erklärung. Unter Mint sieht man

Code: Alles auswählen

└─sdb8                                               crypto_LUKS              
  └─luks-f19f6c95-0ad2-4f16-ab74-4433a2d480e4 (dm-2) LVM2_member              
    ├─sparky-Linux (dm-3)                            ext4                     ...
    └─sparky-swap (dm-4)                             swap

dass sdb8 ein verschlüsseltes luks-Volume enthält, das wiederum zwei lvm2-Volumes enthält. Bevor sdb8 entsperrt wird, sieht das System einfach nur die Partition sdb8 und erkennt, das irgendetwas nach luks-Art verschlüsseltes darauf ist

Code: Alles auswählen

└─sdb8         crypto_LUKS              f19f6c95-0ad2-4f16-ab74-4433a2d480e4

Klickst du nun in thunar darauf wird es im ersten Schritt entsperrt, das sieht dann so aus

Code: Alles auswählen

└─sdb8                                        crypto_LUKS              f19f6c95...   
  └─luks-f19f6c95-0ad2-4f16-ab74-4433a2d480e4 LVM2_member              fdTjMe-MIQA-... 

der zweite Schritt bestünde nun darin das darauf enthaltene Dateisystem zu mounten, was aber nicht geht, weil das Dateisystem nicht direkt in dem luks-Volume liegt sondern noch das logical volume management (lvm2) als Schicht dazwischen liegt. D.h. die Fehlermeldung stimmt insofern als das System noch keinen Zugang zu einem Dateisystem hat.

____

Jetzt ist nur noch die Frage warum das Installieren von lvm2 alleine noch nicht ausgereicht hat, damit es funktioniert.

Ich würde einfach einmal ins Blaue nach dem Versuch das verschlüsselte Ding in Thunar zu mounten (denn danach ist es wie wir gesehen haben bereits entsperrt) den Befehl

Code: Alles auswählen

# vgchange -aay

ausführen, der sollte die lvm2-Geschichten alle aktivieren. Danach sollte die lsblk-Ausgabe aussehen wie unter Mint und auch thunar sollte das Dateisystem vermutlich mounten können.

[ottonormal]

Kleiner Zwischenbericht:
Ich bin gerade auf Debian-Stretch-Cinnamon, da wollte ich das auch mal probieren. lv2m musste da auch erst installiert werden. Außerdem noch liblvm2app2.2 und initramfs-tools, jedenfalls war das bei Mint installiert und ich dachte, schaden kann es ja nicht.
Ja und was soll ich sagen, auf Stretch funktioniert es. Die Ausgabe von lsblk --fs sieht danach genau so aus wie bei Mint.
Es erscheint zwar auch eine Meldung:

Code: Alles auswählen

Der Datenträger "20 GB verschlüsselt" konnte nicht eingehängt werden.
Vorgang wurde abgebrochen.

Aber das ist bei Mint und Ubuntu auch, trotzdem ist der Datenträger jetzt unverschlüsselt im Dateimanager aufgeführt und kann geöffnet werden.

Und nun? warum nicht bei Jessie? Es wäre ein weiterer Punkt von schon mehreren, der in Stretch funktioniert und in Jessie nicht. Ist Jessie schon zu alt?

Ich werde es aber noch weiter probieren. Auf jeden Fall bis hier hin schon mal vielen Dank für die Hilfe. Ich hoffe dass das bei Jessie auch noch wird, ist doch schließlich mein Hauptarbeitssystem.

[ottonormal]

Ich würde einfach einmal ins Blaue nach dem Versuch das verschlüsselte Ding in Thunar zu mounten (denn danach ist es wie wir gesehen haben bereits entsperrt) den Befehl

Code: Alles auswählen

# vgchange -aay

ausführen, der sollte die lvm2-Geschichten alle aktivieren. Danach sollte die lsblk-Ausgabe aussehen wie unter Mint und auch thunar sollte das Dateisystem vermutlich mounten können.

So habe ich es jetzt in Jessie gemacht. # vgchange -aay sagt aber:

Code: Alles auswählen

root@debian:/home/ottonormal# vgchange -aay
  No volume groups found
root@debian:/home/ottonormal#

Da fehlt wohl noch was anderes.

[NAB]

Du könntest mal die Ausgabe von

Code: Alles auswählen

lsmod | grep dm_mod

zwischen Stretch, Jessie und Mint vergleichen.

[ottonormal]

Hier bitteschön:
Jessie:

Code: Alles auswählen

ottonormal@debian:~$ lsmod | grep dm_mod
dm_mod                 89405  6 dm_crypt
ottonormal@debian:~$

Stretch:

Code: Alles auswählen

ottonormal@debian:~$ lsmod | grep dm_mod
dm_mod                106496  5 dm_crypt
ottonormal@debian:~$ 

Mir sagt das absolut nichts

[smutbert]

…# vgchange -aay sagt aber:

Code: Alles auswählen

root@debian:/home/ottonormal# vgchange -aay
  No volume groups found
root@debian:/home/ottonormal#

…

Da war das Luks-Ding sicher schon entsperrt? Es hat also davor bereits mit "lsblk --fs" so ausgesehen?

Code: Alles auswählen

…
└─sdb8                                        crypto_LUKS              f19f6c95...   
  └─luks-f19f6c95-0ad2-4f16-ab74-4433a2d480e4 LVM2_member              fdTjMe-MIQA-... 

[NAB]

Mir sagt das absolut nichts

Das ist gut. Das besagt, dass das dm_mod Kernel-Modul auch bei Jessie geladen ist. Ohne würde er nämlich keine LVMs erkennen

[ottonormal]

Moment... jetzt kapiere ich gar nichts mehr . Ich habe es eingehängt bekommen, weiß aber nicht mehr wieso und warum.
Ich wollte das noch mal genau in der Reihenfolge testen. Dann kam beim Versuch in Thunar wieder die Fehlermeldung und die verschlüsselte Partition wurde in Thunar nicht mehr angezeigt (Das war aber vorher auch schon so). Dann habe ich gnome-disks gestartet und das da irgendwie eingehängt und dann war das da!!
Das muss ich jetzt erst mal verdauen und dann noch mal neu versuchen.

Jetzt muss ich erst mal zum Essen, sonst krieg ich Ärger mit meiner besseren Hälfte.

Ich melde mich wieder.

[NAB]

Dass es "plötzlich" geht, könnte daran liegen, dass du ein paar LVM-Pakete intalliert hast. Und danach war dann vielleicht noch ein Neustart fällig, damit Thunar das auch mitbekommt.

Mahlzeit!

[ottonormal]

So, jetzt bin ich etwas weiter. Nach einem Neustart gebe ich

Code: Alles auswählen

# vgchange -aay

ein und erhalte dann:

Code: Alles auswählen

root@debian:/home/ottonormal# vgchange -aay
  No volume groups found
root@debian:/home/ottonormal# 

Dann versuche ich in Thunar die verschlüsselte Partition einzuhängen, Passphrase, root-Passwort und es kommt wie immer: Fehlermeldung und keine Partition mehr in Thunar zu sehen.
Dann gebe ich wieder ein:

Code: Alles auswählen

# vgchange -aay

und erhalte diesmal:

Code: Alles auswählen

root@debian:/home/ottonormal# vgchange -aay
  2 logical volume(s) in volume group "sparky" now active
root@debian:/home/ottonormal# 

Gleichzeitig erscheint die Partition UNverschlüsselt in Thunar. Angeklickt, root-Passwort und das war's.
Etwas kompliziert und nicht ganz nachvollziehbar für mich. Lässt sich da noch etwas machen? Was müsste / könnte ich da noch ändern?

Das war jetzt kein Zufallsergebnis mehr, ich habe es 3 mal nach jeweiligem Neustart gemacht und der Ablauf war immer gleich.

[smutbert]

Bei deiner Methode, müsstest du das erste »vgchange -aay« weglassen können, das tut gar nichts. Was passiert ist folgendes:

- Dein Versuch in Thunar das verschlüsselte Dateisystem zu mounten, entsperrt einmal die Verschlüsselung
- Das (zweite) »vgchange -aay« aktiviert die lvm2-Volumes, macht also das ext4-Dateisystem erst wirklich zugänglich
- Schließlich kannst du das Dateisystem in Thunar durch Anklicken mounten

___

Wieso das »vgchange -aay« überhaupt notwendig ist und ob andere Desktops (zB Mate, Cinnamon, Gnome) das anders/besser können, weiß ich nicht.
Im Prinzip könnte man diese ganzen Schichten, die zwischen Dateisystem und Festplatte/SSD/USB-Stick liegen ja beliebig „stapeln“, nur ist mir noch nie ganz klar gewesen, wieviele solcher Schichten automatisch vom System erkannt und eingebunden werden können und wo Handarbeit notwendig ist.
Mit Schichten meine ich Partitionierung, lvm2, cryptsetup/luks, raid/mdadm und was sonst noch alles möglich ist

[NAB]

Oder mal anders gefragt: wird bei Mint und Stretch auch Thunar verwendet? Eventuell fehlt dann unter Jessie irgendein Paket. Ich habe aber auch keinen Schimmer, welches das sein könnte. Thunar greift teilweise auf das gvfs von Gnome zurück ... vielleicht kann man in der Richtung mal suchen.

[ottonormal]

Bei deiner Methode, müsstest du das erste »vgchange -aay« weglassen können, das tut gar nichts.

Ja, das mache ich inzwischen auch schon. Dann habe ich in meinem Openbox-Rechtsklickmenü einen Starteintrag für "gexec" und darin den Befehl "vgchange -aay" gespeichert. So brauche ich nach einem Neustart und Mountversuch in Thunar nur noch 2 Klicks und eine root-Passwort-Eingabe. Das ist kein Problem, damit kann ich gut leben.
Ich habe das eben auch noch auf meinem Debian-Jessie-Studio-System probiert, da ist es exakt das gleiche. lvm2 usw. installiert und auch den "vgchange -aay"-Befehl im Rechtsklickmenü eingebaut und fertig.

Außerdem, soo häufig muss ich das ja gar nicht machen. Es ging mir ja in erster Linie darum, dass ich eine Datensicherung des Systems von außen durchführen kann. So wie es jetzt ist, ist es schon gut und wenn Stretch denn mal stable wird, hat sich das Problem ja sowieso erledigt.

Vielen Dank also für Deine und NABs Hilfe, allein wäre ich darauf lvm2 und vgchange -aay wohl nie gekommen, wie kommt man überhaupt auf so etwas?

Gruß, ottonormal

Nachtrag:
NAB: Ja, Thunar ist bei mir auf jedem System Standard. Es ist aber mit PCManFM, Nemo und Nautilus genau das gleiche, das hatte ich ja von Anfang an schon ausprobiert weil ich wusste, das das kommt.