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
Michel Tatoute
Bonjour,
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans /usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier .../lock, remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire au disque aussi. Dans le cas ou le fs doit rester monté (à déconseiller), commencer par renommer /usr/local/var/locks en /usr/local/var/locks_old et recreer un beau repertoire tout neuf avec debugfs ).
Michel.
Bonjour,
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas
d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans
/usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de
même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier .../lock,
remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le
repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou
encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des
pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à
pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans
oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire
au disque aussi. Dans le cas ou le fs doit rester monté (à
déconseiller), commencer par renommer /usr/local/var/locks en
/usr/local/var/locks_old et recreer un beau repertoire tout neuf avec
debugfs ).
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans /usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier .../lock, remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire au disque aussi. Dans le cas ou le fs doit rester monté (à déconseiller), commencer par renommer /usr/local/var/locks en /usr/local/var/locks_old et recreer un beau repertoire tout neuf avec debugfs ).
Michel.
nwjb
Le Mon, 06 Sep 2004 13:57:22 +0200, Michel Tatoute a écrit:
Bonjour,
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans /usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier .../lock, remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire au disque aussi. Dans le cas ou le fs doit rester monté (à déconseiller), commencer par renommer /usr/local/var/locks en /usr/local/var/locks_old et recreer un beau repertoire tout neuf avec debugfs ).
Michel. C'est ce que nous avons fait ... et tout semble OK
Merci beaucoup
J.Bratières
Le Mon, 06 Sep 2004 13:57:22 +0200, Michel Tatoute <tatoute@alussinan.org>
a écrit:
Bonjour,
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas
d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans
/usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de
même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier
.../lock,
remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le
repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou
encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des
pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à
pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans
oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire
au disque aussi. Dans le cas ou le fs doit rester monté (à
déconseiller), commencer par renommer /usr/local/var/locks en
/usr/local/var/locks_old et recreer un beau repertoire tout neuf avec
debugfs ).
Michel.
C'est ce que nous avons fait ... et tout semble OK
Le Mon, 06 Sep 2004 13:57:22 +0200, Michel Tatoute a écrit:
Bonjour,
Un serveur IBM est tombé en panne chez un de nos clients. N'ayant pas d'affichage sur la console , celui-ci a rebooté plusieurs fois.
Le serveur a été réparé (carte ùère).
Maintenant au fsck il y a des erreurs caractères illégaux dans /usr/local/var/locks.
Dans ce répertoire il y a PLUSIEURS fichiers browse.dat (strictement de même nom dixit le client)
Nous pensons : remonter le disque en rw , détruire toutle dossier .../lock, remonter le disque en ro et faire fsck -f...
je vous le déconseille. Il est tres possible que supprimer le repertoire via le montage du fs empire les problemes.
Pourquoi ne pas tenter un fsck à la main, beaucoup moins risqué? Ou encore avec debugfs.
Pour ma part je poasserais fsck à la main, une fois, puis s'il reste des pb, j'utiliserais debugfs (et pas un mount) pour supprimer les fichiers à pb dans /usr/local/var/locks. puis un dernier fsck en automatique (sans oublier un badblocks, on ne sais jamais: un reboot sauvage ca peut nuire au disque aussi. Dans le cas ou le fs doit rester monté (à déconseiller), commencer par renommer /usr/local/var/locks en /usr/local/var/locks_old et recreer un beau repertoire tout neuf avec debugfs ).
Michel. C'est ce que nous avons fait ... et tout semble OK
