[gelöst] Filesystem am Bobbes

Systemcrasher · 14 Nov. 2013

Tach Leutz,

wollte geben gerade eine Partition etwas vergrößern. Habe das mit ner Puppy-Version +gparted gemacht. Weil ich währenddessen ein wenig in Foren rummachen wollte und feststellte, daß die US-Tastatur aktiv ist, wollte ich die ändern - was eigentlich kein Problem hätte sein sollen.

Jedenfalls nicht aufgepaßt und plötzlich war ich in nem Textbildschirm zur Monitorkonfiguration.

Naja, damit waren alle Anwendungen eifach abgechossen - mitten in der Partitionwsvergrößerung.

Fazit: Partition am Bobbes. Weder mit e2fsck noch mit Gparted konnte ich die Sauerei beseitigen.

Gibt es ein Tool, mit dem ich dennoch auf die Partition zugreifen kann, zum Sichern einiger Dateien? Um eine Neuformatierung der Plate werde ich wohl nicht herum kommen.

Vom meisten habe ich ja Kopien, aber nicht von den allerneusten Dingen (nix überragend Wichtiges, aber trotzdem hätte ich das gerne noch gerettet).

josef-wien · 14 Nov. 2013

PhotoRec
TestDisk
eventuell ext4magic

Endlich machst Du Deinem Namen Ehre. Lesestoff: http://www.linupedia.org/opensuse/Verlorene_Dateien_wiederherstellen_ext3_ext4

Systemcrasher · 14 Nov. 2013

josef-wien schrieb:
PhotoRec
TestDisk
eventuell ext4magic

Endlich machst Du Deinem Namen Ehre. Lesestoff: http://www.linupedia.org/opensuse/Verlorene_Dateien_wiederherstellen_ext3_ext4

Danke, werde mich am WE damit beschäftigen. Sieht so aus, als käme ich sogar um eine Neuinstallation rum (betroffen ist übrigens die /home-Partition.

spoensche · 14 Nov. 2013

Sleuthkit, eine Toolsuite für Dateisystem Forensik oder die Forensikdistri Cain.

Das nächste mal solltest du es dir selber nicht unnötig schwer machen und die Frage nach den Tools stellen, bevor du mit einigen Tools die experimentelle Rettung startest, und im schlimmsten Fall wichtige Dateifragmente überschreibst, die für die Wiederherstellung wichtig sind.

PS:
Niemals direkt auf dem Datenträger arbeiten, sondern ein Image verwenden. Bei direktem arbeiten mit dem Datenträger hast du nur einen Versuch. Bei einem Image kannst du dir selbst ein paar zusätzliche "Schüsse" verschaffen.

Systemcrasher · 16 Nov. 2013

spoensche schrieb:
Das nächste mal solltest du es dir selber nicht unnötig schwer machen und die Frage nach den Tools stellen, bevor du mit einigen Tools die experimentelle Rettung startest, und im schlimmsten Fall wichtige Dateifragmente überschreibst, die für die Wiederherstellung wichtig sind.
[{quote]

Bis jetzt habe ich damit noch nicht angefangen. Grund ist die noch nicht vorhandene Kopie der Partition.

PS:
Niemals direkt auf dem Datenträger arbeiten, sondern ein Image verwenden. Bei direktem arbeiten mit dem Datenträger hast du nur einen Versuch. Bei einem Image kannst du dir selbst ein paar zusätzliche "Schüsse" verschaffen.

Zum Vergrößern anklicken....

Damit wären wir bei dem Punkt, mit dem ich heute eigentlich starten wollte. Nämlich die Sicherungskopie

:

Ursprünglich wollte ich fragen, ob diese Version hier gut ist:

Code:

Es wird die komplette fünfte Partition von /dev/sda in die erste Partition von /dev/sdb kopiert:

dd if=/dev/sda5 of=/dev/sdb1

Oder wird damit - was ich befürchte, die Zielpartition überschrieben. Ich habe nämlich keine ausreichend große und freie Platte für den zweck und wollte das daher über meine USB-Platte machen (da ist genug Platz für meherer Kopien).

Nun schreibst Du aber explizid von einem Image.

Damit dürfte dann eher diese Version hier zutreffen, oder?

Code:

 Der folgende Befehl erstellt ein Image von /dev/sda1 in die Datei image_sda1.img, welche im Heimatverzeichnis gespeichert wird:

dd if=/dev/sda1 of=~/image_sda1.img

Wobei ich natürlich logischerweise die Partitionen und Pfade anpassen muß.

Also etwa in der Art:

Code:

dd if=dev/sda7 of=/mnt/sdd2/sicherung/image1_sda7.img

Sorry, ich bin mit dd nicht so vertraut, weiß aber, daß man damit auch nachhaltig zerstören kann.

Die zitierten Befehle stammen von hier: http://wiki.ubuntuusers.de/dd

Anonymous · 16 Nov. 2013

Systemcrasher schrieb:
Wobei ich natürlich logischerweise die Partitionen und Pfade anpassen muß.

Also etwa in der Art

Code:

dd if=dev/sda7 of=/mnt/sdd2/sicherung/image1_sda7.img

das ist das was du brauchst, Das Image kannst du dann bei den meisten Programmen genauso verwenden wie eine Partition auf der Platte. Allerdings solltest du bedenken, das dein Targetdateisystem auch solche großen Dateien unterstützt. Es wird eine Datei angelegt die die Größe der gesamten Partition hat.
zB FAT32 = "Dateien dürfen max. bis zu 4 GiB − 1 Byte (= 4.294.967.295 Byte) groß werden." währe also nur bei kleinen Partitionen geeignet.

Systemcrasher schrieb:
Die zitierten Befehle stammen von hier: http://wiki.ubuntuusers.de/dd

So,So. erst bei der Konqurenz blättern und dann hier fragen

wir haben da auch eine DD-Seite im Wiki

robi

Systemcrasher · 16 Nov. 2013

robi schrieb:
zB FAT32 = "Dateien dürfen max. bis zu 4 GiB − 1 Byte (= 4.294.967.295 Byte) groß werden." währe also nur bei kleinen Partitionen geeignet.

2 Partitionen sind nort Ext4 formatiert, eine NTFS.

So,So. erst bei der Konqurenz blättern und dann hier fragen wir haben da auch eine DD-Seite im Wiki

robi

ps: Das war der erste brauchbare Link, den mir Tante Google gezeigt hat.

Aber eigentlich sollte das in der Konsole egal sein.

Dennoch: Den Linupedia schaue ich mir ebenfalls an. Oft sind die Dinge ja unterschiedlich erklärt und beides zusammen macht es dann verständlicher.

spoensche · 16 Nov. 2013

Tools, mit denen du Images erzeugen kannst: http://www.forensicswiki.org/wiki/Category

isk_Imaging

Systemcrasher · 22 Nov. 2013

robi schrieb:
Systemcrasher schrieb:

Code:

dd if=dev/sda7 of=/mnt/sdd2/sicherung/image1_sda7.img

Zum Vergrößern anklicken....

das ist das was du brauchst,

So, das wollte ich gerade machen (unter Puppy-Live-CD):

Code:

no such file or directory

Problem: Die Partition wurde ja beim Umformatieren zerstört, also ist auch die Partitionstabelle defekt. Wenn ich die Wikis von dd richtig verstanden habe, dann dürfte das dd eigentlich egal sein. Oder fehlt da noch irgendwas? :???:

josef-wien · 22 Nov. 2013

Systemcrasher schrieb:
no such file or directory

Das scheint sehr plausibel zu sein, denn im aktuellen Verzeichnis wird es

Systemcrasher schrieb:
dev/sda7

nicht geben. Du solltest

/dev/sda7

verwenden.

P. S.

Systemcrasher schrieb:
Die Partition wurde ja beim Umformatieren zerstört, also ist auch die Partitionstabelle defekt.

Der Schluß ist falsch, zuerst wurde die Partition vergrößert, dann das Dateisystem, und nur letztere Aktion hast Du "abgebrochen".

Systemcrasher · 22 Nov. 2013

Hi Josef, an dem "/" lag es sicherlich nicht. Das war lediglich an einem "Übertragungsfehler" von mir, nämlich Compi im einen Raum, Compi im anderen Raum.

Ich habe inzwischen versucht, das mit der Systemrescuecd zu machen, aber da gab es das selbe Problem.

Gparted zeigt die Partition zwar an, aber als "unbekannte".

josef-wien · 22 Nov. 2013

Ist das Verzeichnis /mnt/sdd2/sicherung/ vorhanden?

Systemcrasher · 24 Nov. 2013

josef-wien schrieb:
Ist das Verzeichnis /mnt/sdd2/sicherung/ vorhanden?

Natürlich, wobei sie manchmal auch sdc2 heißt. Allerdings ist das mit Puppy auch kaum zu übersehen.

Edit:

So, habe das jetzt nochmal mit der neusten Systemrescue-CD versucht. Damit hat es geklappt.

Systemcrasher · 27 Nov. 2013

Nachdem ich nun mit der Systemrescue-CD in der Lage war, mit dd einige Kopien der defekten Partition auf meine USB-Platte zu kopieren, stehe ich nun vor den nächsten Problemen:

1. Kann das Image nicht mounten (irgendwie logisch, da die Partition ja defekt ist und damit auch das Iso). Scheint aber Vorraussetzung zu sein, damit ich mit anderen Tools drauf zugreifen kann.

2. Mit den Tools auf der Rescue-CD komme ich nicht weiter: Photorec will immer die ganze USB-Platte analysieren, statt nur das Image. Ich weiß nicht, wie ich es dazu bringe. Testdisk dito.

Wie komme ich jetzt aus dem Dilemma? :igitt:

Anonymous · 27 Nov. 2013

wenn du dich noch wage daran erinnern könntest, was es mal für ein Dateisystemtype gewesen sein könnte, brtfs reiserfs ext2/3/4 xfs zfs ... und wie groß das Ding so Pi*Daumen vorher/hinter ist/war?

naja, das die engliche Tastatureinstellung schuld am Unfall war, hilft jedenfalls nicht weiter, dann zeig doch mal was folgende Befehle sagen ( IMAGE ist immer deine Sicherungskopie )
und bitte die Befehle und deren Ausgaben alle komplett hier mit Fehlermeldungen inclusive.
"ging nicht" , "irgendwas so wie ..." , "hab ich probiert, hat aber auch nichts gebracht" sind keine Informationen mit denen man Ferndiagnosen machen kann.

Code:

ls -l IMAGE
file IMAGE

ich vermute mal in Richtung ext4, und hoffe das file auch was ähnliches behaupten, dann

Code:

dumpe2fs -h IMAGE

wenn dort was vernünftiges kommen sollte, dann folgende beiden hinterher

Code:

dumpe2fs IMAGE | sed -ne '/^$/,+25p' 
dumpe2fs IMAGE | tail -25

Ansonsten wenn dort nichts kommt, müssen wir die große Urschleim Diagnostik anstoßen.
dann mal den folgen Befehl anstoßen und eine Zeit lang laufen lassen, sagen wir mal bis er 15 Zeilen fabriziert hat.

Code:

od -Ax -x IMAGE | awk '$6 == "ef53" && $1 ~/.*30$/ {print}'

diesen Befehl kannst du irgendwann nach 15 Zeilen oder einer 1/4 Stunde abbrechen., der dauert sonst zu lange, und wird auch die CPU etwas warm halten.

erstmal soweit, wenn die Infos da sind schau ich mir die an, dann sehen wir wie's weitergeht.

robi

Systemcrasher · 28 Nov. 2013

robi schrieb:
wenn du dich noch wage daran erinnern könntest, was es mal für ein Dateisystemtype gewesen sein könnte, brtfs reiserfs ext2/3/4 xfs zfs ... und wie groß das Ding so Pi*Daumen vorher/hinter ist/war?

Wenn ich mich nicht allzu sehr irre, ist das ext4, knapp 16 GB. Vergrößern wollte ichs in 2 Schritten. Erst mal ein paar MB, die als "unused" gekennzeichnet waren, am Ender der Partition. Dabei passierte der DAU.

Code:
Code:

ls -l IMAGE file IMAGE

Code:

-rw-r--r-- 1 root root 16293822464 25. Nov 21:50

Den Pfad habe ich jetzt mal weggelassen.

Code:
ich vermute mal in Richtung ext4, und hoffe das file auch was ähnliches behaupten, dann

Code:

dumpe2fs -h IMAGE

Code:

dumpe2fs 1.42.6 (21-Sep-2012) dumpe2fs: Ungültige magische Zahl im Superblock beim Versuch, /run/media/norman/17b9308e-2493-452c-83a2-162a571f161a/Image-sda7/Image-sda7-1.img zu öffnen Kann keinen gültigen Dateisystem-Superblock finden.

Ob das jetzt eine vernünftige Antwort ist, sei mal dahingestellt. Für mich hört sich das jedenfalls nach Super-GAU an.

Und ich wußte es ja: Linux hat was mit Magie zu tun! :zensur:

Code:
wenn dort was vernünftiges kommen sollte, dann folgende beiden hinterher

Code:

dumpe2fs IMAGE | sed -ne '/^$/,+25p' dumpe2fs IMAGE | tail -25

Habe es trotzdem mal versucht: beim 1. Befehl kommt keine Antwort, beim 2. die selbe wie beim ls-Beffehl.

Code:
Ansonsten wenn dort nichts kommt, müssen wir die große Urschleim Diagnostik anstoßen.
dann mal den folgen Befehl anstoßen und eine Zeit lang laufen lassen, sagen wir mal bis er 15 Zeilen fabriziert hat.

Code:

od -Ax -x IMAGE | awk '$6 == "ef53" && $1 ~/.*30$/ {print}'

diesen Befehl kannst du irgendwann nach 15 Zeilen oder einer 1/4 Stunde abbrechen., der dauert sonst zu lange, und wird auch die CPU etwas warm halten.

Laut htop knapp 2% Prozessorleistung. Geht also.

Code:

od -Ax -x /run/media/norman/17b9308e-2493-452c-83a2-162a571f161a/Image-sda7/Image-sda7-1.img | awk '$6 == "ef53" && $1 ~/.*30$/ {print}'
0a8030 d97c 5284 0000 ffff ef53 0001 0001 0000
2f4c330 22da adbd 1893 3ad4 ef53 9412 3bef 7aae
5140230 7494 62eb 75bb a0ee ef53 7bd6 ce74 5aa0
5530c30 5fac b4ce ea84 bf0b ef53 683b 0f8c a35e
5f22830 ac9a 7512 7e91 af95 ef53 31b5 0a96 e867
6eaa930 d1ed 1767 5f85 c450 ef53 21dc e169 0e35
80a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
b0a8030 cd68 51c8 0002 0027 ef53 0001 0001 0000
148a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
180a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
250a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
280a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
358a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
380a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
460a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
480a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000

Kann es sein, daß die wichtigen Infos in den ersten 6 Zeilen zu finden sind?

erstmal soweit, wenn die Infos da sind schau ich mir die an, dann sehen wir wie's weitergeht.

robi

.... was täte ich wohl ohne Euch und dem Linux-Club......

Anonymous · 28 Nov. 2013

Systemcrasher schrieb:
Code:

od -Ax -x /run/media/norman/17b9308e-2493-452c-83a2-162a571f161a/Image-sda7/Image-sda7-1.img | awk '$6 == "ef53" && $1 ~/.*30$/ {print}'

0a8030 d97c 5284 0000 ffff ef53 0001 0001 0000
2f4c330 22da adbd 1893 3ad4 ef53 9412 3bef 7aae
5140230 7494 62eb 75bb a0ee ef53 7bd6 ce74 5aa0
5530c30 5fac b4ce ea84 bf0b ef53 683b 0f8c a35e
5f22830 ac9a 7512 7e91 af95 ef53 31b5 0a96 e867
6eaa930 d1ed 1767 5f85 c450 ef53 21dc e169 0e35
80a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
b0a8030 cd68 51c8 0002 0027 ef53 0001 0001 0000
148a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
180a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
250a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
280a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
358a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
380a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000
460a7c30 2e22 4eca 0000 0027 ef53 0000 0001 0000
480a7c30 333e 4d87 0000 ffff ef53 0000 0001 0000

Zum Vergrößern anklicken....

Systemcrasher schrieb:
Kann es sein, daß die wichtigen Infos in den ersten 6 Zeilen zu finden sind?

ne,ne,ne so einfach ist das nicht, das rot markierte ist eine schlüssige Folge von magischen Zahlen (die Magic Markierung eines ext2/3/4 Filesystemsuperblocks mit Blockgroße 4K und dessen Kopien)

Allerdings hat der im Dateisystem einen "ungraden" Offset, (1342 x 512 Byte = 687104) als ob jemand die Partitionstabelle "Pi * Dauen" von Hand eingegeben hätte.
Schauen wir uns erstmal den an. dort ist aber noch eine 2 Serie von solchen ext-typischen Markierungen zu sehen, diese sind aber auf den ersten Blick nicht komplett und nicht ganz sauber in der Anordnung, ist es möglich das du in diesem Dateisystem mal ein ext2/3/4 Image liegen hattest, vielleicht ein USB-Image oder sowas ähnliches? Möglich aber wenig wahrscheinlich sind auch uralte Reste eines ganz alten Dateisystems, keine Ahnung wie oft du dort was an den Partitionen rumgespielt hast.

für das rote Dateisystem folgendes

Code:

modprobe loop    #ist wahrscheinlich notwendig solltest du eine Opensuse >=12.4 haben
losetup -f IMAGE -o 687104
losetup -a

der letzte Befehl sollte dir zeigen welches Loopdevice jetzt genommen worden ist, ich gehe in weiteren von /dev/loop0 aus.

Code:

file -s  /dev/loop0
dumpe2fs -h /dev/loop0

wenn das dann so aussieht wie das Dateisystem das du verloren hast, dann versuche es mal zu mounten , aber readonly

Code:

mount -o ro /dev/loop0 /mnt

möglich das er jetzt hier meckert, wenn das Dateisystem wirklich komplett durcheinander und durch den Wind ist. mal noch keinen fsck machen, ich will ein paar Ausgaben und/oder Fehlermeldungen sehen.

schau mal ob das soweit funktioniert.

robi

Systemcrasher · 29 Nov. 2013

robi schrieb:
ne,ne,ne so einfach ist das nicht, das rot markierte ist eine schlüssige Folge von magischen Zahlen (die Magic Markierung eines ext2/3/4 Filesystemsuperblocks mit Blockgroße 4K und dessen Kopien)

Wäre ja auch zu einfach, wenn es so einfach wäre.

Ergibt dies hier:

Code:

 losetup -a
/dev/loop0: [2066]:6553607 (/run/media/norman/17b9308e-2493-452c-83a2-162a571f161a/Image-sda7/Image-sda7-1.img), offset 687104

Code:
Code:

file -s /dev/loop0 dumpe2fs -h /dev/loop0

wenn das dann so aussieht wie das Dateisystem das du verloren hast, dann versuche es mal zu mounten , aber readonly

Code:

mount -o ro /dev/loop0 /mnt

Meine Erinnerung hat mich also nicht getäuscht. Ist ext4. Und Du hast recht: loop0.

Code:

 file -s  /dev/loop0
/dev/loop0: Linux rev 1.0 ext4 filesystem data, UUID=b7d03abe-5ed7-4f69-8a57-9fb4c5963708 (extents) (large files) (huge files)

 dumpe2fs -h /dev/loop0
dumpe2fs 1.42.6 (21-Sep-2012)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          b7d03abe-5ed7-4f69-8a57-9fb4c5963708
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              995520
Block count:              3977984
Reserved block count:     198899
Free blocks:              261736
Free inodes:              892307
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      971
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Mon Mar 21 12:14:58 2011
Last mount time:          Wed Nov 13 17:06:59 2013
Last write time:          Thu Nov 14 15:09:00 2013
Mount count:              0
Maximum mount count:      -1
Last checked:             Thu Nov 14 15:09:00 2013
Check interval:           0 (<none>)
Lifetime writes:          174 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5eb5db1c-8082-4e8b-9b53-facdfff5afae
Journal backup:           inode blocks
Jounaleigenschaften:         journal_incompat_revoke
Journalgrösse:            128M
Journal-Länge:            32768
Journal-Sequenz:          0x000a550b
Journal-Start:            0

Und der mount-Versuch ergab das hier:

Code:

mount -o ro /dev/loop0 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

MIt bad superblocks hatte ich schon zu tun. Kommt bei alten Festplatten gelegentlich mal vor. Allerdings habe ich das nie geschafft, das mit e2fsck in Ordnung zu bekommen. die alten Platten hab ich dann überprüft mit den smart-dingsbums-tools (

) und ggf. neu formatiert oder entsorgt. Leider sind auf der zerschossenen Partition ein paar Sachen drauf, die ich für die Steuer brauche.

ps:

Anonymous · 29 Nov. 2013

sieht gut aus. Datum letzte Änderung (laut eröffnung dieses Threads) scheint auch zu passen und last mount = /home

erstes Problem, warum der mount auf Fehler geht war schon vorauszusehen. Das Image ist zu klein und zwar um genau den Offsetwert.

hängen wir hinten mal ein paar Nullen an. folgendes erzeugt eine Datei (ich habe mal Dateinamen offset gewählt) in der richtigen Länge.

Code:

 dd if=/dev/zero of=offset bs=512 count=1342

und die hinten an das IMAGE anhängen, dazu muss aber erstmal das Loopdevice gelöscht werden und anschließend wieder mit dem bekannten Offset neu aufgesetzt werden.

Code:

losetup -d /dev/loop0
cat offset >> IMAGE
losetup -f IMAGE -o 687104
losetup -a

dann den mount (readonly) nochmal probieren. wenn wieder Fehler auftreten, dann die letzten Fehlermeldungen mit den Kernelmeldungen vom letztem Mount zB

Code:

dmesg | tail -20

Funktioniert das nicht, dann brauchen wir eine der Kopien vom Superblock, da diese wie es aussieht bei dir nicht erstellt wurde während das Dateisystem gemountet war, sollte es sich bei diesen Kopien um Kopien vom Zeitpunkt der Erstellung des urspünglichen Dateisystems handeln. Erstmal nur zum anschauen und mit dem aktuellen vergleichen.

Code:

dumpe2fs -h -o blocksize=4096 -o superblock=32768 /dev/loop0
dumpe2fs  -o blocksize=4096 -o superblock=32768 /dev/loop0 | sed -ne '/^$/,+25p' 
dumpe2fs  -o blocksize=4096 -o superblock=32768 /dev/loop0 | tail -25

Dann können wir entscheiden ob wir dann gleich eine Reparatur mittels fsck versuchen (wenn du die Partition noch nicht wieder neu benutzt hast, könnten wir ja im Zweifelsfall ein neues Image erstellen, wenn dieser Reparaturversuch so nicht funktionieren solle) oder ob wir erstmal mit ext4magic untersuchen inwieweit die Interne Struktur des Dateisystems beschädigt ist.

robi

Systemcrasher · 30 Nov. 2013

robi schrieb:
dann den mount (readonly) nochmal probieren. wenn wieder Fehler auftreten, dann die letzten Fehlermeldungen mit den Kernelmeldungen vom letztem Mount zB

Code:

dmesg | tail -20

Funzt!

Kann alle Verzeichnisse ansehen (hab das mal testweise mit ein paar probiert), ebenso konnte ich die erst beste Datei laden (Textdokument).

Dennoch hier mal die3 anschließenden dmesg-Meldung:

Code:

dmesg | tail -20
[  395.462922] sd 2:0:0:0: [sdb]  
[  395.462926] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  395.462930] sd 2:0:0:0: [sdb]  
[  395.462932] Sense Key : Medium Error [current] 
[  395.462937] sd 2:0:0:0: [sdb]  
[  395.462942] Add. Sense: Unrecovered read error
[  395.462945] sd 2:0:0:0: [sdb] CDB: 
[  395.462947] Read(10): 28 00 00 00 03 77 00 00 08 00
[  395.462959] end_request: critical target error, dev sdb, sector 887
[  395.462965] Buffer I/O error on device sdb1, logical block 824
[  395.462971] Buffer I/O error on device sdb1, logical block 825
[  395.462974] Buffer I/O error on device sdb1, logical block 826
[  395.462978] Buffer I/O error on device sdb1, logical block 827
[  395.462982] Buffer I/O error on device sdb1, logical block 828
[  395.462985] Buffer I/O error on device sdb1, logical block 829
[  395.462988] Buffer I/O error on device sdb1, logical block 830
[  395.462991] Buffer I/O error on device sdb1, logical block 831
[  551.080513] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
[  720.951635] loop: module loaded
[  810.753626] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

Code:
Funktioniert das nicht, dann brauchen wir eine der Kopien vom Superblock, da diese wie es aussieht bei dir nicht erstellt wurde während das Dateisystem gemountet war, sollte es sich bei diesen Kopien um Kopien vom Zeitpunkt der Erstellung des urspünglichen Dateisystems handeln. Erstmal nur zum anschauen und mit dem aktuellen vergleichen.

Code:

dumpe2fs -h -o blocksize=4096 -o superblock=32768 /dev/loop0 dumpe2fs -o blocksize=4096 -o superblock=32768 /dev/loop0 | sed -ne '/^$/,+25p' dumpe2fs -o blocksize=4096 -o superblock=32768 /dev/loop0 | tail -25

sicher ist sicher:

Code:

dumpe2fs -h -o blocksize=4096 -o superblock=32768 /dev/loop0
dumpe2fs 1.42.6 (21-Sep-2012)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          b7d03abe-5ed7-4f69-8a57-9fb4c5963708
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              995520
Block count:              3977984
Reserved block count:     198899
Free blocks:              3873016
Free inodes:              995509
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      971
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Mon Mar 21 12:14:58 2011
Last mount time:          n/a
Last write time:          Mon Mar 21 12:15:10 2011
Mount count:              0
Maximum mount count:      -1
Last checked:             Mon Mar 21 12:14:58 2011
Check interval:           0 (<none>)
Lifetime writes:          375 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5eb5db1c-8082-4e8b-9b53-facdfff5afae
Journal backup:           inode blocks
Jounaleigenschaften:         journal_incompat_revoke
Journalgrösse:            128M
Journal-Länge:            32768
Journal-Sequenz:          0x000a550b
Journal-Start:            0

2. Befehl:

http://pastebin.de/37645

Code:

dumpe2fs  -o blocksize=4096 -o superblock=32768 /dev/loop0 | tail -25
dumpe2fs 1.42.6 (21-Sep-2012)
  Inode-Tabelle in 3673108-3673617 (bg #112 + 3092)
  32768 freie Blöcke, 8160 freie Inodes, 0 Verzeichnisse
  Freie Blöcke: 3866644-3866655, 3866740-3866751, 3866852-3866855, 3866868-3866879, 3867632-3867647, 3868280-3868287, 3868368-3868383, 3868406-3868415, 3868912-3868927, 3869680-3869695, 3870644-3870719, 3870976-3871231, 3871605-3872767
  Freie Inodes: 962881-971040
Gruppe 119: (Blöcke 3899392-3932159) [ITABLE_ZEROED]
 Prüfsumme 0x52d0, ungenutzte Inodes 0
  Block bitmap in 3670023 (bg #112 + 7), Inode Bitmap in 3670039 (bg #112 + 23)
  Inode-Tabelle in 3673618-3674127 (bg #112 + 3602)
  32768 freie Blöcke, 8160 freie Inodes, 0 Verzeichnisse
  Freie Blöcke: 3899472-3899487, 3899510-3899519, 3899739-3899743, 3899764-3899775, 3900175-3900191, 3900214-3900223, 3900270-3900287, 3900314-3900319, 3900404-3900415, 3900591-3900607, 3900664-3900671, 3900749-3900767, 3900795-3900799, 3900856-3900863, 3901071-3901151, 3901173-3901183, 3901369-3901375, 3901425-3901439, 3901848-3901855, 3901886-3901887, 3901944-3901951, 3902078-3902079, 3902133-3902143, 3902327-3902335, 3902449-3902463, 3902576-3902591, 3902793-3902815, 3902841-3902847, 3902995-3903007, 3903032-3903039, 3903086-3903135, 3903156-3903167, 3903292-3903327, 3903411-3903455, 3903741-3903935, 3903998-3904127, 3904186-3904255, 3904657-3904703, 3904743-3904767, 3905073-3905279, 3905718-3905727, 3905764-3905813, 3905838-3905855, 3905899-3906047, 3906204-3906303, 3906816-3907711, 3907755-3907831, 3909596-3910655, 3910958-3911167, 3911424-3911428, 3911509-3911679, 3915380-3915519, 3917428-3917567, 3919872-3920895, 3921750-3921919
  Freie Inodes: 971041-979200
Gruppe 120: (Blöcke 3932160-3964927) [ITABLE_ZEROED]
 Prüfsumme 0x2fa3, ungenutzte Inodes 0
  Block bitmap in 3670024 (bg #112 + 8), Inode Bitmap in 3670040 (bg #112 + 24)
  Inode-Tabelle in 3674128-3674637 (bg #112 + 4112)
  32768 freie Blöcke, 8160 freie Inodes, 0 Verzeichnisse
  Freie Blöcke: 3935556-3935606, 3935858-3935862, 3935927-3935977, 3936108-3936255, 3941343-3941365, 3941734-3942399
  Freie Inodes: 979201-987360
Gruppe 121: (Blöcke 3964928-3977983) [ITABLE_ZEROED]
 Prüfsumme 0x1983, ungenutzte Inodes 0
  Block bitmap in 3670025 (bg #112 + 9), Inode Bitmap in 3670041 (bg #112 + 25)
  Inode-Tabelle in 3674638-3675147 (bg #112 + 4622)
  13056 freie Blöcke, 8160 freie Inodes, 0 Verzeichnisse
  Freie Blöcke: 3971582-3971583, 3971647-3971671, 3971798-3971999, 3972268-3973119, 3977710-3977727, 3977980-3977983
  Freie Inodes: 987361-995520

Dann können wir entscheiden ob wir dann gleich eine Reparatur mittels fsck versuchen (wenn du die Partition noch nicht wieder neu benutzt hast, könnten wir ja im Zweifelsfall ein neues Image erstellen, wenn dieser Reparaturversuch so nicht funktionieren solle) oder ob wir erstmal mit ext4magic untersuchen inwieweit die Interne Struktur des Dateisystems beschädigt ist.

robi

Das wäre nicht das Problem: ich habe ja gleich 5 Images angelegt, brauche also nur eine Ziffer zu ändern.

Außerdem kann ich jederzeit neue Images von der Platte ziehen. Alle Linux-Partitionen sind auf dem Rechner im Moment "unsichtbar". Ich habe einfach die XP-Partition als bootbar aktiviert und das kennt kein ext4 u.ä.

[gelöst] Filesystem am Bobbes

Hacker

Ultimate Guru

Hacker

Moderator

Hacker

Anonymous

Gast

Hacker

Moderator

Hacker

Ultimate Guru

Hacker

Ultimate Guru

Hacker

Hacker

Anonymous

Gast

Hacker

Anonymous

Gast

Hacker

Anonymous

Gast

Hacker