Mon système RedHat 7.2 s'est planté hier sur mon vieux Thinkpad 600. Ce
PC et le système tournent plusieurs heures par jour depuis plus de cinq
ans, sans pratiquement jamais aucun problème. Ah si, au fait, j'avais un
problème auquel je n'avais guère prêté attention jusqu'ici, et c'est
vraisemblablement responsable du crash. Il s'agit d'une clef USB. Sous
Linux, je n'ai jamais eu besoin d'aucun driver. Je 'montais' la clef par :
#mount /dev/sda1 /mnt/key
et çà fonctionnait. Une bizarrerie cependant, au 'démontage', laquelle
bizarrerie ne se produisait que sur mon Thinkpad, pas sur un autre PC
tournant également sous RH7.2. Lorsque je tapais :
#umount /mnt/key
la clef paraissait se démonter normalement, à ceci près que, si je
faisais un shutdown de la machine, celle ci restait systématiquement en
suspens 5 à 6 minutes sur : "unmounting filesystems...", le shutdown
poursuivait ensuite jusqu'à l'arrêt après cette période d'attente.
Or donc, hier soir, j'ai monté ma clef pour copier des fichiers à
destination d'un autre PC. Et le système a "givré" "bloqué" en cours de
manip, je ne sais plus si c'était en cours de copie, au fait non,
c'était avant, ah oui, c'était lors d'un ls -l /mnt/key. Plus aucune
possibilité d'intervention, souris ou clavier, un CTRL-ALT-BACKUP ne m'a
pas permis de sortir d' X, et un CTRL-ALT-DEL s'est avêré sans
résultat. J'ai donc été forcé de faire un arrêt brutal par
débranchement et retrait de la batterie. Au redémarrage, çà n'a rien
voulu savoir. La partition MSWIN se boote normalement lorsque j'opte pour
ce système, mais rien à faire pour Linux. Voici un résumé des messages
qui apparaissent lors de la tentative de boot :
Plusieurs essais successifs m'ont donné le même résultat.
J'ai alors tenté de faire usage d'un rescue disk qui m'a été prêté
par un collègue il y a plusieurs mois. C'est basé sur Gentoo ; çà
s'appelle System Rescue CD. Cà m'a permis de booter mon système, et de
monter mes disques durs hda3 et hda5 sans problème, et même, de monter
ma clef usb pour aller copier les fichiers que je souhaitais récupérer
au départ.
Par contre, pour réparer mon système, je ne sais pas quoi faire. J'ai
cependant noté quelque chose de vraiment bizarre. Après un shutdown du
système booté avec le disk de SystemRescueCD, j'ai tenté de redémarrer
mon système par les voies normales... et çà a fonctionné au poil...
mais seulement une seule fois ! Au second re-boot: mêmes erreurs que
citées plus haut. Trois ou quatre tentatives : même résultat. A la
cinquième tentative, j'ai opéré exactement comme j'avais fait la fois
où çà avait redémarré normalement, à savoir, le CD de System Rescue
CD dans le lecteur, j'appuie sur le bouton d'éjection durant le reboot,
le CD s'éjecte bien avant le démarrage de Linux... et mon système a
redémarré normalement (ou presque) une fois de plus !
Maintenant, je n'ose plus faire de shutdown. Il est bien vrai que, de
toutes façons, je faisais rarement d'arrêts complets sur ce PC, me
contentant le plus souvent de sortir d'XWindow puis de fermer le
couvercle. A la réouverture du couvercle, je me retrouvais sous la
console et il me restait à taper "startx". Cà a fonctionné comme cela
pendant 5-6 ans, avec sans doute moins de 30 shutdown complets durant tout
ce temps. Mais bon, là çà a l'air de déconner, et donc je voudrais
bien retrouver un système opérationnel sans risque de plantage. Au fait,
étant sous SystemRescueCD, j'en ai profité pour faire un fsck de ma
partition Linux : fsck /dev/hda5 (la partition n'étant alors évidemment
pas montée !). Le fsck s'est bien déroulé sans erreur affichée.
Ensuite, lorsque, la première fois, mon système a redémarré tout seul,
j'ai également opté pour un filesystem integrity check lors du boot.
Là, çà m'avait trouvé une inode qui n'avait pas le bon numéro, et la
correction avait été faite.
Inode 249076, i_blocks is 88, should bd 24 FIXED
Mais, au final, çà n'a pas résolu mon
problème de refus de boot sauf si...
Merci d'avance pour toute info pouvant contribuer à la résolution du
problème. Actuellement, mon Thinkpad est booté, je puis donc essayer
quelque chose. Et je dispose également toujours du CD de SystemRescueCD
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages,
et n'ai rien trouvé qui ait pu attirer mon attention.
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
Emmanuel Florac
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages, et n'ai rien trouvé qui ait pu attirer mon attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2 gèrent plus qu'approximativement les périphériques USB. Utiliser une distribution plus actuelle serait bien préférable de ce point de vue là.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages,
et n'ai rien trouvé qui ait pu attirer mon attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui
est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2
gèrent plus qu'approximativement les périphériques USB. Utiliser une
distribution plus actuelle serait bien préférable de ce point de vue là.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages, et n'ai rien trouvé qui ait pu attirer mon attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2 gèrent plus qu'approximativement les périphériques USB. Utiliser une distribution plus actuelle serait bien préférable de ce point de vue là.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Bernard
Le Sat, 27 Jan 2007 23:15:33 +0100, Emmanuel Florac a écrit :
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages, et n'ai rien trouvé qui ait pu attirer mon attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2 gèrent plus qu'approximativement les périphériques USB. Utiliser une distribution plus actuelle serait bien préférable de ce point de vue là.
Un défaut de Lilo ? Comment cela serait il possible alors que mon Lilo n'a pas posé problème depuis au moins 5 ans ? Je pourrais, tout de même, relancer lilo pour voir si çà fait une différence, mais, avant d'en savoir davantage je m'abstiens de faire un shutdown de la machine.
Quant à une mauvaise gestion des ports USB par 2.4, je le crois volontiers. La même clef USB ne pose aucun problème sur le système d'où provient mon message (Debian Sarge avec kernel 2.6.12.6), et d'ailleurs, aucun problème non plus avec un autre PC sous RH 7.2, mais avec le noyau 2.4.21 (2.4.7-10 sur le Thinnkpad dont il est question)
Le Sat, 27 Jan 2007 23:15:33 +0100, Emmanuel Florac a écrit :
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de
/var/log/messages, et n'ai rien trouvé qui ait pu attirer mon
attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui
est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2
gèrent plus qu'approximativement les périphériques USB. Utiliser une
distribution plus actuelle serait bien préférable de ce point de vue
là.
Un défaut de Lilo ? Comment cela serait il possible alors que mon Lilo
n'a pas posé problème depuis au moins 5 ans ? Je pourrais, tout de
même, relancer lilo pour voir si çà fait une différence, mais, avant
d'en savoir davantage je m'abstiens de faire un shutdown de la machine.
Quant à une mauvaise gestion des ports USB par 2.4, je le crois
volontiers. La même clef USB ne pose aucun problème sur le système
d'où provient mon message (Debian Sarge avec kernel 2.6.12.6), et
d'ailleurs, aucun problème non plus avec un autre PC sous RH 7.2, mais
avec le noyau 2.4.21 (2.4.7-10 sur le Thinnkpad dont il est question)
Le Sat, 27 Jan 2007 23:15:33 +0100, Emmanuel Florac a écrit :
Le Sat, 27 Jan 2007 22:24:51 +0100, Bernard a écrit :
J'ai jeté un oeil de non spécialiste aux messages de /var/log/messages, et n'ai rien trouvé qui ait pu attirer mon attention.
Peut-être un défaut de LILO, ou autre chose... Dificile à dire. Ce qui est sûr c'est que les très vieux noyaux 2.4 utilisés par la RH7.2 gèrent plus qu'approximativement les périphériques USB. Utiliser une distribution plus actuelle serait bien préférable de ce point de vue là.
Un défaut de Lilo ? Comment cela serait il possible alors que mon Lilo n'a pas posé problème depuis au moins 5 ans ? Je pourrais, tout de même, relancer lilo pour voir si çà fait une différence, mais, avant d'en savoir davantage je m'abstiens de faire un shutdown de la machine.
Quant à une mauvaise gestion des ports USB par 2.4, je le crois volontiers. La même clef USB ne pose aucun problème sur le système d'où provient mon message (Debian Sarge avec kernel 2.6.12.6), et d'ailleurs, aucun problème non plus avec un autre PC sous RH 7.2, mais avec le noyau 2.4.21 (2.4.7-10 sur le Thinnkpad dont il est question)
