Vyvyane
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Hallo,
mein Linux Mint 17.3 Rosa startete eines Tages nicht mehr. Ich habe meine Festplatte verschlüsselt und LVM aktiviert. Morgens startete ich den PC, konnte noch das boot-Passwort eingeben, sah dann aber nur noch Grub. Fehlermeldungen wurden nicht ausgegeben. Ich habe die Platte an einem anderen Laptop angeschlossen, kann die Platte auch entschlüsseln, aber nicht mounten. Fehlermeldung: Einhängen von 1,0 TB verschlüsselt nicht möglich: Error unlocking /dev/sdc1: Command-line `cryptsetup luksOpen "/dev/sdc1" "luks-3e475f22-b041-4706-9b7d-791a628333d6" ' exited with non-zero exit status 5: Device luks-3e475f22-b041-4706-9b7d-791a628333d6 already exists. Auf der Platte sind 2 Partitionen - Betriebssystem und Daten - bei beiden Partitionen kommt diese Fehlermeldung. Da ich eher Anfänger mit Linux bin, kann ich den Fehler nicht alleine beheben. Durch Internetrecherche habe ich einige Tipps gefunden. Hier die Ausgabe: sudo fdisk -l
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
255 Köpfe, 63 Sektoren/Spur, 121601 Zylinder, zusammen 1953525168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Festplattenidentifikation: 0x0000d189
Gerät boot. Anfang Ende Blöcke Id System
/dev/sdc1 2048 1953523711 976760832 83 Linux
~ $ sudo e2fsck -f /dev/sdc
e2fsck 1.42.9 (4-Feb-2014)
ext2fs_open2: Ungültige magische Zahl im Superblock
e2fsck: Superblock ungültig versuche es mit Backup-Blöcken...
e2fsck: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdc zu öffnen
The SuperBlock could not be read or does not describe a valid ext2/ext3/ext4
Dateisystem. If the Gerät is valid and it really contains an ext2/ext3/ext4
Dateisystem (and not swap or ufs or something else), then the SuperBlock
is corrupt, and you might try running e2fsck with an alternate SuperBlock:
e2fsck -b 8193 <Gerät>
or
e2fsck -b 32768 <Gerät> Ich habe die Ausgabe befolgt und die Befehle mit den anderen Superblöcken ausgeführt - aber die Ausgabe bleibt die Gleiche! Kann mir jemand helfen? Bearbeitet von sebix: Titel durch nicht supportete Betriebsystemversion ergänzt.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Hallo und willkommen bei ubuntuusers. Vyvyane schrieb: Device luks-3e475f22-b041-4706-9b7d-791a628333d6 already exists.
heißt, dass die verschlüsselte Partition bereits aufgeschlossen wurde und nun erneut versucht wurde, unter dem selben virtuellen Gerätenamen aufzuschließen. Was sagt nach der obigen Meldung dieser Befehl? sudo mount /dev/mapper/luks-3e475f22-b041-4706-9b7d-791a628333d6 /mnt edit: Der Befehl versucht, die aufgeschlossene Partition im Verzeichnis /mnt einzuhängen.
sudo e2fsck -f /dev/sdc
Hier fehlt die Partitionsnummer, richtig ist sudo e2fsck -f /dev/sdc1
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Hallo Vortex,
hier die Ausgabe: sudo mount /dev/mapper/luks-3e475f22-b041-4706-9b7d-791a628333d6 /mnt
mount: unknown filesystem type 'LVM2_member' sudo e2fsck -f /dev/sdc1
e2fsck 1.42.13 (17-May-2015)
/dev/sdb1 wird verwendet.
e2fsck: Fortsetzung nicht möglich, wird abgebrochen. Wenn ich bei der Partition den filesystem type ändere sind meine Daten weg, oder?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
mount: unknown filesystem type 'LVM2_member'
Bedeutet, dass in der verschlüsselten Partition ein LVM liegt, grob gesagt eine weitere Verwaltungsebene, die innerhalb einer Partition weitere sog. Logical Volumes erlaubt, die viel dynamischer angepasst werden können als herkömmliche Partititonen. Du kannst daher /dev/mapper/luks-3e475f22-b041-4706-9b7d-791a628333d6 nicht direkt einhängen oder e2fsck darauf anwenden. Den Dateisystemtyp solltest Du auf keinen Fall ändern, wenn Du nicht genau weißt, was Du tust. Im vorliegenden Fall besteht dafür auch keine Veranlassung. Vielmehr müssen wir mal schauen, welche Logical Volumes im LVM liegen, um diese dann einzubinden oder auf Fehler zu überprüfen. Gib uns mal die Ausgaben von diesen Befehlen: sudo lvs
ls -l /dev/mapper
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Moin Vortex,
hier die Ausgabe XXX@ubuntu-PC:~$ ls -l /dev/mapper
insgesamt 0
crw------- 1 root root 10, 236 Dez 12 17:11 control
lrwxrwxrwx 1 root root 7 Dez 12 17:15 luks-3e475f22-b041-4706-9b7d-791a628333d6 -> ../dm-0
lrwxrwxrwx 1 root root 7 Dez 12 17:15 mint--vg-root -> ../dm-1
lrwxrwxrwx 1 root root 7 Dez 12 17:15 mint--vg-swap_1 -> ../dm-2 Was bedeutet dieses → ../dm-0?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Vyvyane schrieb: Moin Vortex,
hier die Ausgabe
Ich hatte Dir zwei Befehle gegeben. Bitte auch die Ausgabe von sudo lvs . Wir können aber schon mal weitermachen. Laut der Ausgabe gibt es im LVM zwei Logical Volumes, mint--vg-root und mint--vg-swap_1. Die Swap-Volume interessiert nicht, die Root-Volume ist die „Partition“ Deines Mint-Systems. Versuche mal, diese im Verzeichnis /mnt einzubinden: sudo mount -t ext4 /dev/dm-1 /mnt Jedwede Textausgabe bitte hier reinschreiben. Kommt kein Text, sollte es geklappt haben (bei Linux heißt keine Nachricht in der Regel „hat geklappt“).
Was bedeutet dieses → ../dm-0?
Dass die virtuellen Geräte in /dev/mapper nochmal unter diesen Namen nach /dev verlinkt sind (der Doppelpunkt bedeutet in Linux „eine Verzeichnisebene höher“). Man kann sie über beide Pfade ansprechen, /dev/mapper/mint--vg-root ist also genauso gut über /dev/dm-1 erreichbar. Siehe auch Device_Mapper, speziell den Abschnitt Aufbau von Geräten des Device Mappers. Die ganzen Links gebe ich Dir zum Anlesen des Hintergrundwissens und dann hoffentlich besseren Verstehens. 🤓
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Moin Vortex,
ja, sorry, dass ich nicht alles weitergegeben habe. Also hier nochmal alles - incl. der ersten Befehle:
XXX@ubuntu-PC:~$ sudo lvs
[sudo] Passwort für XXX:
maria@ubuntu-PC:~$ ls -l /dev/mapper
insgesamt 0
crw------- 1 root root 10, 236 Dez 12 21:22 control
Dann ist mir aufgefallen, dass ich die Festplatte erstmal entschlüsseln sollte. Danach sah das Ergebins so aus: XXX@ubuntu-PC:~$ ls -l /dev/mapper
3insgesamt 0
crw------- 1 root root 10, 236 Dez 12 21:22 control
lrwxrwxrwx 1 root root 7 Dez 12 21:36 luks-3e475f22-b041-4706-9b7d-791a628333d6 -> ../dm-0
lrwxrwxrwx 1 root root 7 Dez 12 21:36 mint--vg-root -> ../dm-1
lrwxrwxrwx 1 root root 7 Dez 12 21:36 mint--vg-swap_1 -> ../dm-2
XXX@ubuntu-PC:~$ sudo mount -t ext4 /dev/dm-1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mint--vg-root,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
XXX@ubuntu-PC:~$
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Vyvyane schrieb: Dann ist mir aufgefallen, dass ich die Festplatte erstmal entschlüsseln sollte. Danach sah das Ergebins so aus:
… und hast in der Hektik wieder das sudo lvs vergessen. 😛 Nicht böse gemeint, aber Du solltest den Anweisungen der Helfer konzentriert und genau folgen, es erleichtert die Hilfe enorm und spart mehrmaliges Nachfragen. 🤓
XXX@ubuntu-PC:~$ sudo mount -t ext4 /dev/dm-1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/mint--vg-root,
Entweder das Dateisystem ist nicht ext4 (unter Ubuntu der Standard, keine Ahnung ob auch bei Mint) oder es ist nicht in Ordnung, was Dein eigentliches Problem erklären würde. Sehen wir mal nach, welcher Dateisystemtyp es ist: sudo file -s /dev/dm-1 Wenn da ext4 steht, so wie hier /dev/dm-2: Linux rev 1.0 ext4 filesystem data … kannst Du mal testweise einen nur lesenden Dateisystemcheck durchführen: sudo e2fsck -fn /dev/dm-1 Die Option n sorgt für den nur lesenden Zugriff, um nichts versehentlich kaputt zu machen.
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Hallo Vortex, … und hast in der Hektik wieder das sudo lvs vergessen. 😛 Nicht böse gemeint, aber Du solltest den Anweisungen der Helfer konzentriert und genau folgen, es erleichtert die Hilfe enorm und spart mehrmaliges Nachfragen. 🤓
Entschuldige bitte. Ich hatte den Befehl ausgeführt, aber in der falschen Reihenfolge. Jetzt nochmal richtig: sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root mint-vg -wi-a----- 927,23g
swap_1 mint-vg -wi-a----- 4,00g sudo file -s /dev/dm-1
/dev/dm-1: Linux rev 1.0 ext4 filesystem data, UUID=2139cc7e-9847-41b9-a9c2-17f613abf91c (extents) (large files) (huge files)
Es scheint also ext4 zu sein. Vermutlich ist wirklich etwas defekt. Der Systemcheck hat jedenfalls Fehler gefunden: sudo e2fsck -fn /dev/dm-1
e2fsck 1.42.13 (17-May-2015)
Der Superblock hat ein defektes Journal (Inode 8).
Bereinigen? nein
e2fsck: Ungültige Inode-Nummer während der Prüfung des ext3-Journals für /dev/dm-1
/dev/dm-1: ********** WARNUNG: Noch Fehler im Dateisystem ********** Wie bereinigt man so etwas?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Vyvyane schrieb: Entschuldige bitte. Ich hatte den Befehl ausgeführt, aber in der falschen Reihenfolge. Jetzt nochmal richtig:
Super. Der lvs-Befehl ist zwar inzwischen nicht mehr so wichtig, aber so kennst Du ihn jetzt. Er zeigt die einzelnen Logical Volumes der im System aktiven LVM an. Wenn Du die Ausgabe von lvs mit der des lv-Befehls weiter oben vergleichst, siehst Du, wie die Namen der Volume Group (VG) und der Logical Volume (LV) im Verzeichnis /dev/mapper zu Gerätenamen zusammengesetzt werden. Wieder etwas Hintergrundwissen. 🤓
Der Superblock hat ein defektes Journal (Inode 8).
Bereinigen? nein Wie bereinigt man so etwas?
Indem man fsck ohne die Option n (nur lesender Testmodus) ausführt. Vorher solltest Du aber besser ein Image der gesamten verschlüsselten Partiton /dev/sdc1 oder der unverschlüsselten Logical Volume /dev/mapper/mint--vg-root (bzw. /dev/dm-1) machen, z.B. mit dd (Abschnitt „Image-einer-Partition-sichern“) oder partimage oder Clonezilla. Danach führst Du bei aufgeschlossener Verschlüsselung fsck aus: sudo e2fsck -f /dev/dm-1 Bei Reparaturversuchen kann immer etwas schiefgehen, daher macht man wenn irgendwie möglich zuvor ein Backup. Noch besser wäre es, den Reparaturversuch am Image durchzuführen. Wenn dann etwas schiefgeht, hat man nur das Image versaut. Wenn Du die Reparatur am Original durchführst, wäre beim Scheitern das Zurückspielen des Backup-Images nötig. Es kommt halt darauf an, als wie wahrscheinlich man den Erfolg der Reparatur einschätzt. Die Reparatur am Image müsste ich Dir halt erstmal erklären. Entscheide Du. 😛
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Hallo Vortex,
ich bin dann ja eher für das reparieren des images. Allerdings habe ich für die Abbilderstellung und Co. erst am Wochenende Zeit. Ich melde mich am WE wieder, wenn ich mir Clonezilla mal genauer angeschaut habe und das Abbild fertig ist.
LG, Vyvyane
PS: Danke schon mal für deine tollen Erklärungen.
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Gern geschehen, bis dann.
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Hallo Vortex,
ich melde mich vom Krankenlager aus bei Dir. Inzwischen bin ich wieder so weit fit, dass ich meinen PC bedienen kann. Folgendes habe ich im Laufe des Tages ausprobiert:
Ich habe mich vorerst für partimage entschieden. Bei dem Versuch ein image zu erstellen, bekam ich die Fehlermeldung "Image Lesefehler Bitmap Block 0". Danach wurde partimage abgebrochen. Alternativ dazu habe ich jetzt ein Partitionsabbild über folgenden Weg erstellt: Ich habe das Standardtool "Laufwerke" genommen, die defekte Partion ausgewählt und ein Partitionsabbild erstellt. Hilft uns das weiter?
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Das Tool „Laufwerke“ kenne ich nicht (ich habe Kubuntu 14.04). Wenn das Abbild von der verschlüsselten Partition korrekt erstellt wurde, müsste cryptsetup als Containerdatei aufschließen können, wie in LUKS/Containerdatei (Abschnitt „Container-einhaengen“) beschrieben. Probier mal folgendes: Optional: Falls Du den Plattenplatz frei hast, mache von der Abbild-Datei eine Sicherheitskopie. So musst Du bei einem kaputtreparierten Abbild für einen neuen Versuch kein neues mit „Laufwerke“ erzeugen. sudo losetup -f liefert ein freies sog. Loop-Gerät zurück, z.B. /dev/loop0. Unter diesem virtuellen Gerät bindest Du das Abbild ein: sudo losetup /dev/loop0 pfad/zum/abbild Für pfad/zum/abbild musst Du den Pfad und Dateinamen des Abbildes angeben. Führst Du den Befehl im Verzeichnis des Abbildes aus, reicht der Dateiname. sudo cryptsetup luksOpen /dev/loop0 container bindet das loop-Gerät unverschlüsselt unter /dev/mapper/container ein. Der Name „container“ ist frei wählbar. Hat das alles geklappt, testhalber ein e2fsck schreibgeschützt ausführen: sudo e2fsck -fn /dev/mapper/container Zeigt der Befehl ebenfalls ein falsches Journal wie zuvor beim Original, kannst Du die Reparatur versuchen: sudo e2fsck -f /dev/mapper/container Ist die Reparatur erfolgt, das Einhängen unter /mnt versuchen: sudo mount -t ext4 /dev/mapper/container /mnt Und den Inhalt anzeigen: ls -l /mnt
Ich hoffe, ich habe nichts übersehen. ☺ Probier's mal aus.
|
Vyvyane
(Themenstarter)
Anmeldungsdatum: 11. Dezember 2016
Beiträge: 23
|
Moin Vortex,
hier die ausprobierten Befehle: sudo losetup -f
/dev/loop0
Vyvyane@ubuntu-PC:~$ sudo losetup /dev/loop0 /media/Vyvyane/3-TB-INTENSO/Backup/Laufwerksabbild\ von\ mint-vg_root\ \(2016-12-19\ 1753\).img
Vyvyane@ubuntu-PC:~$ sudo cryptsetup luksOpen /dev/loop0 container
Gerät »/dev/loop0« ist kein gültiges LUKS-Gerät. Es hat also leider nicht geklappt. LG, Vyvy
|