2. Partition "versaut"

Message
Author
winner
Posts: 16
Joined: 04. Sep 2005 13:32

#16 Post by winner »

erhoffen deshalb , weil bisher die Suche nach einer kopie des Superblocks auf der Partition nicht vom erfolg gekrönt war ...

dumpe2fs- ob [Block] /dev/hdb2 ( via script wurde da jeder Block einmal von e2fsck und dann von dumpfs geprüft
Resultat bisher :
dumpe2fs: No such file or directory while trying to open [Block]
und durchsucht wurden bisher via Script :
alle Blöcke zwischen 0 und 9999999

P.S. :
dd ... > ohne mount-möglichkeit etwas schwachbrüstig ...

dd count=8192 if=/dev/hdb2 of=datei001.img
dd: öffne /dev/hdb2?: Datei oder Verzeichnis nicht gefunden

und der mount will ja erst den geschredderten Superblock an Ort und Stelle

Wunschgedanke: cp -superblock /dev/hdb1 /dev/hdb2 :twisted:

PS: weiß jemand zufällig, ob mir das weiterhelfen könnte : ( Auszug man-Page )
debugfs
init_filesys device blocksize
Create an ext2 file system on device with device size blocksize. Note that this does not fully initialize all of the data structures; to
do this, use the mke2fs(8) program. This is just a call to the low-level library, which sets up the superblock and block descriptors.
( Soory aber mein englisch ist in etwa so gut wie meine Kochkünste ( 1 von 5 Pizzen verbrennt, bzw die Dose Ravioli auufer Herdplatte köchelt etwas an :roll:

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#17 Post by klopskuchen »

> dd ... > ohne mount-möglichkeit etwas schwachbrüstig ...
losetup -f (findet das nächste freie loop-device, wenn noch nichts "geloopt" dann /dev/loop0)
losetup /dev/loop0 datei001.img
mount /dev/loop0 /Pfad_zu_datei001.img


> und der mount will ja erst den geschredderten Superblock an Ort und Stelle
Auf was beziehst du dich? Die dd-Kopie ist dazu gedacht das Arbeiten mit der Originalpartition zu vermeiden um nicht noch mehr Schäden anzurichten. Auch zum Greppen brauchst du das Dateisystem nicht zwingend (deshalb das Argument -a für grep).


> dd count=8192 if=/dev/hdb2 of=datei001.img
> dd: öffne /dev/hdb2?: Datei oder Verzeichnis nicht gefunden
/dev/hdb2 ist nach deiner Aussage die der /home-Partition entsprechende Gerätedatei. Warum die jetzt nicht zu finden sein soll kannst nur du beantworten. Vielleicht erklärt das aber die Meldung "no such file or directory" von dumpe2fs?!

> init_filesys device blocksize
Aus der interaktiven Hilfe von debugfs:
"init_filesys Initalize a filesystem (DESTROYS DATA)"

Wenn du also deine Partition wieder gefunden hast: Was genau gibt "dumpe2fs /Gerätedatei" aus?

MfG, Klopskuchen
When all else fails, read the instructions .

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#18 Post by winner »

1.
klopskuchen wrote:Wenn du also deine Partition wieder gefunden hast: Was genau gibt "dumpe2fs /Gerätedatei" aus?
Dasselbe was e2fsck im Prinzip meldet ....

Code: Select all

:~ # dumpe2fs /dev/hdb2
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: Bad magic number in super-block while trying to open /dev/hdb2
Couldn't find valid filesystem superblock.
:~ #
Wiedergefunden ist die Partition ja nicht - die ging ja nicht "verloren" ... sie wurde nur durch die fehl-Installation "verbeult"

2.
klopskuchen wrote:losetup -f (findet das nächste freie loop-device, wenn noch nichts "geloopt" dann /dev/loop0)
schön wärs .....

Code: Select all

:~ # losetup -f
invalid option -- f
usage:
  losetup [-e encryption] [options] loop_device file  # setup
  losetup -F [options] loop_device [file]   # setup, read /etc/fstab
  losetup loop_device                       # give info
  losetup -a                                # give info of all loops
  losetup -d loop_device                    # delete
options:  -o offset  -s sizelimit  -p passwdfd  -S pseed  -H phash  -t timeout
          -I loinit  -T  -K gpgkey  -G gpghome  -C itercountk  -v  -r
:~ # losetup -F /dev/hdb2
Error: loop=/dev/hdb2 option not found in /etc/fstab
:~ # losetup /dev/hdb2
loop: can't get info on device /dev/hdb2: Invalid argument
:~ #:~ # losetup -a
:~ #
Die alte Homepartition ( /dev/hdb2) ist , da der Superblock defekt ist ( und auch sich ne Kopie versteckt ) nicht aktiv eingebunden ins System.
Und solange ein aktivieren an dem Superblockverlangen scheitert bringt eine eintragung in/etc/fstab auch nicht viel....

von daher ja auch meine Frage wegen debugfs + init_filesys device blocksize > bastelt das neue Superblöcke ? wenn ja - dann müsste es ja via undelete -Programmen möglich sein, die Dateien wiederherzustellen - und mein englisch ist da nicht so gut um das aus der man-page zu erkennen - ich kann da zu 80% nur raten ...........

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#19 Post by klopskuchen »

Die Reparaturtools suchen selbstständig nach Backups des Superblockes und legen dabei Defaultwerte zu Grunde: 4096Bytes per Block, Backups in Blockgruppe 3,5,7,9... Wenn kein Backup gefunden wird kommen als Ursache in Frage: andere Blockgröße (nur wenn bei Formatierung explizit angegeben) oder in deinem Fall ein völlig zerstörtes Dateisystem. Du hast geschrieben das die erste Partition um ca. 1,5 GB überlappte. Das du während des Formatierens abgebrochen hast hat leider nicht viel zu sagen. Das Formatieren geht seeehr schnell. Die meiste Zeit benötigt die nachfolgende Überprüfung des frischen Dateisystems. Es wäre also gut möglich das die ersten 1,5 GB deiner /home-Partition formatiert wurden. Kann, muss aber nicht sein.

> Wiedergefunden ist die Partition ja nicht - die ging ja nicht "verloren" ... sie wurde nur durch die fehl-Installation "verbeult"
Da ist nichts verbeult. Die Partition ist iO. Das Dateisystem ist offensichlich _richtig_ Schrott.

Bei der Formatierung ohne Argumente (4096Bytes/ Block) liegen die Backups der Superblöcke bei jeweils n*2^15, wobei n 1 ist und für jeden weitere Blockgruppe inkrementiert werden muss.

> debugfs + init_filesys device blocksize
Damit würdest du formatieren.

> dann müsste es ja via undelete -Programmen möglich sein,
Ein "undelete" aktiviert lediglich einen beim Löschen als frei markierten Inodentabelleneintrag. Beim Formatieren werden die Inodentabellen komplett neu erstellt.

> Die alte Homepartition ( /dev/hdb2) ist , da der Superblock defekt ist ( und auch sich ne Kopie versteckt ) nicht aktiv
> eingebunden ins System.
Du verwechselst Geräte- und Verzeichnisdatei.
/dev/hdb2 = http://de.wikipedia.org/wiki/Geraetedatei
/home = http://de.wikipedia.org/wiki/mounten

Eine weitere Ursache wäre das, wie Udo M. schon schrieb, das der Anfang der Partition nicht mehr mit dem Ursprünglichen übereinstimmt. Dann wenn Yast Käse gemacht haben sollte oder du zuvor wiederholt Partitionen im entsprechenden Bereich angelegt hast, somit mehr als eine in der engeren Auswahl standen und du die Falsche erwischt hast.

> :~ # losetup -f
> invalid option -- f
Dann hast du eine andere Version von losetup als ich. Manpage lesen. Das Mounten ist momentan ohnehin unerheblich da du für Reparatur- und Rettungsarbeiten über die Gerätedatei, also hardwarenah, auf die Partition zugreifen musst.

MfG, Klopskuchen
When all else fails, read the instructions .

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#20 Post by winner »

klopskuchen wrote:Du verwechselst Geräte- und Verzeichnisdatei.
Nein auf /dev/hdb2 lag früher die /home .. aktuell ist dieses Verzeichnis auf hdb1 ( wie auch der gesamte Rest ) und die hdb2 ist vollkomen inaktiv ( da ja nicht mountbar ).
klopskuchen wrote:Eine weitere Ursache wäre das, wie Udo M. schon schrieb, das der Anfang der Partition nicht mehr mit dem Ursprünglichen übereinstimmt. Dann wenn Yast Käse gemacht haben sollte oder du zuvor wiederholt Partitionen im entsprechenden Bereich angelegt hast, somit mehr als eine in der engeren Auswahl standen und du die Falsche erwischt hast.
Na ja Mandrake hat ja kein Yast ... nur ist die Funktion diesselbe :wink:
Partitionen waren auch bei der tödlichen ( weil fehlerhaften Installation ) auf hdb nur 2 ... root + /home ... boot und swap liegen seit Urzeiten auf ner verstaubten 500 MB als hda :oops: ( wo Mandrake die alten Daten fehlerfrei von der hda gefressen hat )
klopskuchen wrote:Dann hast du eine andere Version von losetup als ich. Manpage lesen.
Und nach was Ausschau halten ?

Code: Select all

LOSETUP(8)                   MAINTENANCE COMMANDS                   LOSETUP(8)
...
-F    Reads  and  uses mount options from /etc/fstab that match specified  loop  device,  including  offset=  sizelimit=  encryption= pseed= phash= loinit= gpgkey= gpghome= itercountk= and looped to device/file name. loop= option in /etc/fstab must  match  specified  loop  device name. Command line options take precedence in case of conflict.
Das ?
wäre dann nur die Frage wie dort die hdb2 in der fstab definieren ...

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#21 Post by klopskuchen »

> Und nach was Ausschau halten ?
Es ging bei "losetup -f" darum unbelegte loop-devices zu finden. Finden musst du also in deiner Version das zulässige Argument für das Programm das dafür definiert ist; in der manpage (man losetup).

> wäre dann nur die Frage wie dort die hdb2 in der fstab definieren ...
Die /etc/fstab dient der Automatisierung. Beim Booten und um dem mount-Befehl nicht jeden Parameter (Dateisystem usw.) manuell mitgeben zu müssen. Für deinen Fall ist sie also irrelevant.
Um einen Superblock zu finden und zurückzuschreiben brauchst du die ersten und letzten paar signifikanten Bytes des Selbigen, sowie das Offset des ersten Superblockes (nach dem obligatorischen Bootblock). Ich hab mal in die Richtung gegoogelt aber auf die Schnelle nichts gefunden.
Wenn dir ein Programm reicht das automatisiert nach bestimmten Dateitypen sucht (vielleicht auch nur "erst mal"), guck mal unter http://www.heise.de/ct/ftp/result.xhtml ... ords=dares .

MfG, Klopskuchen
When all else fails, read the instructions .

Gast

Wo war /dev/hdb2?

#22 Post by Gast »

winner, am 10. Sep 2005 18:27
erhoffen deshalb , weil bisher die Suche nach einer kopie des Superblocks auf der Partition nicht vom erfolg gekrönt war ...

dumpe2fs- ob [Block] /dev/hdb2 ( via script wurde da jeder Block einmal von e2fsck und dann von dumpfs geprüft
Resultat bisher :
dumpe2fs: No such file or directory while trying to open [Block]
und durchsucht wurden bisher via Script :
alle Blöcke zwischen 0 und 9999999
Da dein Gerät /dev/hdb2 hier nicht vorhanden war, hast Du wohl auch nichts, also keinen einzigen Block durchsucht!
Zugegeben, die Fehlermeldung von dumpe2fs ist hier leider etwas albern, weil das Gerät unterschlagen wird. (Möglicherweise bleibt diese (Einheits-)Meldung, wenn Gerät vorhanden, aber Block-Nr. zu groß.)


winner, am 11. Sep 2005 12:20

Code: Select all

:~ # dumpe2fs /dev/hdb2
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: Bad magic number in super-block while trying to open /dev/hdb2
Couldn't find valid filesystem superblock.
:~ #
Hier scheint aber /dev/hdb2 vorhanden gewesen zu sein.

klopskuchen fragte auch am 10. Sep 2005 19:04, warum /dev/hdb2 nicht vorhanden war:
> dd count=8192 if=/dev/hdb2 of=datei001.img
> dd: öffne /dev/hdb2?: Datei oder Verzeichnis nicht gefunden
/dev/hdb2 ist nach deiner Aussage die der /home-Partition entsprechende Gerätedatei. Warum die jetzt nicht zu finden sein soll kannst nur du beantworten. Vielleicht erklärt das aber die Meldung "no such file or directory" von dumpe2fs?!
Ich denke, klopskuchen vermutet richtig!

Udo M.

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#23 Post by winner »

klopskuchen wrote:> Und nach was Ausschau halten ?
Es ging bei "losetup -f" darum unbelegte loop-devices zu finden. Finden musst du also in deiner Version das zulässige Argument für das Programm das dafür definiert ist; in der manpage (man losetup).
klingt nach diesem : ( manpage )
  • OPTIONS
    -a Show status of all loop devices.
nur .... das hatte ich ja schon weiter oben angegeben :

Code: Select all

:~ # losetup -a 
 :~ #
... ohne viel Erfolg ( kein loop-Device definiert )

zu dares : mal sehen obs was nutzt ... CD/DVD haben meines Wissens einen anderen Header als Festplattenpartitionen. - vor allem eine Imagedatei existiert ja ( noch ) nicht.
dares.tgz / c't wrote:Linux: DAta REScue, eine Datenrettungssoftware, die versucht, aus dem Image einer (beschädigten) CD oder DVD Dateien anhand ihrer Header zu identifizieren und zu rekonstruieren. "Silberpuzzle", c't 16/2005, Seite 78
gast wrote:Zugegeben, die Fehlermeldung von dumpe2fs ist hier leider etwas albern, weil das Gerät unterschlagen wird. (Möglicherweise bleibt diese (Einheits-)Meldung, wenn Gerät vorhanden, aber Block-Nr. zu groß.)
Scheint ganz so als wenn dumpfs etwas einsilbig ist ...

Code: Select all

:~ # dumpe2fs -ob 1 /dev/hda5
dumpe2fs 1.35 (28-Feb-2004)
dumpe2fs: No such file or directory while trying to open 1
Couldn't find valid filesystem superblock.
:~ #
/dev/hda5 gibts nicht ... beide Festplatten bei mir besitzen jeweils 2 primäre Partitionen.

Und wegen vorhandener / nichtvorhandener /dev/hdb2 :

Ich vermute dd ( und andere Befehle ) setzen einen funktionsfähiges Dateisystem vorraus .. und da /dev/hdb2 "nur" über einen kaputten SB verfügt, können sie die Daten darauf nicht ordentlich auslesen ...
/dev/hdb2 ist ja immer im Computer ... nur halt aufgrund des Hauptproblemes ( Kaputter SB ) nirgends angemeldet oder definiert ...
( weil ohne /dev/hdb1 geht in meinem PC gar nix .... da ist aktuell ( so wie früher auch ) das Hauptsystem ( / ) + das aktuelle /home

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#24 Post by klopskuchen »

> zu dares : mal sehen obs was nutzt ... CD/DVD haben meines Wissens einen anderen Header als Festplattenpartitionen.
> - vor allem eine Imagedatei existiert ja ( noch ) nicht.
Das Prog benötigt zusammenhängende Dateien. (mehrere Blöcke in Folge gelten als auch zusammenhängend) Lediglich bei fragmentierten Dateien schwenkt es die weisse Fahne.

> /dev/hda5 gibts nicht ... beide Festplatten bei mir besitzen jeweils 2 primäre Partitionen.
Warum hast du dann /dev/hda5 angegeben? (Oder hab ich was überlesen?)

> Ich vermute dd ( und andere Befehle ) setzen einen funktionsfähiges Dateisystem vorraus...
Nein. DD (wie zB. auch cat) lesen sequentiell aus der Gerätedatei; binär. Deshalb auch die Optionen der Blockgrösse die anzugeben sind.

Zu losetup: Abhängig von der Befindlichkeit des Programmierers kann die Meldung auf losetup -a eine Fehlermeldung oder der Hinweis "(sogar) /dev/loop0 ist frei" bedeuten. Ich vermute Zweites. In dem Fall könntest du Numero 0 als loopdevice für das Image definieren.

Ich glaube immernoch der Unterschied zwischen Gerätedatei und Verzeichnisbaum ist dir nicht ganz klar (siehe wikipedia). Das ist sicher nicht der primäre Grund für das Scheitern von Reparaturversuchen. Allerdings würde dir ein besseres Verständnis um die Aufgaben und die Art wie beides angesprochen wird sicher helfen zielstrebiger vorzugehen. Ich habe versucht dein Problem in einer Emulatorinstallation zu reproduzieren. Ausser durch Formatieren der Partition habe ich es nicht geschafft das Dateisystem so zu zerstören, das ich die massive Schwierigkeit beim Reparieren habe wie sie bei dir vorliegt.

Ich kann zwar nicht versichern das jetzt "der Durchbruch" folgt. Aber es wäre hilfreich wenn du einige elementare Infos preisgibst:

fdisk -l /dev/hda
fdisk -l /dev/hdb
cat /etc/fstab
cat /proc/partitions
ls -l /dev/hdb2

Vielleicht liegt der Fehler nur in einem kleinen "miesen" Detail und ein Durchreisender ohne "Vorbelastung" findet ihn. ;)


MfG, Klopskuchen
When all else fails, read the instructions .

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#25 Post by winner »

Udo M. hat ja in seinem Posting vermutet, das dumpe2fs nicht wirklich sucht, sondern ein falsches ( nicht existentes ) Device untersucht - zugegeben, egal ob das Device existiert oder nicht - die Fehlermeldung ist diesselbe - jedoch denke ich mal das das hier diese Frage endgültig löst :oops:
Auszug aus dem Suchscript ( inzwischen etwas erweitert )

Code: Select all

 nice -n 20 e2fsck -b $z /dev/hdb2
 nice -n 20 dumpe2fs -ob $z /dev/hdb2
 nice -n 20 debugfs -b 8192 -s $z -c -R quit /dev/hdb2
 echo 
 echo Ende Schleifendurchlauf Block $z
 echo 
wobei $z den zu untersuchenden Block darstellt und bei jedem durchlauf der Schleife um 1 erhöht wird
und die Ausgabe :

Code: Select all

e2fsck 1.35 (28-Feb-2004)
e2fsck: Bad magic number in super-block while trying to open /dev/hdb2

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>

dumpe2fs 1.35 &#40;28-Feb-2004&#41;
dumpe2fs&#58; No such file or directory while trying to open 1
Couldn't find valid filesystem superblock.
debugfs 1.35 &#40;28-Feb-2004&#41;
/dev/hdb2&#58; Bad magic number in super-block while opening filesystem

Ende Schleifendurchlauf Block 1
Dasselbe Bild bietet sich auch bei Block 8193 ( Vorschlag von e2fsck )
daher schließe ich mal aus, das dumpefs auf einem nicht existenten Device sucht ( siehe Ausgaben von e2fsck und debugfs im selben Durchlauf )

nun zu den Fragen von klopskuchen:
fdisk -l /dev/hda

Code: Select all

&#58;~ # fdisk -l /dev/hda

Disk /dev/hda&#58; 1281 MB, 1281181696 bytes
64 heads, 63 sectors/track, 620 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1          18       36256+  83  Linux
/dev/hda2              19         620     1213632   82  Linux swap / Solaris
&#58;~ #
fdisk -l /dev/hdb

Code: Select all

&#58;~ # fdisk -l /dev/hdb

Disk /dev/hdb&#58; 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1       20806    10486192+  83  Linux
/dev/hdb2           20807       77545    28596456   83  Linux
&#58;~ #
cat /etc/fstab

Code: Select all

&#58;~ # cat /etc/fstab
/dev/hdb1            /                    ext2       acl,user_xattr        1 1
/dev/hda1            /boot                ext2       acl,user_xattr        1 2
/dev/hda2            swap                 swap       pri=42                0 0
devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
proc                 /proc                proc       defaults              0 0
usbfs                /proc/bus/usb        usbfs      noauto                0 0
sysfs                /sys                 sysfs      noauto                0 0
/dev/cdrecorder      /media/cdrecorder    subfs      user,fs=cdfss,ro,procuid,nosuid,nodev,exec,iocharset=utf8 0 0
/dev/fd0             /media/floppy        subfs      user,fs=floppyfss,procuid,nodev,nosuid,exec 0 0
&#58;~ #
cat /proc/partitions

Code: Select all

&#58;~ # cat /proc/partitions
major minor  #blocks  name

   3     0    1251154 hda
   3     1      36256 hda1
   3     2    1213632 hda2
   3    64   39082680 hdb
   3    65   10486192 hdb1
   3    66   28596456 hdb2
&#58;~ #
ls -l /dev/hdb2 ( und auch die anderen Devices als vergleich )

Code: Select all

&#58;~ # ls -l /dev/hdb2
brw-rw----  1 root disk 3, 66 Oct  2  2004 /dev/hdb2
&#58;~ # ls -l /dev/hdb1
brw-rw----  1 root disk 3, 65 Oct  2  2004 /dev/hdb1
&#58;~ # ls -l /dev/hda1
brw-rw----  1 root disk 3, 1 Oct  2  2004 /dev/hda1
&#58;~ # ls -l /dev/hda2
brw-rw----  1 root disk 3, 2 Oct  2  2004 /dev/hda2
&#58;~ #

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#26 Post by winner »

Zu Dares ... ( Frei nach Muphy`s Gesetzen : wenn man ein Problem hat, kommen 99 andere dazu :evil: )
:~/dateien/dares-0.6.5> ./dares
./dares: error while loading shared libraries: libmagic.so.1: cannot open shared object file: No such file or directory
1:~/dateien/dares-0.6.5> dir /usr/lib/libmagic*
-rw-r--r-- 1 root root 74730 2004-10-02 03:32 /usr/lib/libmagic.a
-rw-r--r-- 1 root root 654 2004-10-02 03:32 /usr/lib/libmagic.la
:~/dateien/dares-0.6.5>

und via Websuche nach dieser lib fand ich zwar ne menge - jedoch nur nicht diese Datei - nur Programmiererseiten und maillistarchive die diese lib erwähnen .....
Da wünsch ich mich doch glatt ins Jahr 335 - da gab es solche Ärgernisse nich

Gast

#27 Post by Gast »

Zu nächtlicher Stunde nochmal kurz zum "vermissten" /dev/hdb2: Die Fehlermeldung von dumpe2fs war ja recht zweideutig, aber dies ist doch wohl eindeutig:

Code: Select all

dd count=8192 if=/dev/hdb2 of=datei001.img
dd&#58; öffne /dev/hdb2?&#58; Datei oder Verzeichnis nicht gefunden
Hier gab es kein /dev/hdb2 ! Daher meine Vermutung, dass wohl zu diesem Zeitpunkt (noch) einiges platt gemacht wurde. Ich habe aber auch keine Lust, alle Postings zu durchforsten, um heraus zu finden, wann Du diese Meldung hattest.

Udo M.

Gast

$x1

#28 Post by Gast »

Das konnte wohl auch nicht funktioniert haben:

x=x1$x2$x3$x4$x5$x6$x7$x8
ergibt
x10000000
x10000001
x10000002
...

Code: Select all

for x1 in 1 2 3 4 5 6 7 8 9
do
 for x2 in 0 1 2 3 4 5 6 7 8 9
 do
 for x3 in 0 1 2 3 4 5 6 7 8 9
 do
 for x4 in 0 1 2 3 4 5 6 7 8 9
 do
 for x5 in 0 1 2 3 4 5 6 7 8 9
 do
 for x6 in 0 1 2 3 4 5 6 7 8 9
 do
 for x7 in 0 1 2 3 4 5 6 7 8 9
 do
 for x8 in 0 1 2 3 4 5 6 7 8 9
 do
   x=x1$x2$x3$x4$x5$x6$x7$x8
   e2fsck -b $x /dev/hdb2
  dumpe2fs -ob $x /dev/hdb2
 done
done
 done
done
 done
done
 done
done
kleine Anregung (Einzeiler zum kopieren):
x=0; while [ "${x}" -le 10 ]; do echo "${x}"; ((++x)); done

winner
Posts: 16
Joined: 04. Sep 2005 13:32

#29 Post by winner »

Gast wrote:Zu nächtlicher Stunde nochmal kurz zum "vermissten" /dev/hdb2: Die Fehlermeldung von dumpe2fs war ja recht zweideutig, aber dies ist doch wohl eindeutig:

Code: Select all

dd count=8192 if=/dev/hdb2 of=datei001.img
dd&#58; öffne /dev/hdb2?&#58; Datei oder Verzeichnis nicht gefunden
Hier gab es kein /dev/hdb2 ! Daher meine Vermutung, dass wohl zu diesem Zeitpunkt (noch) einiges platt gemacht wurde. Ich habe aber auch keine Lust, alle Postings zu durchforsten, um heraus zu finden, wann Du diese Meldung hattest.

Udo M.
Meine Vermutung : Das lag ( und liegt ) an dem nicht erkennbaren Superblock - und somit bekam dd zuwenig infos über die datenstruktur ( zb wieviele Blöcke / Sektor ... )
Gast wrote:Das konnte wohl auch nicht funktioniert haben:

x=x1$x2$x3$x4$x5$x6$x7$x8
ergibt
x10000000
x10000001
x10000002
...
Nicht ganz - echo $x ergibt
10000000
10000001
10000002
...
aber den einzeiler werd ich mal ausprobieren :)
PS: Soll ich debugfs insoweit ändern das auch die Blockgrösse durchprobiert wird ?
  • nice -n 20 e2fsck -b $z /dev/hdb2
    nice -n 20 dumpe2fs -ob $z /dev/hdb2
    nice -n 20 debugfs -b 8192 -s $z -c -R quit /dev/hdb2
    echo
    echo Ende Schleifendurchlauf Block $z
    echo
e2fsck zeigt ja 8193 an - lohnt sich eine änderung in dieser richtung ->
  • nice -n 20 e2fsck -b $z /dev/hdb2
    nice -n 20 dumpe2fs -ob $z /dev/hdb2
    nice -n 20 debugfs -b 1-32768 -s $z -c -R quit /dev/hdb2
    echo
    echo Ende Schleifendurchlauf Block $z
    echo

klopskuchen
prolinux-forum-admin
Posts: 1444
Joined: 26. Jun 2004 21:18
Contact:

#30 Post by klopskuchen »

dumpe2fs will bei mir keinen alternativen Superblock. e2fsck schon. Allerdings hast du einen Syntaxfehler gemacht. Mit "e2fsck -b $z /dev/hdb2" nimmt das Programm immer Block 0. Es fehlt das Gleichheitszeichen:
e2fsck -b=$z /dev/hdb2
Nicht ganz - echo $x ergibt
10000000
10000001
10000002
Wenn die erste Suche bei Block 10000000 erfolgte, hast du ein Offset von mindestens >3GB (bei 512Bytes per Block, das achtfache bei 4096Byes per Block).

Probier mal folgende Blöcke durch (da du nichts Gegenteiliges gesagt hast, gehe ich von den default-4kb-Blöcken aus):
e2fsck -b=32768 /dev/hdb2
e2fsck -b=98304 /dev/hdb2
e2fsck -b=163840 /dev/hdb2
e2fsck -b=229376 /dev/hdb2

Wenn sich unter den Adressen nichts intaktes finden läßt, rödel alle Blöcke mit Udos Code durch.

ps. So bescheuert die Meldung "no such file..." von dumpe2fs auch ist, es ist eine default-Fehlermeldung.

MfG, Klopskuchen
When all else fails, read the instructions .

Post Reply