Les miracles ça arrive !
Une énorme partition en ext3 de mon disque dur était devenue subitement
inaccessible. Même e2fsck n'y comprenait rien.
J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui
s'est vraiment passé.
Voici les symptômes (attention aux âmes sensibles !) :
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752486
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752544
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752546
[etc...]
Ensuite impossible d'accéder au disque dur.
Lorsque je lance un e2fsck j'obtiens :
e2fsck 1.27 (8-Mar-2002)
e2fsck: Attempt to read block from filesystem resulted in short read
while trying to open /dev/hdb5 Could this be a zero-length partition?
Si j'enlève /dev/hdb5 de /etc/fstab et que je lance
e2fsck, la vérification se lance et je tombe ensuite sur le même type
d'erreur :
Error reading block 6521299 (Attempt to read block from filesystem
resulted in short read) while doing inode scan.
/dev/hdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Bon bref, le disque semblait bel et bien mort.
Un bienveillant contributeur à ce forum m'a indiqué une procédure pour
tenter de récupérer les données : recopier à grand coup de 'dd' sur un
autre disque dur, jeter un oeil sur les données avec 'debugfs' et
ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
La copie avec dd a été très très longue, et quelques erreurs d'accès
aux données ont été détectées mais ignorées. J'ai donc lancé 'e2fsck'
sur ces données recopiées et à partir de là ce fut un peu le bordel :
des tonnes de réparations, de nettoyage d'inodes et compagnie à faire
manuellement. Puis j'ai jeté un oeil sur ces données 'réparées' avec
'debugfs' : c'était le grand souk ! enfin bon pas mal de données étaient
encore présentes, beaucoup de choses bizarres dans le 'lost+found' et
bien entendu beaucoup de données manquantes. J'ai alors tenté de monter
cette partition reconstituée et là même phénomène que sur l'ancien
disque dur : quand je fais 'ls' il me remplit l'écran de caractères
bizarres. C'était tout de même bizarre que 'debugfs' arrive à lire les
noms de fichiers/répertoires et qu'en montant la partition je n'y arrive
pas !
En désespoir de cause j'ai lancé 'debugfs' sur l'ancien disque dur, et
là surprise ! toutes mes données étaient accessibles !!! J'ai alors
découvert la commande 'rdump' et j'ai copié toutes les données sur
l'autre disque dur. Tout est bien qui finit bien, mais plusieurs
interrogations subsistent :
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il
pu lire et recopier les données alors que le montage était devenu
impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées
?
3) Pourquoi 'e2fsck' est-il si peu efficace et ne fait-il pas appel à
'debug2fs' pour pouvoir récupérer les données ?
4) Comment cela se fait-il au travers de mes pénibles recherches sur
Internet que presque personne ne parle de 'debugfs+rdump' dans le cas
d'un disque dur endommagé ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien
disque dur semble nickel. Que s'est-il passé ? était-ce un problème de
surchauffe de disque (il était un peu coincé entre un lecteur de
disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut
arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours
le sens...
J'espère que ce *long* message servira à d'autres linuxiens débutants
victimes d'un crash disque. En tout cas pour moi cela finit bien...
Merci et tous ceux qui pourront éclairer un peu ma lanterne !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pham
Oups je me suis trompé de forums ! désolé !
*********** REPLY SEPARATOR ***********
Bonjour,
Les miracles ça arrive ! Une énorme partition en ext3 de mon disque dur était devenue subitement inaccessible. Même e2fsck n'y comprenait rien. J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui s'est vraiment passé.
Voici les symptômes (attention aux âmes sensibles !) :
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752486 kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752544 kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752546
[etc...]
Ensuite impossible d'accéder au disque dur. Lorsque je lance un e2fsck j'obtiens :
e2fsck 1.27 (8-Mar-2002) e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hdb5 Could this be a zero-length partition?
Si j'enlève /dev/hdb5 de /etc/fstab et que je lance e2fsck, la vérification se lance et je tombe ensuite sur le même type d'erreur :
Error reading block 6521299 (Attempt to read block from filesystem resulted in short read) while doing inode scan. /dev/hdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
Bon bref, le disque semblait bel et bien mort. Un bienveillant contributeur à ce forum m'a indiqué une procédure pour tenter de récupérer les données : recopier à grand coup de 'dd' sur un autre disque dur, jeter un oeil sur les données avec 'debugfs' et ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
La copie avec dd a été très très longue, et quelques erreurs d'accès aux données ont été détectées mais ignorées. J'ai donc lancé 'e2fsck' sur ces données recopiées et à partir de là ce fut un peu le bordel : des tonnes de réparations, de nettoyage d'inodes et compagnie à faire manuellement. Puis j'ai jeté un oeil sur ces données 'réparées' avec 'debugfs' : c'était le grand souk ! enfin bon pas mal de données étaient encore présentes, beaucoup de choses bizarres dans le 'lost+found' et bien entendu beaucoup de données manquantes. J'ai alors tenté de monter cette partition reconstituée et là même phénomène que sur l'ancien disque dur : quand je fais 'ls' il me remplit l'écran de caractères bizarres. C'était tout de même bizarre que 'debugfs' arrive à lire les noms de fichiers/répertoires et qu'en montant la partition je n'y arrive pas ! En désespoir de cause j'ai lancé 'debugfs' sur l'ancien disque dur, et là surprise ! toutes mes données étaient accessibles !!! J'ai alors découvert la commande 'rdump' et j'ai copié toutes les données sur l'autre disque dur. Tout est bien qui finit bien, mais plusieurs interrogations subsistent :
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il pu lire et recopier les données alors que le montage était devenu impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées?
3) Pourquoi 'e2fsck' est-il si peu efficace et ne fait-il pas appel à 'debug2fs' pour pouvoir récupérer les données ?
4) Comment cela se fait-il au travers de mes pénibles recherches sur Internet que presque personne ne parle de 'debugfs+rdump' dans le cas d'un disque dur endommagé ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un problème de surchauffe de disque (il était un peu coincé entre un lecteur de disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la robustesse du système de fichier sur le disque ? je vois pleins d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours le sens...
J'espère que ce *long* message servira à d'autres linuxiens débutants victimes d'un crash disque. En tout cas pour moi cela finit bien...
Merci et tous ceux qui pourront éclairer un peu ma lanterne !
Oups je me suis trompé de forums ! désolé !
*********** REPLY SEPARATOR ***********
Bonjour,
Les miracles ça arrive !
Une énorme partition en ext3 de mon disque dur était devenue
subitement inaccessible. Même e2fsck n'y comprenait rien.
J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui
s'est vraiment passé.
Voici les symptômes (attention aux âmes sensibles !) :
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752486
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752544
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752546
[etc...]
Ensuite impossible d'accéder au disque dur.
Lorsque je lance un e2fsck j'obtiens :
e2fsck 1.27 (8-Mar-2002)
e2fsck: Attempt to read block from filesystem resulted in short read
while trying to open /dev/hdb5 Could this be a zero-length partition?
Si j'enlève /dev/hdb5 de /etc/fstab et que je lance
e2fsck, la vérification se lance et je tombe ensuite sur le même type
d'erreur :
Error reading block 6521299 (Attempt to read block from filesystem
resulted in short read) while doing inode scan.
/dev/hdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Bon bref, le disque semblait bel et bien mort.
Un bienveillant contributeur à ce forum m'a indiqué une procédure pour
tenter de récupérer les données : recopier à grand coup de 'dd' sur un
autre disque dur, jeter un oeil sur les données avec 'debugfs' et
ensuite réparer les données sur le nouveau disque à l'aide de
'e2fsck'.
La copie avec dd a été très très longue, et quelques erreurs d'accès
aux données ont été détectées mais ignorées. J'ai donc lancé 'e2fsck'
sur ces données recopiées et à partir de là ce fut un peu le bordel :
des tonnes de réparations, de nettoyage d'inodes et compagnie à faire
manuellement. Puis j'ai jeté un oeil sur ces données 'réparées' avec
'debugfs' : c'était le grand souk ! enfin bon pas mal de données
étaient encore présentes, beaucoup de choses bizarres dans le
'lost+found' et bien entendu beaucoup de données manquantes. J'ai
alors tenté de monter cette partition reconstituée et là même
phénomène que sur l'ancien disque dur : quand je fais 'ls' il me
remplit l'écran de caractères bizarres. C'était tout de même bizarre
que 'debugfs' arrive à lire les noms de fichiers/répertoires et qu'en
montant la partition je n'y arrive pas !
En désespoir de cause j'ai lancé 'debugfs' sur l'ancien disque dur, et
là surprise ! toutes mes données étaient accessibles !!! J'ai alors
découvert la commande 'rdump' et j'ai copié toutes les données sur
l'autre disque dur. Tout est bien qui finit bien, mais plusieurs
interrogations subsistent :
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment
a-t-il pu lire et recopier les données alors que le montage était
devenu impossible et que même e2fsck ne comprenait rien à ma partition
?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors
qu'en recopiant comme un bourrin avec 'dd' j'ai des données
endommagées?
3) Pourquoi 'e2fsck' est-il si peu efficace et ne fait-il pas appel à
'debug2fs' pour pouvoir récupérer les données ?
4) Comment cela se fait-il au travers de mes pénibles recherches sur
Internet que presque personne ne parle de 'debugfs+rdump' dans le cas
d'un disque dur endommagé ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck',
l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un
problème de surchauffe de disque (il était un peu coincé entre un
lecteur de disquette et un lecteur DVD) ? ou bien ce genre de
plaisanterie peut arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la
robustesse du système de fichier sur le disque ? je vois pleins
d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours
le sens...
J'espère que ce *long* message servira à d'autres linuxiens débutants
victimes d'un crash disque. En tout cas pour moi cela finit bien...
Merci et tous ceux qui pourront éclairer un peu ma lanterne !
Les miracles ça arrive ! Une énorme partition en ext3 de mon disque dur était devenue subitement inaccessible. Même e2fsck n'y comprenait rien. J'ai réussi à tout récupérer mais je n'ai pas très bien compris ce qui s'est vraiment passé.
Voici les symptômes (attention aux âmes sensibles !) :
kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752486 kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752544 kernel: end_request: I/O error, dev 03:45 (hdb), sector 37752546
[etc...]
Ensuite impossible d'accéder au disque dur. Lorsque je lance un e2fsck j'obtiens :
e2fsck 1.27 (8-Mar-2002) e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hdb5 Could this be a zero-length partition?
Si j'enlève /dev/hdb5 de /etc/fstab et que je lance e2fsck, la vérification se lance et je tombe ensuite sur le même type d'erreur :
Error reading block 6521299 (Attempt to read block from filesystem resulted in short read) while doing inode scan. /dev/hdb5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options)
Bon bref, le disque semblait bel et bien mort. Un bienveillant contributeur à ce forum m'a indiqué une procédure pour tenter de récupérer les données : recopier à grand coup de 'dd' sur un autre disque dur, jeter un oeil sur les données avec 'debugfs' et ensuite réparer les données sur le nouveau disque à l'aide de 'e2fsck'.
La copie avec dd a été très très longue, et quelques erreurs d'accès aux données ont été détectées mais ignorées. J'ai donc lancé 'e2fsck' sur ces données recopiées et à partir de là ce fut un peu le bordel : des tonnes de réparations, de nettoyage d'inodes et compagnie à faire manuellement. Puis j'ai jeté un oeil sur ces données 'réparées' avec 'debugfs' : c'était le grand souk ! enfin bon pas mal de données étaient encore présentes, beaucoup de choses bizarres dans le 'lost+found' et bien entendu beaucoup de données manquantes. J'ai alors tenté de monter cette partition reconstituée et là même phénomène que sur l'ancien disque dur : quand je fais 'ls' il me remplit l'écran de caractères bizarres. C'était tout de même bizarre que 'debugfs' arrive à lire les noms de fichiers/répertoires et qu'en montant la partition je n'y arrive pas ! En désespoir de cause j'ai lancé 'debugfs' sur l'ancien disque dur, et là surprise ! toutes mes données étaient accessibles !!! J'ai alors découvert la commande 'rdump' et j'ai copié toutes les données sur l'autre disque dur. Tout est bien qui finit bien, mais plusieurs interrogations subsistent :
1) Comment fonctionne ce truc magique qu'est 'debugfs' ? comment a-t-il pu lire et recopier les données alors que le montage était devenu impossible et que même e2fsck ne comprenait rien à ma partition ?
2) Pourquoi ai-je réussi à copier les données avec 'debugfs' alors qu'en recopiant comme un bourrin avec 'dd' j'ai des données endommagées?
3) Pourquoi 'e2fsck' est-il si peu efficace et ne fait-il pas appel à 'debug2fs' pour pouvoir récupérer les données ?
4) Comment cela se fait-il au travers de mes pénibles recherches sur Internet que presque personne ne parle de 'debugfs+rdump' dans le cas d'un disque dur endommagé ?
5) Après reformatage et test avec avec 'badblocks' et 'e2fsck', l'ancien disque dur semble nickel. Que s'est-il passé ? était-ce un problème de surchauffe de disque (il était un peu coincé entre un lecteur de disquette et un lecteur DVD) ? ou bien ce genre de plaisanterie peut arriver aléatoirement ?
6) Est-ce que l'on peut activer des options pour améliorer la robustesse du système de fichier sur le disque ? je vois pleins d'options dans le BIOS ou dans 'hdparm' dont je ne saisis pas toujours le sens...
J'espère que ce *long* message servira à d'autres linuxiens débutants victimes d'un crash disque. En tout cas pour moi cela finit bien...
Merci et tous ceux qui pourront éclairer un peu ma lanterne !
