Der Versuch, eine verschlüsselte Partition wiederherzustellen, wird sehr verwirrt

574
naomi

Ich habe eine mit LUKS / cryptsetup verschlüsselte Festplatte eines Debian-Rechners eines Freundes, die nicht booten würde. Ich versuche, es auf einem anderen Debian-Computer mit einem USB-Gehäuse zu installieren, um die Daten wiederherzustellen oder einen Hinweis auf das Problem zu erhalten. Ich bin ein erfahrener Linux-Befehlszeilenbenutzer, aber insgesamt n00b mit LUKS und LVM.

Auto-Mount funktioniert nicht (es akzeptiert die Passphrase, sagt jedoch etwas über ein unbrauchbares Dateisystem aus und mounten nicht).

Also habe ich versucht, es von der Kommandozeile aus zu mounten.

root@somepc:/dev/mapper# fdisk -l | grep sdb Disk /dev/sdb: 149.1 GiB, 160041885696 bytes, 312581808 sectors /dev/sdb1 2048 999423 997376 487M 83 Linux /dev/sdb2 1001470 312580095 311578626 148.6G 5 Extended /dev/sdb5 1001472 312580095 311578624 148.6G 83 Linux   root@somepc:~# cryptsetup luksOpen /dev/sdb5 foo Enter passphrase for /dev/sdb5: [Passphrase accepted] root@somepc:~# vgdisplay --- Volume group --- VG Name ubuntu-mate-vg21 System ID  Format lvm2 Metadata Areas 1 Metadata Sequence No 9 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.57 GiB PE Size 4.00 MiB Total PE 38033 Alloc PE / Size 38027 / 148.54 GiB Free PE / Size 6 / 24.00 MiB VG UUID y7TB6e-b6hT-0Fpr-wXAY-6DwW-1Vyw-2bolpJ  --- Volume group --- [ details of system disk ] 

An diesem Punkt wurde mir klar, dass mein Freund versucht hatte, ihn mit einem Ubuntu Mate-Rechner wiederherzustellen. Das Folgende legt nahe, dass er die Partitionen modifiziert haben muss ... Nach dem "LV Creation Host, time" zu urteilen - Er sagt, er habe es in GParted angesehen und GParted habe vielleicht etwas damit gemacht.

Wir sind die Blinden, die die Blinden führen ...

root@somepc:~# lvdisplay /dev/ubuntu-mate-vg21 --- Logical volume --- LV Path /dev/ubuntu-mate-vg21/root LV Name root VG Name ubuntu-mate-vg21 LV UUID wOnyHp-WXox-QatY-mQEy-Esuz-ADcP-TzVEFh LV Write Access read/write LV Creation host, time ubuntu-mate, 2017-04-08 06:50:00 +0300 LV Status NOT available LV Size 140.87 GiB Current LE 36062 Segments 1 Allocation inherit Read ahead sectors auto  --- Logical volume --- LV Path /dev/ubuntu-mate-vg21/swap_1 LV Name swap_1 VG Name ubuntu-mate-vg21 LV UUID WapYkq-O3AP-r0x9-3bBW-KcWD-yCNC-mw8Gq2 LV Write Access read/write LV Creation host, time ubuntu-mate, 2017-04-08 06:50:01 +0300 LV Status NOT available LV Size 7.68 GiB Current LE 1965 Segments 1 Allocation inherit Read ahead sectors auto 

Jedenfalls weiter.

root@somepc:~# vgchange -ay ubuntu-mate-vg21 2 logical volume(s) in volume group "ubuntu-mate-vg21" now active root@somepc:~# mount /dev/ubuntu-mate-vg21/root /mnt/test mount: wrong fs type, bad option, bad superblock on /dev/mapper/ubuntu--mate--vg21-root, missing codepage or helper program, or other error  In some cases useful info is found in syslog - try dmesg | tail or so. 

Also habe ich "schlechten Superblock" gegoogelt und gemacht

root@somepc:~# fsck /dev/ubuntu-mate-vg21/root fsck from util-linux 2.25.2 e2fsck 1.42.12 (29-Aug-2014) ext2fs_open2: Bad magic number in super-block fsck.ext2: Superblock invalid, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/ubuntu--mate--vg21-root  The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (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 <device> or e2fsck -b 32768 <device>  root@somepc:~# mke2fs -n /dev/ubuntu-mate-vg21/root mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 36927488 4k blocks and 9232384 inodes Filesystem UUID: 484f5abf-3fee-42a7-af1c-22f9bdde8976 Superblock backups stored on blocks:  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,  4096000, 7962624, 11239424, 20480000, 23887872 

Dann habe ich es e2fsck -b <BLOCKNUMBER> /dev/ubuntu-mate-vg21/rootmit jeder Blocknummer versucht und jedes Mal den gleichen Fehler wie oben erhalten.

Danach habe ich gelesen, dass Sie fsck nicht auf einem logischen Datenträger oder so ausführen müssen und sollten, und ich sollte es nicht tun. Ich hoffe, ich habe die Situation nicht verschlimmert.

Ich habe das Gefühl, dass es noch etwas gibt, was ich tun kann, bevor ich diese Platte einfach aufgeben kann, aber ich habe echte Probleme, es herauszufinden. Vielleicht muss ich nur auf eine Dokumentation hinweisen.

Vielen Dank

1
Sie haben `mke2fs` ausgeführt, was erfolgreich zu sein schien. Als solche haben Sie eine neue FS erstellt und im Zweifelsfall alles überschrieben, was an ihrer Stelle war. Wahrscheinlich hat er vorher etwas angeklickt. Auf welchem ​​Betriebssystem lief der ursprüngliche Computer, bevor eine Wiederherstellung stattfand? Seth vor 7 Jahren 1

0 Antworten auf die Frage