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 !

Rien a faire ... ?

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

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?

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

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

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.
 

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

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

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

 
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.

# 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
 

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

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.
 

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 !

 
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 ?
 

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.    
 
Je t'ai trouvé un nouveau pseudo mexx the hd destructor. C'est amical et pas méchant. Je comprends la tentation.
   
 
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.    Ç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  
 

 
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.
 

 
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.
 

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

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