Réparer une partition, ext3, reiserfs.

Recherche :

Dernière réponse
Sujet : Réparer une partition, ext3, reiserfs.
mexx20	Mon script n'a pas trouvé de super block (que ce soit en 1k, 2k ou 4k) :( Je crois que je vais abandonner ...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

mexx20

Mon script n'a pas trouvé de super block (que ce soit en 1k, 2k ou 4k) :( Je crois que je vais abandonner ...

mexx20

Citation :

L'intention est louable mais de la façon que tu es parti, c'est la façon idéale de démontrer comment détruire son disque dur.

Si je voulais détruire mon disque dur, je ne posterais pas ici.

L'idée est : tu possèdes une machine qui tourne très bien et on te donne un HD possédant une partition abimée, tu le branches sur ton périphérique IDE et tu travailles directement sur un périphérique /dev/hdXX avec à ta disposition tout un arsénal d'outils. La façon rigide et spécifique que tu appelles "rescue disk" est bien moins flexible.

Citation :

La procédure habituelle c'est booter le systeme en mode rescue et de simplement lancer un fsck.ext3

Non ! Ce que tu ne comprends pas c'est que pour lancer "fsck.ext3" tu dois lui spécifier où se situe le "superblock" (car dans mon cas il ne le trouve pas automatiquement). De plus, un "rescue disk" ce n'est qu'une couche qui utilise ces outils qui sont à ma disposition.

Citation :

Pour ton script les blocs par défaut son de 8192 et et non 4096. Donc, les superblocks se retrouvent à 8193, 16385, etc.

Non, 4096 c'est la taille et non l'indice !

rdc3

Citation :

Ainsi, si nous étudions ce problème indépendamment de ce CD, ce forum servira à d'autre personne de par son caractère plus généraliste.

L'intention est louable mais de la façon que tu es parti, c'est la façon idéale de démontrer comment détruire son disque dur. :D

Je t'ai trouvé un nouveau pseudo mexx the hd destructor. C'est amical et pas méchant. Je comprends la tentation.
:jap:

Pour ton script les blocs par défaut son de 8192 et et non 4096. Donc, les superblocks se retrouvent à 8193, 16385, etc. Par contre, je ne vois pas où est-ce que tu veux en venir à part la destruction de ton disque bien sûr. :jap: Ça je le comprends, pourquoi faire simple lorsque l'on peut faire compliquer.

En relisant un peu le thread je me demande si tu n'as pas simplement tenté de réparer ton disque en étant mounter dessus.

La procédure habituelle c'est booter le systeme en mode rescue et de simplement lancer un fsck.ext3

mexx20

Citation :

Malheureusement, il me semble que
dans ces conditions, je ne peux consulter le fichier "/etc/fstab" pour le
découvrir. Ma première question est la suivante : Comment déterminer le type
de système de fichiers pour une partition donnée ?

En y réfléchissant un peu je me suis dit que mon système de fichier n'étant pas crypté, il devrait être possible de retrouver du texte brut en lisant directement le fichier device. J'ai alors essayé la commande suivante :

grep -a -B10 -A10 '/dev/hda2' /dev/hdc2 | strings

qui m'a permit de récupérer mon fichier /etc/fstab et de découvrir qu'il s'agissait effectivement de "ext3" et n'on pas de "reiserfs" !!!!!

Le "superbloc" ayant été écrasé par la commande "reiserfsck", mon problème se concretise et consite, je pense, à retrouver une sauvegarde d'un "superblock". Les indices proposés par "mke2fs" n'allant pas, j'ai écrit un petit script (voir le code bash ci-dessous) pour tester tous les indices possibles de façon exhaustive. Pensez-vous que c'est une bonne idée ? C'est très long : cela fait 5 heures qu'il tourne et il n'en est qu'a 5%.

J'ai supposé que la taille des blocs est de 4kb (=4096 bytes). Comme mon disque fait 20490559488 bytes (information donnée par fdisk) je suppose que le dernier bloc est à l'indice 20490559488 / 4096 = 5002578. Pourriez-vous me confirmer ces deux hypothèses ?

Code :

#!/bin/sh
begin=1
end=5002578
device=/dev/hdc2
bsize=4096
tmpfile=/tmp/tmp.file
for (( i=$begin ; $i <= $end ; i=$i+1 )); do
echo "open $device -b $bsize -s $i" > $tmpfile
output=`debugfs -f $tmpfile 2>&1 | grep "Bad magic number"`
if [ -z output ]; then echo "$i"; fi
done
rm $tmpfile

mexx20

Citation :

si tu fais un fdisk -l /dev/hdc, il te sort quoi?

# fdisk -l /dev/hdc

Disk /dev/hdc: 20.4 GB, 20490559488 bytes
255 heads, 63 sectors/track, 2491 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdc1 1 31 248976 82 Linux swap
/dev/hdc2 * 32 2491 19759950 83 Linux

Citation :

Question : Est-ce que ton système est bien une Slackware version 10.0?

Non, il s'agit de << slackware-current >>, une version située entre 10.1 et 10.2 mais fort proche de cette dernière.

Citation :

Bref, commence par démarrer le rescue et ensuite reviens nous voir.

Ce n'est pas une mauvaise idée ! mais ... ne disposant ni d'internet ni de graveur j'aurais un peu de mal à télécharger l'image disque et la graver. De toute façon, les opérations que réalisent le script de récupération doivent pouvoir se faire manuellement. Ainsi, si nous étudions ce problème indépendamment de ce CD, ce forum servira à d'autre personne de par son caractère plus généraliste.

Citation :

badblocks est une commande pour vérifier le dd, voir s'il y a des blocs défectueux et éventuellement les "réparer", ou tout au moins, les marquer

D'après la page du manuel, cet utilitaire est utilisé par "e2fsck" et "mke2fs" comme couche inférieure, donc je l'utilisais déjà sans m'en rendre compte avec l'argument "-c"; mais de toute façon il a besoin du superblock et donc ce scan ne peut démarrer !

rdc3

Citation :

Tout es relatif, à mon sens oui, j'aimerais bien tout récupérer.

Donc, on respire par les trous du nez et tu ne te lances pas en fou avec toutes sortes de commandes aléatoires.

La première chose à faire c'est de bien comprendre ton système. Ta distribution est une slackware. Malheuresement, je ne connais pas vraiment la Slackware, mais j'ai pu trouver ceci :

CD 1 - Premier CD d'installation Slackware Linux 10.0, Bootdisks, Rootdisks
CD 2 - Deuxième Cd d'installation Slackware Linux 10.0, Slackware Rescue, Testing (Linux 2.6.7, GCC 3.4.0, LVM2), Kernels (noyaux de Linux pour Slackware), KDE, KDEI (paquets nationaux pour KDE) et GNOME
CD 3 - Sources de Slackware Linux 10.0 partie 1, manuel Slackware Linux Essentials et Extra (paquets supplémentaires pour Slackware 10.0 - binaires et sources)
CD 4 - Sources Slackware Linux 10.0 partie 2, Pasture et ZipSlack

Le rescue semble être sur le CD2, il faut commencer par réussir à démarrer le système rescue. Je ne peux pas te donner la manière exacte et je n'ai pas le temps de chercher pour l'instant.

Question : Est-ce que ton système est bien une Slackware version 10.0?

Bref, commence par démarrer le rescue et ensuite reviens nous voir.

arghbis

badblocks est une commande pour vérifier le dd, voir s'il y a des blocs défectueux et éventuellement les "réparer", ou tout au moins, les marquer

mexx20

Citation :

Est-ce que tu as des données sensibles (document important) sur ce disque

Tout es relatif, à mon sens oui, j'aimerais bien tout récupérer.

Citation :

si tu fais un fdisk -l /dev/hdc, il te sort quoi?

Je posterai l'output plutard mais c'est quelque chose du style : découverte de deux partitions dont l'une labellée "Linux" et l'autre "Linux Swap" mais rien sur le système de fichier contenu.

Citation :

tu as essayé un badblocks sur le hdc?

Je ne comprend pas, c'est quoi ? Une commande ?

Citation :

Si t'as un rescue de Sues 9.2 sous la main, il me semble qu'il y a l'utilitaire guessfstype

Je ne le trouve pas dans ma distrib. Je vais essayer de l'installer et je posterai les résusltats.

Phoenix

Si t'as un rescue de Sues 9.2 sous la main, il me semble qu'il y a l'utilitaire guessfstype

FreTux:~ # /bin/guessfstype /dev/sda3
/dev/sda3 *appears* to be: reiserfs

arghbis

si tu fais un fdisk -l /dev/hdc, il te sort quoi?

et normalement, si tu lances fsck et qu'il reconnait un superblock compatible, il choisit tout seul le bon mode.

tu as essayé un badblocks sur le hdc?

rdc3	Non! À ce point, il ne reste qu'à tenter ta chance avec un marteau. Est-ce que tu as des données sensibles (document important) sur ce disque

mexx20

Rien a faire ... ?

mexx20

Bonjour,

Suite à un arrêt brutal de l'ordinateur, je me trouve dans l'impossibilité
de monter ma partition principale (root partition). Une série de "segmentation
fault" (je suspecte la RAM défectueuse) m'avaient forcé à presser le bouton
"power".

Un CD de démarrage (celui de ma distribution Slackware) ne semble rien
arranger. J'ai alors découvert qu'il existait des utilitaires pour <<réparer>>
les partitions. Mais ... ceux-ci s'utilisent à condition de savoir à quel type
de système de fichiers nous avons affaire. Malheureusement, il me semble que
dans ces conditions, je ne peux consulter le fichier "/etc/fstab" pour le
découvrir. Ma première question est la suivante : Comment déterminer le type
de système de fichiers pour une partition donnée ?

Sachant très certainement qu'il sagit ou du "ext3" ou du "reiserfs" (ce sont
les propositions de l'utilitaire d'installation de la distribution), j'ai
procédé au hasard en commençant par faire l'hypothèse qu'il s'agissait de
"reiserfs" et j'ai utilisé la commande "reiserfsck".

Pour commencer, j'ai écrit :

#reiserfsck --check /dev/hdc2

... qui m'a signalé qu'il ne trouvait pas de "superblock". Puis, comme indiqué,
je tente de le reconstruire avec :

#reiserfsck --rebuild-sb /dev/hdc2

Ensuite, je refait un test de consistance :

#reiserfsck --check /dev/hdc2
... qui m'annonce "Bad root block 0" et me propose le procéder ainsi :

#reiserfsck --rebuild-tree /dev/hdc2
... qui finalement finit par m'avouer "No reiserfs metadata found".

Etant <<bloqué>> avec "reiserfs" je me suis tourné vers "ext3" et ce fût très
bref car on m'indiquait clairement que le "superblock" était inexistant et
qu'il n'y avait rien à éspérer.

#e2fsck -b 8193 /dev/hdc2

Ne connaissant pas la taille des "blocks", j'ai essayé tous ces indices
(comprenez indice comme pour les vecteurs) :

8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409, 663553,
1024001, 1990657, 2809857, 5120001, 5971969, 17915905, 19668993

16384, 49152, 81920, 114688, 147456, 409600, 442368, 802816, 1327104,
2048000, 3981312, 5619712

32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000

Est-ce que nous pouvons conclure qu'il ne s'agit pas de "ext3" ?

Est-il possible qu'il s'agissait de "ext3" mais que "reiserfsck" a tout cassé ?
Selon moi, la commande à pu casser "un peu" au début mais sans abimer les
sauvegardes du "superblock" en bout de disque, ce qui me laisse un peu
perplexe.

Je précise que je n'ai pas utilisé de programme de partitionnement (à part lors
de l'installation de la distribution) et donc je ne pense pas que la table de
partitions soi altérée. Tant bien qu'elle le serait, que dois-je faire ?

Quelles sont mes chances pour récuperer mes données; auriez-vous des conseils
pouvant m'amener à explorer d'autres pistes ?

PS: Tous ces essais ont été effectué sur une autre machine (que l'on peut
considérer comme fiable) sur laquelle j'ai branché le disque dur contenant la
partition (référencée par /dev/hdc2)

Merci d'avance !