Salut,
Dinh-Tuan.Pham@??? wrote:
> La machine est dejà un peu instable (parfois des plantages
>inexpliquables) et j'ai constaté qu'il m'est pratiquement impossible
>de copier un gros fichier (en fait une image CD iso) sans erreur: les
>md5sum ne concordent pas. Je supconne donc le probleme vient du dique
>dur (SCSI). J'ai appelé le service après vente: il ont fait des tests et
>ont constaté des problèmes de disque et ont mis un nouveau disque.
>Mais alors un problème mysterieur apparait:
> J'ai reinstallé le systeme (debian). Tout marche bien jusque
>moment ou j'ai rebooté et voulu ajouter quelques paquets. Alors dpkg
>me sort a tout les coup "segmenatation fault".
>
Regarde dans /var/log/messages (dans les sections couvertes par le noyau
SMP). Tu devrais y trouver des messages "Ooops" avec un decodage
hexadecimal (ou symbolique) du bug dans le noyau.
Si le message est symbolique, poste le ici (un peu d'education pour tout
le monde...), sinon envoie moi (en prive) ce message accompagne du
resultat cd la commande "cat /proc/ksyms".
>Apres bien d'essais, je
>realise que j'ai installé un noyau smp (car c'est une machine bi-proc)
>et que ce phenomene aparait quand je boote sur ce noyau mais si je
>boote sur le noyau du CD d'installation, qui n'est pas spm, alors ca
>marche sans problème.
>
Bug classique de verouillage SMP dans un driver. Ou le driver lui meme
est bugge, ou il n'est pas compile pour ton noyau.
1. verifie qu'aucun module kernel n'est situe dans /lib/modules/misc.
Tous les modules doivent imperativement etre situes dans
/lib/modules/<version(smp)?>/ sous peine d'ennuis graves au
changement de noyau.
2. tourne "depmod -aue" histoire de reperer que les dependances
binaires des modules sont bien satisfaites
>Autre chose, apres le coup "segmenatation fault"
>cerain fichiers du repertoire /var/lib/dpkg peuvent être corrompus.
>
Lors d'un bug kernel, absolument tout peut etre corrompu. A chaque fois
qu'on s'en sort, c'est un peu grace a la chance... :-)
Pour info, la procedure de "Ooops" du noyau correspond a un "Kernel
Panic" sur n'importe quel autre OS. Linux tente de laisser la main a
l'utilisateur pour qu'il puisse sortir proprement. Mais le system qui a
"Ooops"e ne tient en general pas tres longtemps.
Mon conseil quand cela t'arrive, si tu commences a constater des
corruptions:
1. Surtout pas de reboot propre (les corrputions ont le plus souvent
lieu au demontage des file-systems)
2. Alt-SysRq+u (re-montage des FS en read-only, elimine les
corruptions a venir, seuls les fichiers ouverts sont encore en danger)
3. AltSysRq+b (reboot immediat)
>Un autre coup de dpkg indique, par exemple, erreur systaxe de
>/var/lib/dpkg/status, et la lecture de ce fichier a montré que certain
>caracteres de celui-ci ont ete remplacés par des carateres non
>imprimables. Mais cette corruption peut etre, _mais pas toujours_, que
>virtuel: un reboot avec le noyau monoprocesseur remet tout dans
>l'ordre.
>
Je precise que la piste "memtest86" est aussi particulierement
interressante, mais n'est plausible que dans la mesure ou tu as rajoute
/ change de la RAM.
A+
--
Francois-Xavier 'FiX' KOWALSKI
