Hallo Forum, ich habe mit meiner HOME Partition, die Verschlüsselt ist, ein Problem unter OpenSuse 13.1. Die HOME Partition befindet sich auf sda8 innerhalb eienr erweiterten Partition sda5 als logisches Laufwerk. Die Partition sda8 wurde darunter als luks Partition aufgesetzt und kann jetzt werder händisch noch beim Hochfahren eingebunden werden. cryptsetup open /dev/sda8 disk_by_id....... Es wird nach dem Passwort gefragt und dann erhalte ich eine Fehlermeldung in der Art: device-mapper: reload ioctl on failed: No such file or directory Failed to open temporary keystore device. Partition #5&6 sda5/sda6, die var und tmp enthalten und ebenfalls verschlüsselt sind, können gemounted werden und befinden sich ja auch innerhalb der erweiterten Partition. Ich konnte Gestern noch mit cryptsetup luksDump mir die Metadaten sichern, aber weiß nicht so recht, wie ich weiter vorgehen soll. Z.Z. läuft testdisk über die Disk, die ich aus dem NB ausgebaut habe und an einer Dockingstation eines zweiten NB angeschlossen habe. Meine Diagnose zuvor brachte folgenden Output: fdisk -l /dev/sdb Warning: ignoring extra data in partition table 5 Warning: ignoring extra data in partition table 5 Warning: ignoring extra data in partition table 5 Warning: invalid flag 0x9e1c of partition table 5 will be corrected by w(rite) Disk /dev/sdb: 750.2 GB, 750156374016 bytes, 183143646 sectors Units = sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: dos Disk identifier: 0x00007ce4 Device Boot Start End Blocks Id System /dev/sdb1 * 2048 1044479 4169728 83 Linux /dev/sdb2 1044480 51376127 201326592 82 Linux swap / Solaris /dev/sdb3 51376128 101707775 201326592 83 Linux /dev/sdb4 101707776 1465147391 1158791168 f W95 Ext'd (LBA) /dev/sdb5 ? 372805395 2844512324 1296893128 72 Unknown <<== ??? testdisk /list /dev/sdb TestDisk 7.0-WIP, Data Recovery Utility, January 2015 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org Please wait... Disk /dev/sdb - 750 GB / 698 GiB - CHS 11400 255 63 Sector size:4096 Model: ST975042 0AS Disk /dev/sdb - 750 GB / 698 GiB - CHS 11400 255 63 Partition Start End Size in sectors 1 * Linux 0 32 33 65 4 3 1042432 2 P Linux Swap 65 4 4 3198 4 6 50331648 3 P Linux 3198 4 7 6331 4 9 50331648 4 E extended LBA 6331 4 10 91201 52 51 1363439616 Testdisk läuft noch, aber mir fehlt die Anzeihe der extendet Partition, die längst hätte erscheinen müssen. TestDisk 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org Disk /dev/sdb - 750 GB / 698 GiB - CHS 11400 255 63 Analyse cylinder 9673/11399: 84% Linux 0 4 5 8 32 24 130304 [BOOT_PRT] Linux 8 32 25 8 97 25 4096 Linux 399 191 49 791 96 9 6291456 [ROOT_PRT] Linux 791 100 14 791 165 14 4096 Linux 987 68 42 987 133 42 4096 Linux 1574 196 31 1770 160 54 3146496 [OPT_PRT] Linux 1770 164 59 1770 229 59 4096 Habt Ihr Vorschläge, wie ich weiter verfahren soll? Danke für Eure Mühe im Voraus. Markus
Markus W. schrieb: > Hallo Forum, > > ich habe mit meiner HOME Partition, die Verschlüsselt ist, ein Problem > unter OpenSuse 13.1. > > Die HOME Partition befindet sich auf sda8 innerhalb eienr erweiterten > Partition sda5 als logisches Laufwerk. > > Die Partition sda8 wurde darunter als luks Partition aufgesetzt und > kann jetzt werder händisch noch beim Hochfahren eingebunden werden. > > cryptsetup open /dev/sda8 disk_by_id....... dann müsste es afair /dev/sda5 sein und nicht /dev/sda8. Test: cryptsetup open /dev/sda5 irgendwas cryptsetup status /dev/mapper/irgendwas # mount /dev/mapper/irgendwas /media/irgendwas Wie sieht /etc/fstab aus? Wie sieht /boot/grub/grub.cfg aus (der Default-Eintrag menuentry ... linux ...)? Die Ausgaben von lsblk -f und blkid (UUIDs) könnten u.U. auch noch nützlich sein
danke für Deinen Hinweis. Bin gerade dabei meine Festplatte komplett mit dd auf eine andere Disk zu schreiben. Wird einige Stunden in Anspruch nehmen (750GB bei 22MB/sec). Werde dann auf der Kopie weier arbeiten und mich wieder melden. Gruß Markus
Hallo Arc Net, halo Forum die Gewünschten Infos - s.u. Leider sind diese nicht so hilfreich. Ich habe die Festplatte mit testdisk behandelt und eine Partitionstabelle entsprechend der gefundenen Werte schreiben lassen. Was mich irritiert, ist die Länge der Partition sdb8 laut fdisk -l /dev/sdb8 28445440 28449535 16384 83 Linux Es ist eine veschlüssselte Partition (>500GB), aber die Länge müsste doch bekannt sein, oder ist dies aus Sicherheitsgründen gezielt nicht in der Partitionstabele bei einem LUKS System enthalten. Kann mir jemand sagen, welches "magic pattern" eine LUKS Partition am Anfang in ersten Block hat. Ich würde gerne händisch die Partitionstabelle via fdisk modifizieren entsprechend des ersten gefundenen LUKS blocks. Werde auch mal suchen was Google hierzu liefert. Danke für Eure Hilfe und Vorschläge im Vorraus. Markus cat ./fstab /dev/mapper/cr_ata-ST9750420AS_6WS2SRHZ-part2 swap swap defaults 0 0 LABEL=ROOT_PRT / ext4 acl,user_xattr 1 1 /dev/mapper/cr_ata-ST9750420AS_6WS2SRHZ-part5 /var ext4 noexec,nosuid,acl,user_xattr,nofail 0 2 /dev/mapper/cr_ata-ST9750420AS_6WS2SRHZ-part6 /tmp ext4 noexec,nosuid,noatime,acl,user_xattr,nofail 0 2 LABEL=BOOT_PRT /boot ext4 noatime,acl,user_xattr 1 2 LABEL=OPT_PRT /opt ext4 acl,user_xattr 1 2 LABEL=USRSRC_PRT /usr/src ext4 acl,user_xattr 1 2 LABEL=SRV_PRT /srv ext4 acl,user_xattr 1 2 /dev/mapper/cr_ata-ST9750420AS_6WS2SRHZ-part8 /home ext4 data=journal,acl,user_xattr,nofail 0 2 lsblk /dev/sdb NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 698.7G 0 disk ├─sdb1 8:17 0 509M 0 part /var/run/media/markus/BOOT_PRT ├─sdb2 8:18 0 16M 0 part ├─sdb3 8:19 0 24G 0 part /var/run/media/markus/ROOT_PRT ├─sdb4 8:20 0 4K 0 part ├─sdb5 8:21 0 16M 0 part ├─sdb6 8:22 0 16M 0 part │ └─luks-d9874d65-ae4c-4282-9ab6-1d22422f2c5c 253:7 0 14M 0 crypt ├─sdb7 8:23 0 12G 0 part /var/run/media/markus/OPT_PRT ├─sdb8 8:24 0 16M 0 part │ └─luks-6cfcee98-bca2-4fbf-b01a-7b11b77dad92 253:6 0 14M 0 crypt ├─sdb9 8:25 0 64G 0 part /var/run/media/markus/USRSRC_PRT └─sdb10 8:26 0 14.1G 0 part /var/run/media/markus/SRV_PRT fdisk -l /dev/sdb Disk /dev/sdb: 750.2 GB, 750156374016 bytes, 183143646 sectors Units = sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: dos Disk identifier: 0x00007ce4 Device Boot Start End Blocks Id System /dev/sdb1 * 256 130559 521216 83 Linux /dev/sdb2 130560 134655 16384 83 Linux /dev/sdb3 6422016 12713471 25165824 83 Linux /dev/sdb4 12713472 183143423 681719808 f W95 Ext'd (LBA) /dev/sdb5 12713728 12717823 16384 83 Linux /dev/sdb6 15860480 15864575 16384 83 Linux /dev/sdb7 25298688 28445183 12585984 83 Linux /dev/sdb8 28445440 28449535 16384 83 Linux /dev/sdb9 162662400 179440127 67110912 83 Linux /dev/sdb10 179440384 183141119 14802944 83 Linux cat crypttab cr_ata-ST9750420AS_6WS2SRHZ-part2 /dev/disk/by-id/ata-ST9750420AS_6WS2SRHZ-part2 none none cr_ata-ST9750420AS_6WS2SRHZ-part5 /dev/disk/by-id/ata-ST9750420AS_6WS2SRHZ-part5 none none cr_ata-ST9750420AS_6WS2SRHZ-part6 /dev/disk/by-id/ata-ST9750420AS_6WS2SRHZ-part6 none none cr_ata-ST9750420AS_6WS2SRHZ-part8 /dev/disk/by-id/ata-ST9750420AS_6WS2SRHZ-part8 none none
Markus W. schrieb: > Was mich irritiert, ist die Länge der Partition sdb8 > laut fdisk -l > > /dev/sdb8 28445440 28449535 16384 83 Linux Das kann nicht passen... Die Start-/Endsektoren vom ersten Post (u.a. sdb3,4 und 5) passen nicht zu den aus dem zweiten Post. Da ist irgendwas schiefgegangen... Hat dd beim Kopieren irgendwelche Fehler gemeldet? Bei Fehlern sollte ddrescue besser funktionieren. > Es ist eine veschlüssselte Partition (>500GB), aber die Länge > müsste doch bekannt sein, oder ist dies aus Sicherheitsgründen > gezielt nicht in der Partitionstabele bei einem LUKS System > enthalten. Die Partitionstabelle ändert sich nicht. Von einem Live-USB-Stick gebootet sieht es hier bspw. so aus
1 | fdisk -l |
2 | /dev/sda1 * 2048 2099199 2097152 1G 83 Linux |
3 | (das ist die hier unverschlüsselte Boot-Partition) |
4 | /dev/sda2 2099200 976773167 974673968 464,8G 83 Linux |
5 | (da sind die verschlüsselten Partitionen drauf /, swap und /home) |
Im Betrieb:
1 | /dev/sda1 * 2048 2099199 2097152 1G 83 Linux |
2 | /dev/sda2 2099200 976773167 974673968 464,8G 83 Linux |
3 | Festplatte /dev/mapper/luks-viele-Zahlen: 464,8 GiB, 499030974464 Bytes, 974669872 Sektoren |
4 | Festplatte /dev/mapper/pool-root: 20 GiB, 21474836480 Bytes, 41943040 Sektoren |
5 | Festplatte /dev/mapper/pool-swap: 8 GiB, 8589934592 Bytes, 16777216 Sektoren |
6 | Festplatte /dev/mapper/pool-home: 436,8 GiB, 468965130240 Bytes, 915947520 Sektoren |
7 | |
8 | lsblk /dev/sda |
9 | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT |
10 | sda 8:0 0 465,8G 0 disk |
11 | ├─sda1 8:1 0 1G 0 part /boot |
12 | └─sda2 8:2 0 464,8G 0 part |
13 | └─luks-viele-Zahlen |
14 | 254:0 0 464,8G 0 crypt |
15 | ├─pool-root 254:1 0 20G 0 lvm / |
16 | ├─pool-swap 254:2 0 8G 0 lvm [SWAP] |
17 | └─pool-home 254:3 0 436,8G 0 lvm /home |
> Kann mir jemand sagen, welches "magic pattern" eine LUKS Partition > am Anfang in ersten Block hat. LUKS kurz dahinter folgen lesbare Angaben zu den Algorithmen (bspw. aes und sha256) http://unix.stackexchange.com/questions/177831/recovering-a-luks-partition Edit: Vielleicht hilft auch https://alvinabad.wordpress.com/2012/09/22/how-to-recover-a-luks-encrypted-disk/ Hatte bislang noch nicht das "Vergnügen" so ein Setup reparieren zu müssen
:
Bearbeitet durch User
Markus W. schrieb: > Kann mir jemand sagen, welches "magic pattern" eine LUKS Partition > am Anfang in ersten Block hat.
1 | daniel@Daniels-Surface-Pro-3:~$ sudo dd if=/dev/sda4 bs=1 count=112 |
2 | 2>/dev/null | hexdump -C |
3 | [sudo] Passwort für daniel: |
4 | 00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| |
5 | 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
6 | 00000020 00 00 00 00 00 00 00 00 78 74 73 2d 70 6c 61 69 |........xts-plai| |
7 | 00000030 6e 36 34 00 00 00 00 00 00 00 00 00 00 00 00 00 |n64.............| |
8 | 00000040 00 00 00 00 00 00 00 00 73 68 61 35 31 32 00 00 |........sha512..| |
9 | 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
10 | 00000060 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 40 |...............@| |
Hallo Daniel, hallo Forum, danke für Deinen Hinweis. Weist Du ob man nun mittels eines loop devices via losetup -o <Offset> /dev/sdb sdb_image.bin eine Datei mit dem Image der disk als luks device mounten kann? So könnte ich die Daten der HOME Partition irgendwohin retten. Danke! Markus
Hallo Arc Net, habe Deine Antwort übersehen. Danke! Mein Erster Durchlauf entsprechend dem Vorschlag von Daniel, liefert einige Treffer. Der "skip=67508864" Parameter ist nur grob gschätzt, wo die erste gecryptete Partioion sein könnte. Bevor ich mich auf /home austobe, will ich erst /tmp und/oder /var aufspühren, da sie mehr am Anfang positioniert sind und auch nur wenige GB Größe haben. Wie gesagt, mein Fehler bestand wohl darin "testdisk" Ver. 7.0 eine neue Partition anlegen zu lassen, entsprechend den gefundenen Pattern. Dabei muss etwas schiefgegangen sein. Der Inhalt der Disk wurde aber nicht modifiziert, so dass ich noch an die Daten ran kommen müsste. Leider habe ich den luksDump Output auch auf die /tmp Partition geschrieben, die zu diesem Zeitpunkt noch funktionieret. :-( dd if=/dev/sdc bs=512 count=20000000 skip=67508864 2>/dev/null | hexdump -C | grep LUKS 06b78690 4c 55 4b 53 ba be 00 25 73 20 21 3d 20 25 73 0a |LUKS...%s != %s.| 09b5a540 52 59 50 54 2d 4c 55 4b 53 31 2d 00 2f 64 65 76 |RYPT-LUKS1-./dev| 09b5b4b0 4c 55 4b 53 ba be 00 25 73 20 21 3d 20 25 73 0a |LUKS...%s != %s.| 09c66cc0 52 59 50 54 2d 4c 55 4b 53 31 2d 00 2f 64 65 76 |RYPT-LUKS1-./dev| 09c67c30 4c 55 4b 53 ba be 00 25 73 20 21 3d 20 25 73 0a |LUKS...%s != %s.| 0ca52050 6f 72 67 3e 0a 0a 09 4c 55 4b 53 20 61 6e 64 20 |org>...LUKS and | 0ca526a0 61 6e 64 6c 65 20 4c 55 4b 53 20 61 6e 64 20 47 |andle LUKS and G| 0ca52990 29 3a 20 52 65 6e 61 6d 65 20 4c 55 4b 53 20 74 |): Rename LUKS t| 0cace300 49 43 45 5f 4c 55 4b 53 5f 49 44 2e 0a 09 2a 20 |ICE_LUKS_ID...* | 23ad3260 79 70 74 5f 4c 55 4b 53 34 37 31 35 0a 01 20 00 |ypt_LUKS4715.. .| 23ad3300 79 70 74 6f 5f 4c 55 4b 53 00 00 00 12 01 20 00 |ypto_LUKS..... .| 23ad3330 72 79 70 74 5f 4c 55 4b 53 00 00 00 14 01 20 00 |rypt_LUKS..... .| 23ad3350 6f 5f 4c 55 4b 53 00 00 82 5a 20 00 10 00 06 07 |o_LUKS...Z .....| 3c8670e0 75 72 65 00 4c 55 4b 53 20 73 69 67 6e 61 74 75 |ure.LUKS signatu| Markus
Markus W. schrieb: > Hallo Daniel, > hallo Forum, > > danke für Deinen Hinweis. > > Weist Du ob man nun mittels eines loop devices via > losetup -o <Offset> /dev/sdb sdb_image.bin eine Datei > mit dem Image der disk als luks device mounten kann? Sollte gehen. losetup -o offset /dev/loop0 image_file_name /dev/loop0 bzw. welches frei ist (losetup -f)
1 | sudo losetup -o 1 /dev/loop0 image_file_name |
2 | Ausgabe sieht dann bspw. so aus: |
3 | sudo hexdump -C -n 16 /dev/loop0 |
4 | 00000000 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 00 |UKS....aes......| |
5 | 00000010 |
Dann weiter mit dem üblichen: sudo cryptsetup luksOpen /dev/loop0 image_container sudo mount /dev/mapper/image_container /mnt Würde mir aber vorher mit dd skip=start_block ... nur den gerade benötigten Teil des Images "rausschneiden" statt mit dem gesamten Imagefile zu arbeiten und wenn's funktioniert hat wieder zurückkopieren
Ich würde das Dateisystem auf welchem das Image ist readonly mounten, um jegliche änderung am Image auszuschliessen.
Am besten die "-r" Option bei losetup verwenden.
1 | -r, --read-only |
2 | Set up a read-only loop device. |
Hallo Leute, danke für Eure Vorschläge. Die -r Option beim losetup war mir bereits bekannt. Kann man auch Teile der Verschlüsselten Partition zu Testzwecken mounten - z.B. die ersten 100MB um zu sehen, ob das Passwort angenommen wird und den Mount über /dev/mapper machen? Mir ist zwar klar, das der mount einen Fehler melden wird, da die Partition nicht vollständig ist, aber man hätte weniger Kopieraktionen mit dd um sich der richtige Stelle auf dem Image zu nähern, wo cryptsetup luksOpen einen ok Status zurück gibt. Oder kann ich mich auf das erste LUKS, dem eien aes folgt setzen und mit dd extrahieren. Da ich im Augenblick mit zwei USB-Docking-Stationen für Festplatten arbeite, ist es etwas mühselig den Ganzen Diskinhalt zu kopieren. Ich will mir ersteinmal die kleinste Partition (/var) rauschneiden und mit dem Offset in losetup an die Stelle navigieren, wo ich ein cryptsetup machen kann. Bei Erfolg würde ich mich an die /home Partition wagen. Gruß Markus Gruß Markus
Markus W. schrieb: > Kann man auch Teile der Verschlüsselten Partition zu > Testzwecken mounten - z.B. die ersten 100MB um zu sehen, > ob das Passwort angenommen wird und den Mount über > /dev/mapper machen? losetup -o offset --sizelimit size size muss ein vielfaches der Blockgröße sein. cryptsetup funktioniert danach (falls nichts beschädigt ist), mount geht erstmal nicht > mount: Falscher Dateisystemtyp, ungültige Optionen, der... sudo fsck.ext4 /dev/mapper/image_container liefert dann sowas wie > Die Größe des Dateisystems (laut Superblock) ist 23552 Blöcke. > Die physikalische Größe des Gerätes ist 14336 Blöcke. > Entweder ist der Superblock oder die Partionstabelle beschädigt!
Hallo Arc Net, im augenblick kämpfe ich mit folgendem Fenomän. Das u.g. Kommando, angewendet auf das Image der Disk findet einmal die LUKS signatur und ein erneutes mal dider nicht. Was ist da los? dd if=/run/media/markus/DATA2/sdb8_crypted_hp8730.bin bs=512 skip=227560000 count=1000000 2>/dev/null | hexdump -C | grep 'LUKS....aes' 001b8000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| Gruß Markus Übrigens, diese Meldung > Die Größe des Dateisystems (laut Superblock) ist 23552 Blöcke. > Die physikalische Größe des Gerätes ist 14336 Blöcke. > Entweder ist der Superblock oder die Partionstabelle beschädigt! hatte ich schon nach dem "testdisk" Durchlauf und dem Überschreiben der Partitionstabelle mit den ermittelten Werten. Markus
:
Bearbeitet durch User
Hallo zur Info, markus@HP8710W:~> dd if=/run/media/markus/DATA2/sdb8_crypted_hp8730.bin bs=512 skip=227560000 count=1000000 2>/dev/null | hexdump -C | grep 'LUKS....aes' 001b8000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| losetup loop0 losetup: /dev/loop0: No such file or directory # mknod -m660 /dev/loop0 b 7 8 # losetup -o 116512522240 /dev/loop0 /run/media/markus/DATA2/sdb8_crypted_hp8730.bin # cryptsetup luksOpen /dev/loop0 crypred_home Enter passphrase for /run/media/markus/DATA2/sdb8_crypted_hp8730.bin: /dev/mapper/crypred_home 504G 458G 22G 96% /mnt/crypt_home Leider sind alle Verzeichnisse leer :-( Markus
Auch wenn du als root reinschaust? Auch in lost+found nix? Was Spuckt
1 | sudo fsck -nf /dev/mapper/crypred_home |
aus?
Hallo Lukas, sowohl als root als auch als user sehe ich keinen Inhalt in den Verzeichnissen. fsck spuckt folgendes aus. fsck -nf /dev/mapper/crypred_home fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-2013) Warning! /dev/mapper/crypred_home is mounted. Error reading block 9254 (Attempt to read block from filesystem resulted in short read). Ignore error? no Resize inode not valid. Recreate? no Pass 1: Checking inodes, blocks, and sizes Error reading block 9254 (Attempt to read block from filesystem resulted in short read). Ignore error? no Error while iterating over blocks in inode 7: Attempt to read block from filesystem resulted in short read e2fsck: aborted Ist es möglich, dass zwar die Verzeichnisstruktur am Anfang der Partition intakt ist, aber danach die Fileblöcke ein Problem haben, oder die Partition zu kurz ist. Markus Nachtrag: # umount /mnt/crypt_home # fsck -nf /dev/mapper/crypred_home fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-2013) Error reading block 9254 (Attempt to read block from filesystem resulted in short read). Ignore error? no Resize inode not valid. Recreate? no Pass 1: Checking inodes, blocks, and sizes Error reading block 9254 (Attempt to read block from filesystem resulted in short read). Ignore error? no Error while iterating over blocks in inode 7: Attempt to read block from filesystem resulted in short read e2fsck: aborted Nachtrag #2 fsck -b 8193 -nf /dev/mapper/crypred_home fsck from util-linux 2.23.2 e2fsck 1.42.8 (20-Jun-2013) fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/mapper/crypred_home Could this be a zero-length partition? fdisk -s /dev/loop0 618792824
:
Bearbeitet durch User
Habe noch eine Loop über die Anfangsblöcke der
verschlüsselten Partition drüberlaufen lassen.
for i in `seq 1 1 10000`; do echo ${i}; dd if=/dev/mapper/crypred_home
bs=4096 count=1 skip=${i} | hexdump -C; done 2>> dd_loop.log 1>>
dd_loop.log
Ergebnis in der .gz Datei im Anhang.
Leider können einige Blöcke nicht gelesen werden. Danach geht es aber
wieder weiter.
???
Brauche ich jetzt dd_rescue
Gruß
Markus
:
Bearbeitet durch User
Und die letzten c.a. 20 Zeilen von
1 | dmesg |
?
Ja, wenn es um defekt Sektoren geht, würd ich dd_rescue empfehlen. Da gibt es zwei von, ich glaub die GNU Version ist die bessere von beiden. Schau mal im Internet. Teste doch mal, ob PhotoRec überhaupt Daten Findet. PS: Und schau dir hier (http://unix.stackexchange.com/questions/114429/short-read-while-trying-to-open-partition) mal die zweite Antwort an.
:
Bearbeitet durch User
Hallo Lukas, mke2fs -n /dev/mapper/crypted_home mke2fs 1.42.8 (20-Jun-2013) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 38674432 inodes, 154697694 blocks 7734884 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=4294967296 4721 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 liefert den o.g. Output. Aber!! cryptsetup -v --debug luksHeaderBackup /dev/loop0 --header-backup-file /tmp/hbck.bin # cryptsetup 1.6.2 processing "cryptsetup -v --debug luksHeaderBackup /dev/loop0 --header-backup-file /tmp/hbck.bin" # Running command luksHeaderBackup. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /dev/loop0 context. # Trying to open and read device /dev/loop0. # Initialising device-mapper backend library. # Crypto backend (gcrypt 1.5.4) initialized. # Requested header backup of device /dev/loop0 (LUKS1) to file /tmp/hbck.bin. # Reading LUKS header of size 1024 from device /dev/loop0 # Key length 32, device size 1237585648 sectors, header size 2050 sectors. # Storing backup of header (1024 bytes) and keyslot area (1045504 bytes). # Releasing crypt device /dev/loop0 context. # Releasing device-mapper backend. # Unlocking memory. Command failed with code 5: Input/output error liefert einen IO-Error!! Frage mich, wie ich am geschicktesten vorgehe. Werde Morgen weiter um meine Daten kämpfen. Danke an alle die mir bis dahin weitergeholfen haben. Markus
Noch was zum Grübeln.
Markus
fsck -b 102400000 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
fsck -b 78675968 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
fsck -b 71663616 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
fsck -b 23887872 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
dabei liefert dmsg:
2016-04-26T22:51:53.147268+02:00 HP8710W kernel: [20867.335605] Buffer
I/O error on device dm-6, logical block 5971968
2016-04-26T22:51:53.147286+02:00 HP8710W kernel: [20867.335648] Buffer
I/O error on device dm-6, logical block 5971968
2016-04-26T22:51:53.147288+02:00 HP8710W kernel: [20867.335740] Buffer
I/O error on device dm-6, logical block 11943936
2016-04-26T22:51:53.147291+02:00 HP8710W kernel: [20867.335767] Buffer
I/O error on device dm-6, logical block 11943936
2016-04-26T22:51:53.147294+02:00 HP8710W kernel: [20867.335845] Buffer
I/O error on device dm-6, logical block 23887872
2016-04-26T22:51:53.147296+02:00 HP8710W kernel: [20867.335892] Buffer
I/O error on device dm-6, logical block 23887872
2016-04-26T22:51:53.148257+02:00 HP8710W kernel: [20867.336399] Buffer
I/O error on device dm-6, logical block 47775744
2016-04-26T22:51:53.148266+02:00 HP8710W kernel: [20867.336428] Buffer
I/O error on device dm-6, logical block 47775744
2016-04-26T22:51:53.148268+02:00 HP8710W kernel: [20867.336501] Buffer
I/O error on device dm-6, logical block 95551488
2016-04-26T22:51:53.148270+02:00 HP8710W kernel: [20867.336526] Buffer
I/O error on device dm-6, logical block 95551488
Hallo Helfer, hallo Forum, Habe angefangen von der Originaldisk nochmal ein Abbild zu erzeugen. Bin jetzt an einer USB3 Dockingstation dran mit 44MB/sec. In knapp fünf Stunden, so zumindest ddrescue, sollte das Image fertig sein. ddrescue /dev/sdc ./crypt_hp8730_disk.img ./crypt_hp8730_disk.map Habt Ihr noch Vorschläge zu den Parametern von gnu ddrescue. Wie könnte ich das o.g. Kommando noch effektiver machen. Habe ich das richtig verstanden, dass das map-File, ein Wiederaufsetzen beim gescheiterten Lesen ermöglichen soll, und dass man höllisch auf- passen muss, dass der devicename auf den man ddrescue ansetzt mit dem im map-File übereinstimmen muss. Vor allem bei USB-Disks, kann sich die devicename beim erneuten anstöpseln ändern. Gruß Markus
Markus W. schrieb: > ddrescue /dev/sdc ./crypt_hp8730_disk.img ./crypt_hp8730_disk.map > > Habt Ihr noch Vorschläge zu den Parametern von gnu ddrescue. > Wie könnte ich das o.g. Kommando noch effektiver machen. Ja, Du kannst vor dem eigentlichen Start mit der Blockgröße (Parameter c) herumspielen und gucken, bei welcher Blockgröße die Übertragungsrate am höchsten ist. Immer eine Logdatei benutzen! Die sagt Dir hinter detailliert, wo es hakte. Auf diese Information solltest Du nicht verzichten. > Habe ich das richtig verstanden, dass das map-File, ein Wiederaufsetzen > beim gescheiterten Lesen ermöglichen soll, und dass man höllisch auf- > passen muss, dass der devicename auf den man ddrescue ansetzt mit dem > im map-File übereinstimmen muss. Dass man höllisch aufpassen muss, hat nichts mit dem mapfile zu tun. Bei solchen Aktionen darf man halt Start und Ziel nicht vertauschen. Im mapfile finden sich keine Gerätenamen! Welche Geräte beschrieben werden, ergibt sich aus der Parameteranordnung: ddrescue [options] infile outfile [mapfile]
Zur Info,
ddrescue ist ohne Fehler durchgelaufen:
ddrescue /dev/sdc ./crypt_hp8730_disk.img ./crypt_hp8730_disk.map
GNU ddrescue 1.21
Press Ctrl-C to interrupt
ipos: 750156 MB, non-trimmed: 0 B, current rate: 188
kB/s
opos: 750156 MB, non-scraped: 0 B, average rate: 36707
kB/s
non-tried: 0 B, errsize: 0 B, run time: 5h 40m
36s
rescued: 750156 MB, errors: 0, remaining time:
n/a
percent rescued: 100.00% time since last successful read:
0s
Finished
Wie kann das sein?
Trotzdem IO-Errors beim Verzeichnis.
Sind wohl doch Blöcke gelöscht worden,
die physikalisch in Ordnung sind aber
der Inhalt nicht zum Filesystem passt.
Markus
Markus W. schrieb: > Wie kann das sein? > Trotzdem IO-Errors beim Verzeichnis. Wer meldete IO-Fehler? ddrescue? > Sind wohl doch Blöcke gelöscht worden, > die physikalisch in Ordnung sind aber > der Inhalt nicht zum Filesystem passt. Nein. ddrescue hat nur Dein C-Gerät sektorweise kopiert. Dabei wurde der Inhalt nicht angefasst. Ganz offensichtlich hat Dein C-Gerät keine physischen Fehler.
Hallo Peter,
ich meine meinen Beitrag vom 26.04.2016 22:47.
IO-Errors beim fsck
2016-04-26T22:51:53.148268+02:00 HP8710W kernel: [20867.336501] Buffer
I/O error on device dm-6, logical block 95551488
2016-04-26T22:51:53.148270+02:00 HP8710W kernel: [20867.336526] Buffer
I/O error on device dm-6, logical block 95551488
und dem Parameter -b für veschiedene Superblöcke.
fsck -b 102400000 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
fsck -b 78675968 -fn /dev/mapper/crypted_home
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext4: Invalid argument while trying to open
/dev/mapper/crypted_home
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
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>
...
mke2fs -n /dev/mapper/crypted_home
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
38674432 inodes, 154697694 blocks
7734884 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
4721 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000
Markus
Hallo Markus, ich bin nur Linux-Gelegenheitsnutzer und mit LUKS nicht vertraut. Bitte Schnellprüfung der defektverdächtigten Platte mit smartctl -a /dev/sdx (x anpassen) und in Datei umleiten und posten. Ich vermute, Dein LUKS versagt, weil auf Deiner Platte fehlerhafte oder irreführende Partitionsinformationen vorhanden sind. Sicherheitshalber die Platte noch ein zweites Mal sektorweise kopieren. Ich bevorzuge die GNU-Version von ddrescue, die mit dem Unterstrich ist von Herrn Garloff. Diese zweite Kopie ist dann Dein Spielplatz für wilde Experimente. Welches Partitionsschema weist die Problemplatte auf, MBR oder GPT? Im folgenden Tips, die überwiegend für das MBR-Schema gelten: Mit Tabellenkalkulation versuchen, das Partitionsschema nachzuvollziehen. Dabei Informationen aus den Linuxtools verwenden. Spalten für absolute Adresse in Bytes, aber auch für Sektornummern und CHS-Adressierung benutzen. Liegen die Partitionen sauber hintereinander? Das MBR-Schema ist ja nur eine verkettete Liste, die auf den Folge-MBR und/oder ein oder mehrere Partitionen verweist. Die Partitionen der Reihe nach mounten und auf Plausibilität prüfen. Alle Dateien da, soweit die Erinnerung das zulässt? Dateisystem prüfen. Eventuell ist nur die MBR-Liste an einer Stelle gerissen. Mit welchem Betriebssystem wurde die Platte partitioniert? Mein XP orientiert sich noch an so Sachen wie Zylindergrenzen, Folgeprodukte sind wohl wie die Linuxprodukte eher MByte-orientiert. Bei GParted kann man so etwas wohl einstellen. Mit testdisk Partitionsschnellsuche und Infos loggen oder abschreiben. Im Zweifelsfalle auch Intensivsuche nutzen. Dann die Daten aus den MBRs auswerten. Mir gefällt "Runtime Explorer" ganz gut. http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf Alternativ zur MBR-Suche kannst Du auch LUKS_MAGIC auf der Platte suchen. Der Header befindet sich laut obigem Manual immer im Sektor 0 der betreffenden Partitition. Eventuell eine weitere kleine Platte partitionieren und zwei kleine LUKS-Partitionen einrichten und da das Suchen von MBRs und LUKS-headern üben.
Kann gut sein, dass LUKS durcheinander kommt, wenn man mit Offsets arbeitet.
HAllo Lukas und Peter, hallo Forum, Meine Disk aus einem NB ist 750GB groß und besitzt vier LUKS Partitionen. Die Partitionstabelle ist mit fdisk erzeugt worden, da die Disk kleiner 2TB ist. Mein Partitionsschema unter Linux ist immer gleich, wenn es die Diskgröße zulässt. PP1: /boot, sda1 PP2: swap als LUKS, sda2 PP3: /root, sda3 PP4: erweiterte Partition, meist sda5 EP1: /var als LUKS, sda6 EP2: /tmp als LUKS, sda7 EP3: /home als LUKS, sda8 EP4-6: /usr, /usr/src, /opt auf sda9/10/11 wobei PP: primäre Partition und EP: erweiterte Partition bedeutet. Gnu ddrescue konnte Gestern die gesamte Disk ohne Fehler lesen zumindest nach den Consolen Meldungen. Auch im Map-File steht nichts von Fehlern. Angefangen hat mein Problem am WE, als ich ein Kernel-Modul für die CPU-Thermal-Profile entfernen wollte (modprobe -r), weil ich auf der console nach dem reboot Fehler gefunden hatte, die besagten, das irgendeine CPU-Thermal-Tabelle/Profil nicht gefunden/geladen werden kann. Diese Meldungen überfluteten die Console, kammen aber nicht nach jedem Start. Zudem hate ich auch meine regulären Updates via zypper unter Open- Suse 13.1 gemacht, wie ich es schon seit Jahren ohne besondere Vorkommnisse mache. Mit Ausnahme der Kernelupdates, die immer eine Installation des Nvidia-Treibers nach sich ziehen, gab es bei den Updates nie Probleme. Deswegen, kann ich nicht genau sagen, wo der Wurm jetzt hergekommen ist. Beim nächstem Reboot konnte die /home Partition nicht mehr gemounted werden. VAR, TMP und SWAP funktionierten aber soweit. Ein händisches Mounten von /home über cryptsetup luksOpen /dev/sda8 /dev/mapper/... war leider nicht mehr möglich. Fehlermeldung habe ich leider gerade nicht zur Hand. Aber irgendwie ist die sda8 Partition nicht sichtbar dewesen und die erweiterte Partition zeigte unter fdisk -l /dev/sda beine logischen Laufwerke an. Daraufhin habe ich die Disk ausgebaut und in einer Dockingstation am anderen Rechner einem testdisk-Durchlauf unterzogen. Dieser hat Partitionen/Laufwerke innerhalb der erweiterten Partition gefunden und ich habe daraufhin die Partitionstabelle neu schreiben lassen. Ob das in Nachhinein klug war, kann ich mit Sicherheit nicht sagen, denn seit dem wurde aus der Partition sda5 eine sda4 und die Nummerierung der nachfolgenden Laufwerke hat sich um eins geändert. Die LUKS partitionen waren im devicemapper unter /dev/mapper als blkid-Kennung eingetragen. Jetzt nachdem ich ein Abbild habe, läuft ein dd über das Image drüber und sucht meine LUKS Partitionen. dd if=./crypt_hp8730_disk.img bs=8M count=10000 | hexdump -C | grep 'LUKS....aes' Auffallend ist auch, dass testdisk meine LUKS-PArtitionen sda6/7/8 (vorher) jetzt (sda5/6/8) kleiner gemacht hat, auf 16384 Blöcke. fdisk -l /dev/sdb (im NB war es eien sda Disk) Disk /dev/sdb: 750.2 GB, 750156374016 bytes, 183143646 sectors Units = sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: dos Disk identifier: 0x00007ce4 Device Boot Start End Blocks Id System /dev/sdb1 * 256 130559 521216 83 Linux /dev/sdb2 130560 134655 16384 83 Linux /dev/sdb3 6422016 12713471 25165824 83 Linux /dev/sdb4 12713472 183143423 681719808 f W95 Ext'd (LBA) /dev/sdb5 12713728 12717823 16384 83 Linux /dev/sdb6 15860480 15864575 16384 83 Linux /dev/sdb7 25298688 28445183 12585984 83 Linux /dev/sdb8 28445440 28449535 16384 83 Linux /dev/sdb9 162662400 179440127 67110912 83 Linux /dev/sdb10 179440384 183141119 14802944 83 Linux Mein dd Durchlauf hat schon zwei LUKS Partitionen gefunden. 1fe00000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| (swap) 9ef00000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....| (var) Ich werde jetzt versuchen VAR einzubinden. Fortsetzung folgt ;-) Markus
Hallo zur Info, auf meine var Partition bin ich schon gekommen. Für die Experten unter Euch, meinem massages File im Anhang. Am Ende scheint Müll drin zu sein. Angefangen hat der ganze Mist mit solchen Fehlermeldungen: 2016-04-23T15:27:54.116159+02:00 HP8730W kernel: [ 92.453356] cpufreq: __cpufreq_driver_target: Unable to find freq_table die mir die Console zugemüllt haben. Danke für Eure Mühe und Hilfe Markus
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.