Suite à un phénomène inexpliqué (orage ?), je ne peux plus booter sur ma partition /. Je tombe sur cette erreur au démarrage :
 
 
 
EXT3-fs: ide0(3,5): couldn't mount because of unsupported optional features (800080000)
EXT3-fs: ide0(3,5): couldn't mount because of unsupported optional features (800080004)
 
 
 
Pis voilà, il s'arrête là, avec un beau kernel panic...
 
J'ai essayé de scanner la partition avec e2fsck (ça marche avec l'ext3 ?? il faut utiliser e3fsck (si ça existe) ? ). voici le résultat :
 
 
 
Filesystem revision too high while trying to open /dev/hda5
The file system revision is apparently too high for this version of e2fsck. (Or the filesystem superblock is corrupt)
 
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is validand is really containing an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try rinning e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
 
 
 
C'est réparable ? Je comprends pas cette histoire de filesystem trop récent. J'ai utilisé la version 1.34 de e2fsck (e2fsck-static 1.34+1.35-WIP-2003.08.01-1 pour ceux qui veulent le détail, debian unstable). C'est bien la version la plus récente, non ?
 
Le disque n'a pas l'air d'avoir de pb physique, les autres partoches tournent nickel.
 
J'ai essayé de lire la partition avec explore2fs, et il me sort ça :
 
Error: Access violation at address 0040F625 in module "explore2fs.exe". Read of address 00000008
 
bien sûr, y'a plein de données importantes sur la partoche...
qqn a une idée ? c'est réparable ?

il semble en effet que ton fsck soit trop vieux.
si tu n'as pas de fsck.ext3, essaies avec une knoppix ou un autre truc de secours

 
OK je vais essayer ça (dès que je retrouve mon cd de knoppix), mais d'après http://e2fsprogs.sourceforge.net/, la version 1.34 est la plus récente :-/

arf
 
[jorge@blackknight] (~)> ll /sbin/fsck.ext3  
-rwxr-xr-x    3 root     root       122060 2003-08-03 00:34 /sbin/fsck.ext3*
 
[jorge@blackknight] (~)> ll /sbin/fsck.ext2  
-rwxr-xr-x    3 root     root       122060 2003-08-03 00:34 /sbin/fsck.ext2*
 
ça a l'air d'être le même binaire et j'ai bien la 1.34

tu as essayé ce qu'il suggère au sujet du superblock détruit ?

oui, je viens d'essayer avec le fsck.ext3 d'une knoppix, et c'est pareil (version 1.30).
 
comment je peux avoir une partition trop récente pour la dernière version ? En plus, elle est vieille cette partition...

 
oui, il me dit que le block 8193 n'est pas un superblock valide et donc qu'il ne peut rien en faire

ouais, en même temps il me dit la même chose sur une partition en parfait état  
 
joker

à mon avis ce numéro est donné comme exemple. Mais j'ai aucune idée de l'emplacement de mes superblocks...

tu as vu ? (extrait de man fsck.ext3)

Par défaut ma Sid créé des Block size=4096 (=4k)
 
pas aussi simple

Y'a du nouveau !
 
Apparemment, il a trouvé un super-block de rechange, le 32768.
 
Après, il me sort ça :
 
/dev/hda5: Argument invalide while reading block -2147450370
/dev/hda5: Argument invalide while reading journal superblock
/dev/hda5: Argument invalide while cheching ext3 journal for /dev/hda5
 
 
Je peux pas le forcer à faire un scan comme si c'était en ext2, en ignorant le journal ? C'est juste pour récupérer les données, c'est pas un pb de torpiller la journalisation.
J'ai essayé fsck.ext2, j'obtiens le même message.

autre chose qui pourrait être utile : la partition a été créée en ext3. Il n'y a pas eu de conversion ext2 > ext3 (donc pas de fichier /.journal)

J'ai trouvé : c'est la commande "tune2fs -O ^has_journal /dev/hda5"
 
Le problème c'est que tune2fs se plaint que le superblock est invalide. Comment lui dire d'aller chercher le 32768 (comme fsck) ?

Si je me souviens en pareil cas, il faut effacer le journal ext3 pour passer la partition en ext2, puis exécuter e2fsck.
 
http://www.troubleshooters.com/lin [...] _three2two
 
Puis repasser la partition en ext3.

 
euh, comment je peux faire pour l'enlever ce journal ?

Euh, écoute je dis peut-être des c..neries s'agissant de ton cas particulier.
Mais je m'en suis déjà sorti comme ça. J'avais repassé la partition en ext2 et alors e2fsk avait bien fonctionné.
 
Il semble en effet, qu'au moins deux de tes trois erreurs soient liées à la journalisation.
 
J'essaie de voir ce que je trouve.

Je pense que tu as raison, mais j'ai l'impression d'être dans un cercle vicieux :
 
e2fsck dit que le superblock normal est invalide. Je lui en donne un autre de secours, et là il me dit que le journal à un pb.
 
Je lance tune2fs pour virer le journal (commande "tune2fs -O ^has_journal /dev/hda5" ), et là il me dit que le superblock est invalide. Comment je peux dire à tune2fs d'utiliser le superblock de secours ?

Aïe. Le serpent qui se mord la queue.
 
As-tu vu cela :
http://www-math.cudenver.edu/~jman [...] rblock.pdf
ou encore :
http://www.commedia.it/ccontavalli/e2sbf/doc/e2sbf.pdf

 
Y'a bien qqch à faire non ?
On ne peut pas demander à e2fsck de simplement réparer le superblock à partir de celui de secours sans s'occuper du journal ?

Qu'est-ce que donne, avec les multiples de 8192+1 :
e2fsck -b (8192xn)+1 <device> comme indiqué sur le lien plus haut.
 
Macolu : traducteur KDE ?
J'aimerais pouvoir t'aider.

As-tu sur un autre support une copie de la table de partition ?

 
Le seul nombre qui marche, c'est 32768, et ça donne le résultat ci-dessus...
 
J'ai donc essayé un mke2fs -S /dev/hda5 comme indiqué sur ton PDF, c'était pe une connerie mais bon. Maintenant, e2fsck se lance, mais trouve des millions d'erreurs (l'option "p" ne veut pas marcher, j'ai donc adopté la technique du poids sur la touche entrée). Au bout d'un moment, je vois la liste des fichiers de la partition qui défile, avec une erreur et le message "Clear ?" :-(
 
J'en suis là, j'ose pas répondre yes à ces questions
 
Et oui, je suis tracteur KDE :-)

 
Pas besoin d'autre support : excepté cette partoche ext3, le reste du DD est intact. C'est pour ça que je ne comprends pas ce qu'il s'est passé.
Ah non le mbr aussi a été touché. Mais c'est plus facile à réparer.
Le mbr est au début du disque et la partoche ext3 à la fin... C'est vraiment étrange que ça soit ces deux trucs qui aient pris.

 
En effet.
Non de bleu, il doit bien y avoir un moyen de te tirer de là.
Je continue de voir ce que je trouve.

 
OK, merci bien :-)

pour commencer, si tu peux, il faudrait faire une copie brute de ta partition dans un fichier (avec dd) comme ça, si tu détruis tout; tu pourras toujours récupérer des trucs et/ou travailler dessus en montant en loopback (peut-être en forçant -t ext2 dans tes options de montage)
 
un truc qui marche parfois, c'est supprimer la partition et d'en recréer une par dessus avec exactement les même caractéristiques. J'avais vu je sais plus où quelqu'un réussir à récupérer ses données comme ça.
 
sinon, ya toujours les softs de récupération de données comme easy recovery sous win, faut voir si ça marche pour de l'ext2/ext3
 
bonne chance
 
En libre y a peut-être ça :
http://cvs.glandium.org/cvs.php?rt=ext3rminator
 
Et en proprio :
http://www.runpage-stellar.com/fr/ [...] mesfr.html

Prêt à contribuer pour partie pour l'achat du soft proprio.
Car KDE, je l'utilise tous les jours, gratuitement, et me félicite de la traduction française.

Bon, j'ai fini par répondre yes à ces questions (cf plus haut). Je me suis retrouvé avec une partition montable, mais ne contenant qu'un lost+found. Tous les fichiers ont l'air d'y être, mais les noms sont parfois perdus (remplacés par le n° de l'inode, genre #434578).
Il y a des gros bouts intacts, comme quasiment tout /usr.
Mais plutôt que de recoller les morceaux, j'ai préféré réinstaller une debian, et je repiocherai mes données persos dans le lost+found).
Du coup j'ai rien perdu (sauf du temps que j'aurai pu passer à traduire, grrr).
 
Merci pour votre aide (c'est pas la peine d'acheter un soft :-)
Et faites des backups !!!

Histoire d'avoir les idées claires, ça serait cool de simuler à nouveau la même panne, pour savoir ce qu'il est possible de faire pour réparer sur place, sans sortir l'artillerie lourde (ré-install...).
 
Ce qui me surprend, c'est que j'avais lu que certaines informations, comme le superblock, existent en plusieurs endroits stratégiques du disque et qu'en cas de destruction de l'une d'elles il serait possible de reconstruire celle détruite à partir des autres. Un peu à la manière de certains mirroirs RAID.
 
Comme c'est une "fonction" même du système de fichiers ext2/3, il doit exister un outil integré pour corriger tout ça.

 
J'ai réussi à recréer le superblock à partir de ceux de secours, pas de problème ça marche. Mais ma partition était aussi amochée ailleurs (au milieu des données).

Macolu, tu pourrais faire une petite description des commandes que tu as lancées ? Parce que ce matin j'ai eu exactement le même problème, udok aussi, et le truc inquiétant c'est qu'on est tous en Debian Sid ...
 
Pour mon cas, j'ai vu qu'apt n'arrivait pas à mettre à jour des paquets xfree, et j'ai vu une erreur reiser, donc je me suis mis en mode rescue et j'ai lancé mes fsck sur mes deux partitions reiser. Avant de rebooter, je me suis dit ca fait longtemps que je n'ai pas fsck ma racine (la bonne idée ) qui est en ext3, je la remonte donc en ro et je lance le fsck ... et là merdouille. Mais grave. Plus moyen d'accéder aux fichiers, ma console polluée, à chaque fois que je tape un caractère j'ai un message de e2fsck, plus accès à aucun fichier du /, le truc immonde. Je reboot, ca merde pareil. Et comme j'avais activé les HTrees, les fsck de version <1.25 sont inefficace ... c'est bien ma veine.
 
Donc si tu pouvais juste faire un petit listing ce serait sympa

C'est pas exactement le même problème. Pour moi, c'était une sous tension qui a fait dérailler mon disque dur. Pas physiquement, mais il s'est mis à écrire n'importe quoi au niveau du mbr et dans 2-3 endroits sur ma partition / (ext3).
 
Du coup, après réparation du superblock, j'ai lancé un fsck qui a mis toutes les données dans le lost+found, et je n'avais que ce dossier sur la partoche. Pour certains fichiers/dossiers, le nom et l'arborescence étaient conservés. J'ai par exemple retrouvé /etc et /var en un seul morceau (avec les noms de fichiers et les sous-dossiers), mais /usr était en mille morceaux (avec des tas de fichiers du style "#42145" ).