restauration d'image disque avec ddrescue fail

jamesbad000 · Le 16/09/2015, à 22:48

Oui évidement dans ta manip tu as recopié la zone de boot et le début de la fat 32 tel qu'à l'origine. Mais tu as trouvé le moyen de lui faire subir une transformation étrange. par exemple le message "this is not a bootable disk..." qui apparaissait correctement plus haut

00000070  e4 cd 16 cd 19 eb fe 54  68 69 73 20 69 73 20 6e  |.......This is n|
00000080  6f 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 64 69  |ot a bootable di|
00000090  73 6b 2e 20 20 50 6c 65  61 73 65 20 69 6e 73 65  |sk.  Please inse|

est devenu

00000070  cd e4 cd 16 eb 19 54 fe  69 68 20 73 73 69 6e 20  |......T.ih ssin |
00000080  74 6f 61 20 62 20 6f 6f  61 74 6c 62 20 65 69 64  |toa b ooatlb eid|
00000090  6b 73 20 2e 50 20 65 6c  73 61 20 65 6e 69 65 73  |ks .P elsa enies|

Tous les octets sont inversés par pair. Qu'est ce que tu as utilisé comme commande et paramètres pour faire ça ???

tu peux faire

sudo hd -n 1024 /tonImage

qu'on voit ce que tu as mis dans l'image maintenant.

edit : dans l'aide de dd je trouve une option qui colle bien avec ce délire...

swab   swap every pair of input bytes

edit 2: De toute façon le meilleur original est maintenant sdb. Donc on ne fait plus de manip dessus, sauf pour recopier. et on va travailler avec l'image.
Pour toucher sdb c'est comme pour déclencher l'arme nucléaire, il faudra être 2

Dernière modification par jamesbad000 (Le 16/09/2015, à 23:52)

Ux · Le 17/09/2015, à 09:45

Hello,

jamesbad000 a écrit :

Oui évidement dans ta manip tu as recopié la zone de boot et le début de la fat 32 tel qu'à l'origine. Mais tu as trouvé le moyen de lui faire subir une transformation étrange. par exemple le message "this is not a bootable disk..." qui apparaissait correctement plus haut
00000070  e4 cd 16 cd 19 eb fe 54  68 69 73 20 69 73 20 6e  |.......This is n|
00000080  6f 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 64 69  |ot a bootable di|
00000090  73 6b 2e 20 20 50 6c 65  61 73 65 20 69 6e 73 65  |sk.  Please inse|
est devenu
00000070  cd e4 cd 16 eb 19 54 fe  69 68 20 73 73 69 6e 20  |......T.ih ssin |
00000080  74 6f 61 20 62 20 6f 6f  61 74 6c 62 20 65 69 64  |toa b ooatlb eid|
00000090  6b 73 20 2e 50 20 65 6c  73 61 20 65 6e 69 65 73  |ks .P elsa enies|
Tous les octets sont inversés par pair. Qu'est ce que tu as utilisé comme commande et paramètres pour faire ça ???

Hmmm alors la je ne sais pas, je n'ai utilisé aucuns paramètres supplémentaires que tes commandes (que j'ai mal transposées pour l'image .dd, je vais verifier dans mon historique tout de meme).

jamesbad000 a écrit :

tu peux faire
sudo hd -n 1024 /tonImage 
qu'on voit ce que tu as mis dans l'image maintenant.
edit : dans l'aide de dd je trouve une option qui colle bien avec ce délire...
swab   swap every pair of input bytes
edit 2: De toute façon le meilleur original est maintenant sdb. Donc on ne fait plus de manip dessus, sauf pour recopier. et on va travailler avec l'image.
Pour toucher sdb c'est comme pour déclencher l'arme nucléaire, il faudra être 2

Je fais ca ce midi ! OK pour le bouton rouge et la mallette nucleaire... :-)

Ux · Le 17/09/2015, à 12:50

Sur l'image ça a l'air dans l'ordre

 sudo hd -n 1024 /media/ux/WD3TO/2tob.dd 
[sudo] password for ux: 
00000000  eb 58 90 6d 6b 64 6f 73  66 73 00 00 02 20 20 00  |.X.mkdosfs...  .|
00000010  02 00 00 00 00 f8 00 00  3f 00 ff 00 00 00 00 00  |........?.......|
00000020  b0 88 e0 e8 40 8c 0e 00  00 00 00 00 02 00 00 00  |....@...........|
00000030  01 00 06 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 29 76 7b 6a 6a 20  20 20 20 20 20 20 20 20  |..)v{jj         |
00000050  20 20 46 41 54 33 32 20  20 20 0e 1f be 77 7c ac  |  FAT32   ...w|.|
00000060  22 c0 74 0b 56 b4 0e bb  07 00 cd 10 5e eb f0 32  |".t.V.......^..2|
00000070  e4 cd 16 cd 19 eb fe 54  68 69 73 20 69 73 20 6e  |.......This is n|
00000080  6f 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 64 69  |ot a bootable di|
00000090  73 6b 2e 20 20 50 6c 65  61 73 65 20 69 6e 73 65  |sk.  Please inse|
000000a0  72 74 20 61 20 62 6f 6f  74 61 62 6c 65 20 66 6c  |rt a bootable fl|
000000b0  6f 70 70 79 20 61 6e 64  0d 0a 70 72 65 73 73 20  |oppy and..press |
000000c0  61 6e 79 20 6b 65 79 20  74 6f 20 74 72 79 20 61  |any key to try a|
000000d0  67 61 69 6e 20 2e 2e 2e  20 0d 0a 00 00 00 00 00  |gain ... .......|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  52 52 61 41 00 00 00 00  00 00 00 00 00 00 00 00  |RRaA............|
00000210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003e0  00 00 00 00 72 72 41 61  7f 1b 46 07 02 00 00 00  |....rrAa..F.....|
000003f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000400

jamesbad000 · Le 17/09/2015, à 14:37

Ux a écrit :

Sur l'image ça a l'air dans l'ordre

Et bien c'est très mauvais signe:
Vraisemblablement en recopiant ton image tronquée vers sdb tu as écrasé le début du disque en inversant les octets.
Ensuite en faisant la nouvelle image tu as fait la même inversion, mais sur toute l'image cette fois. Ce qui explique que le début à l'air normal... Et laisse supposer que tous le reste est à l'envers... Ce qui tombe assez mal, puisque c'est justement la partie utile qui se trouve ainsi cul par dessus tête.

Ux a écrit :

jamesbad000 a écrit :
Qu'est ce que tu as utilisé comme commande et paramètres pour faire ça ???
Hmmm alors la je ne sais pas, je n'ai utilisé aucuns paramètres supplémentaires que tes commandes

Je ne t'ai indiqué aucune commande pour copier ton image vers sdb ou dans l'autre sens. Ceci est le résultat d'un travail "très" personnel, et original certes. Mais impropre à la consommation.

Et en plus comme tu l'as certainement fait 2 fois, les excuses du genre : "j'étais pas la au début", "je regardais ailleurs", "j'avais une araignée au plafond" ou "l'éléphant bleu est passé à ce moment, et a foutu le bordel", ça ne tient pas.
Alors tu vas me cracher le morceau, même si je dois te coller des coups de bottin virtuel sur la tête jusqu'à la fin de mes jours !

Ensuite on va vérifier si l'image est exploitable ou non avec (un exemple de retour valide dans ce post https://forum.ubuntu-fr.org/viewtopic.p … p20581621)

sudo dumpe2fs -h -o superblock=214990848 /fichierImage

si le résultat de la commande précédente se résume à 2 ou 3 lignes de message d'insultes, on essaye sur sdb (oui ! c'est une manip en lecture seule)

sudo dumpe2fs -h -o superblock=214990848 /dev/sdb

Et donc si l'image est foireuse et pas sdb, refaire l'image avec :

sudo dd if=/dev/sdb of=/fichierImage bs=4k

Et la, tu prend le temps de respirer et relire que ça copie bien de sbd vers l'image !!

Et si tout est pété, tu peux aller à la plage...
autrement on continue avec :

# efface la signature fat32 ainsi que début fat.

sudo dd if=/dev/zero of=/fichierImage  count=36 conv=notrunc

# cherche les 1ers octets non initialisés

sudo hexdump  /fichierImage | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'

Laisser refroidir... Et ne pas oublier de me retourner le contenu COMPLET du terminal !

Dernière modification par jamesbad000 (Le 17/09/2015, à 14:43)

Ux · Le 17/09/2015, à 15:32

jamesbad000 a écrit :

Ux a écrit :
Sur l'image ça a l'air dans l'ordre
Et bien c'est très mauvais signe:
Vraisemblablement en recopiant ton image tronquée vers sdb tu as écrasé le début du disque en inversant les octets.
Ensuite en faisant la nouvelle image tu as fait la même inversion, mais sur toute l'image cette fois. Ce qui explique que le début à l'air normal... Et laisse supposer que tous le reste est à l'envers... Ce qui tombe assez mal, puisque c'est justement la partie utile qui se trouve ainsi cul par dessus tête.
Ux a écrit :
jamesbad000 a écrit :
Qu'est ce que tu as utilisé comme commande et paramètres pour faire ça ???
Hmmm alors la je ne sais pas, je n'ai utilisé aucuns paramètres supplémentaires que tes commandes
Je ne t'ai indiqué aucune commande pour copier ton image vers sdb ou dans l'autre sens. Ceci est le résultat d'un travail "très" personnel, et original certes. Mais impropre à la consommation.
Et en plus comme tu l'as certainement fait 2 fois, les excuses du genre : "j'étais pas la au début", "je regardais ailleurs", "j'avais une araignée au plafond" ou "l'éléphant bleu est passé à ce moment, et a foutu le bordel", ça ne tient pas.
Alors tu vas me cracher le morceau, même si je dois te coller des coups de bottin virtuel sur la tête jusqu'à la fin de mes jours !

Oui désolé si je ne suis pas assez précis... (j'ai mérité mon coup de botin :-) ) Je recapitule, dans l'ordre:

la commande qui a ecrasé mon image:

sudo dd  if=/dev/zero of=/media/ux/WD3TO/2to.dd bs=1 count=16 seek=$((0x1d18c000))

après le script:

rm ~/sdb.delblocks  ; 
bMax=169811;
for ((b=8865; b<$bMax; )); do 
  echo -en "$b\r"; 
  b2=$b;
  b3=$(($b+1000));
  bList="";
  for ((; b<$b3; b++)); do
    bList="$bList $b";
    if (($b==$bMax)); then break; fi;
  done;
  sudo debugfs -s 214990848 -b 4096 -R "icheck $bList" /media/ux/WD3TO/2to.dd 2>/dev/null | sed -re '/[0-9]+\s+[0-9]+/!d' >> ~/sdb.delblocks ; 
done;

apres, restauration de mon image sur sdb :

ux@gni:~$ sudo ddrescue -f /media/ux/WD3TO/2to.dd /dev/sdb

la je me rends compte de mes conneries.

je fais une nouvelle image de /sdb :

ddrescue /dev/sdb /media/WD3TO/2tob.dd /media/WD3TO/2tob.log -n

Pour la suite, je reviens quand je trouve le temps de me poser calmement devant le probleme, sinon je vais encore faire des betises...

Merci de ta patience James en tout cas...

Dernière modification par Ux (Le 17/09/2015, à 16:28)

jamesbad000 · Le 17/09/2015, à 17:49

Ux a écrit :

je fais une nouvelle image de /sdb :
ddrescue /dev/sdb /media/WD3TO/2tob.dd /media/WD3TO/2tob.log -n

Bon. La je suis bien obligé d'admettre que tu n'a commis aucun impair à ce niveau, et que l'inversion ne vient pas de là.

Ne me restait plus qu'à envisager que c'est le hexdump utilisé sans paramètre de mise en forme qui est le résultat de cette hérésie.
Et vérification faite, c'est bien hexdump le coupable. Et non moi comme tu aurais pu oser le penser de façon impardonnable

Je retourne ma veste donc. Et anticipe maintenant un résultat positif du test de l'image. te non nu érustl a nirvianslblb e...

Ux · Le 18/09/2015, à 19:31

Hello, me revoila avec un resultat qui si j'ai bien compris, dit que ma nouvelle image est correcte :

ux@gni:~$ sudo dumpe2fs -h -o superblock=214990848 /media/ux/WD3TO/2tob.dd
[sudo] password for ux: 
dumpe2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   Data
Last mounted on:          <not available>
Filesystem UUID:          dbab2b6e-7e51-43f2-9730-e96f3384c0df
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:              122101760
Block count:              488378646
Reserved block count:     24418932
Free blocks:              48402226
Free inodes:              121695320
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      907
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              1
RAID stripe width:        1
Flex block group size:    16
Filesystem created:       Fri Jul 15 19:52:30 2011
Last mount time:          n/a
Last write time:          Mon Sep 14 13:10:17 2015
Mount count:              0
Maximum mount count:      20
Last checked:             Mon Sep 14 13:10:17 2015
Check interval:           15552000 (6 months)
Next check after:         Sat Mar 12 12:10:17 2016
Lifetime writes:          337 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:      1c614f70-d6f1-4f24-8fff-858c9486ae57
Journal backup:           inode blocks
Journal superblock magic number invalid!

Si j'ai bien compris je peux passer à l’effaçage de la fat sur mon image... ?! me dire si je me trompe

jamesbad000 · Le 18/09/2015, à 20:22

Oui, c'est ça.
# efface la signature fat32 ainsi que début fat.

sudo dd if=/dev/zero of=/fichierImage  count=36 conv=notrunc

# cherche les 1ers octets non initialisés

sudo hexdump  /fichierImage | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'

Dernière modification par jamesbad000 (Le 18/09/2015, à 20:25)

Ux · Le 18/09/2015, à 22:24

Et voila ce que ca donne :

ux@gni:~$ sudo dd if=/dev/zero of=/media/ux/WD3TO/2tob.dd  count=36 conv=notrunc 
[sudo] password for ux: 
36+0 enregistrements lus
36+0 enregistrements écrits
18432 octets (18 kB) copiés, 0,621068 s, 29,7 kB/s

ux@gni:~$ sudo hexdump  /media/ux/WD3TO/2tob.dd | grep -E -m 30 -ve '[0-9]+ 0000 0000 0000 0000 0000 0000 0000 0000' -ve '\*'
28000000 2000 0747 1116 1d1c 9a74 0174 8f32 02e2
28000010 ec58 0740 0000 0000 0002 0000 0002 0000
28000020 8000 0000 8000 0000 2000 0000 0000 0000
28000030 ab19 55f6 0000 0014 ef53 0000 0001 0000
28000040 ab19 55f6 4e00 00ed 0000 0000 0001 0000
28000050 0000 0000 000b 0000 0100 0005 003c 0000
28000060 0242 0000 007b 0000 abdb 6e2b 517e f243
28000070 3097 6fe9 8433 dfc0 6144 6174 0000 0000
280000c0 0000 0000 0000 0000 0000 0000 0000 038b
280000e0 0008 0000 0000 0000 0000 0000 611c 704f
280000f0 f1d6 244f ff8f 8c85 8694 57ae 0101 0000
28000100 0000 0000 0000 0000 7e5e 4e20 f30a 0002
28000110 0004 0000 0000 0000 0000 0000 7fff 0000
28000120 8000 0e88 7fff 0000 0001 0000 ffff 0e88
28000140 0000 0000 0000 0000 0000 0000 0000 0800
28000150 0000 0000 0000 0000 0000 0000 001c 001c
28000160 0001 0000 0001 0000 0000 0000 0000 0000
28000170 0001 0000 0004 0000 422a 0005 0000 0000
28001000 0401 0000 0411 0000 0421 0000 5bdc 1ff5
28001010 0002 0000 0000 0000 0000 0000 1ff5 3ffb
28001020 0402 0000 0412 0000 0621 0000 7859 2000
28001030 0000 0001 0000 0000 0000 0000 2000 d900
28001040 0403 0000 0413 0000 0821 0000 8000 2000
28001050 0000 0001 0000 0000 0000 0000 2000 5117
28001060 0404 0000 0414 0000 0a21 0000 78b7 2000
28001070 0000 0001 0000 0000 0000 0000 2000 b28b
28001080 0405 0000 0415 0000 0c21 0000 8000 2000
28001090 0000 0001 0000 0000 0000 0000 2000 1b41
280010a0 0406 0000 0416 0000 0e21 0000 79bc 2000
280010b0 0000 0001 0000 0000 0000 0000 2000 711c

c'est grave docteur ? odtcue?r pardon;-)

Dernière modification par Ux (Le 18/09/2015, à 22:32)

jamesbad000 · Le 18/09/2015, à 23:20

Ok il n'y a plus qu'à refaire un coup de

sudo fsck.ext4  -yf -b 214990848 /media/ux/WD3TO/2tob.dd

puis recopie tes fichiers. On verra ensuite pour la liste des fichiers défectueux.

Ux · Le 19/09/2015, à 00:51

C'est bon ca copie... :-)

Par contre je manque de place, je peux formater sdb et m'en servir du coup ? (tjs peur de la boulette à ce stade...)

jamesbad000 · Le 19/09/2015, à 10:47

Je crois que oui, si vraiment tu n'a plus le choix. Ca serait dommage que ce disque serve de décoration plutôt qu'à récupérer tes fichiers.

Ux · Le 20/09/2015, à 16:43

Et voila c'est (enfin) copié !

jamesbad000 · Le 21/09/2015, à 01:12

Ok. On va refaire la procédure de recherche des fichiers écrasés. Légèrement modifiée, de façon à pouvoir vérifier que ça fonctionne. (Mais il est tout à fait possible qu'il n'y en ait pas...)

bMax=169812;
for ((b=8865; b<$bMax; )); do 
  echo -en "$b\r"; 
  b2=$b;
  b3=$(($b+1000));
  bList="";
  for ((; b<$b3 && b<$bMax; b++)); do
    bList="$bList $b";
  done;
  sudo debugfs -s 214990848 -b 4096 -R "icheck $bList" /media/ux/WD3TO/2tob.dd  2>/dev/null >> ~/sdb.delblocks ; 
done;
grep -E -c '^[0-9]+\s+<block not found>' ~/sdb.delblocks;
grep -E -c '^[0-9]+\s+[0-9]+' ~/sdb.delblocks;

Ca devrait donner le retour du nombre de block non utilisés et utilisés.

Puis ci-dessous pour extaire la liste des fichiers correspondant aux blocs utilisés

nodes=$(sed -re '/[0-9]+\s+[0-9]+/!d' -e  's:[0-9]+\s+([0-9]+):\1:' ~/sdb.delblocks  | sort | uniq); debugfs -s 214990848 -b 4096 -R "ncheck $(echo $nodes)" /media/ux/WD3TO/2tob.dd > ~\sdb.badFiles; head ~\sdb.badFiles;

Dernière modification par jamesbad000 (Le 21/09/2015, à 01:15)

Ux · Le 22/09/2015, à 21:20

OK, ca a prit un peu de temps (~24h)

voila ce que ca donne :

ux@gni:~$ grep -E -c '^[0-9]+\s+<block not found>' ~/sdb.delblocks;
155870
ux@gni:~$ grep -E -c '^[0-9]+\s+[0-9]+' ~/sdb.delblocks;
5077

Je viens de lancer l'extraction des noms de fichiers, ca risque de prendre un peu de temps aussi j'imagine !

jamesbad000 · Le 22/09/2015, à 23:39

C'est bien plus long que ce à quoi je pouvais m'attendre d'après mes test.

L'extraction de la liste des fichiers d'après les inodes devraient quand même être beaucoup plus rapide.

Du fait que la liste est obtenu après réparation, il est fort possible que certain fichiers ou même répertoires s'y trouvent à tord. (Par exemple le répertoire lost+found a très bien pu être créé dans la zone précédemment effacée..)

Tout fichier ou répertoire qui aura une date de création >= à la date de la première réparation est en principe hors de cause (a condition que l'horloge du pc soit correcte)

Dernière modification par jamesbad000 (Le 22/09/2015, à 23:40)

Ux · Le 23/09/2015, à 20:04

Salut Jamesbad,

Effectivement la recuperation des noms de fichiers n'a pas pris tant de temps que ça, et j'ai bien récupéré une liste d'une dizaine de fichiers (seulement une dizaine !), qui après vérification, sont bien tous corrompus (mais sans importance aucune).

Je crois que c'est le moment de te remercier sincèrement pour ton aide, ta patience et surtout ton efficacité ! Qu'on se le dise sur le forum ! Il est évident que je ne serai jamais allé aussi loin seul...
Je crois aussi que ce post pourra servir de référence dans le domaine (si on enlève mes boulettes passagères xD).

jamesbad000 président !

jamesbad000 · Le 23/09/2015, à 22:13

Ux a écrit :

jamesbad000 président !

Non ca va pas être possible, j'ai une phobie administrative...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 16/09/2015, à 22:48

Re : restauration d'image disque avec ddrescue fail

#52 Le 17/09/2015, à 09:45

Re : restauration d'image disque avec ddrescue fail

#53 Le 17/09/2015, à 12:50

Re : restauration d'image disque avec ddrescue fail

#54 Le 17/09/2015, à 14:37

Re : restauration d'image disque avec ddrescue fail

#55 Le 17/09/2015, à 15:32

Re : restauration d'image disque avec ddrescue fail

#56 Le 17/09/2015, à 17:49

Re : restauration d'image disque avec ddrescue fail

#57 Le 18/09/2015, à 19:31

Re : restauration d'image disque avec ddrescue fail

#58 Le 18/09/2015, à 20:22

Re : restauration d'image disque avec ddrescue fail

#59 Le 18/09/2015, à 22:24

Re : restauration d'image disque avec ddrescue fail

#60 Le 18/09/2015, à 23:20

Re : restauration d'image disque avec ddrescue fail

#61 Le 19/09/2015, à 00:51

Re : restauration d'image disque avec ddrescue fail

#62 Le 19/09/2015, à 10:47

Re : restauration d'image disque avec ddrescue fail

#63 Le 20/09/2015, à 16:43

Re : restauration d'image disque avec ddrescue fail

#64 Le 21/09/2015, à 01:12

Re : restauration d'image disque avec ddrescue fail

#65 Le 22/09/2015, à 21:20

Re : restauration d'image disque avec ddrescue fail

#66 Le 22/09/2015, à 23:39

Re : restauration d'image disque avec ddrescue fail

#67 Le 23/09/2015, à 20:04

Re : restauration d'image disque avec ddrescue fail

#68 Le 23/09/2015, à 22:13

Re : restauration d'image disque avec ddrescue fail

Pied de page des forums