[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fichiers impossibles à supprimer



quick'n dirty hack:
ajouter des "/sbin/rmmod <nom_du_driver>"
dans /etc/rc.local

Christophe Alonso a écrit :
Le samedi 13 octobre 2007 à 23:29 +0200, Gilles Mocellin a écrit :
Le Saturday 13 October 2007 18:51:09 Christophe Alonso, vous avez écrit :
Le samedi 13 octobre 2007 à 17:23 +0200, Gilles Mocellin a écrit :
Le Saturday 13 October 2007 17:15:03 Christophe Alonso, vous avez écrit :
Bonjour,

ce matin mise à jour du noyau 2.6.18-5-686. Sur un pc, sans problème.
Sur un autre, l'installation échoue parce qu'il n'arrive pas à lier
symboliquement /lib/modules/2.6.18-5-686/drivers/char/ipmi_watchdog.ko.
Je pense à un problème de disponibilité du dit fichier, je redémarre
sur un ancien noyau, et retente l'installation. Même erreur. De dépit,
je purge le noyau 2.6.18-5-686, j'essaie de supprimer le
répertoire /lib/modules/2.6.18-5-686/drivers/char/ à la main, mais je
ne peut que le déplacer. Même en root, il me dit que je ne suis pas
autorisé. En regardant de plus près, voici ce que je trouve :
permissions sur le fichier ipmi_watchdog.ko 000 ; user 1447362560 ;
group 1430407252. Les user et group en question ne semble pas exister
sur le pc, d'ailleurs, voilà bien d'étranges user et group, non ? Je
commence à m'inquiéter. Quelqu'un a-t-il déjà eu ce genre de problème ?
Comment se débarrasser définitivement de ce fichier ?

Pour la mise à jour, elle s'est effectuée correctement, après
déplacement du fichier récalcitrant.

Merci de votre aide.
A mon avis, une corruption du système de fichier.
Boot sur un liveCD, ou autre système n'utilisant pas le FS sur lequel il
y a /lib/modules/...

Puis fsck sur le FS, s'il ne trouve rien, c'est autre chose et je ne vois
pas quoi.
Merci pour ta réponse.

J'ai essayé en ssh depuis l'autre pc, mais je n'arrive à rien, il faut
dire que je ne connais pas grand chose à la ligne de commande et
qu'entre le man de ssh, celui de fsck, je ne m'en sors pas du tout.
Tant que le système tourne, tu ne pourras pas réparer le filesystem.
Il va vraiment falloir le rebooter.

Le problème c'est qu'avec gdm, la session graphique démarre toute seule.
Est-ce que le redémarrer en single-user mode peut convenir ?

En plus celui qui a installé linux sur le pc a utilisé lvm qui ne semble
pas être géré par fsck.
Si si, en fait disque ou LVM, ce qui compte c'est le système de fichier qui est mis dessus (ext3, reiserfs, fat...), c'est lui que saura gérer fsck.

Pourtant fdisk ne voit que hda1 (/boot), hda2 (partition étendue) et
hda5 (le lvm), mais pas les partitions qui sont sur le lvm.

Mais puisque c'est un fichier corrompu, je peux finalement le laisser où
il est. Au prochain fsck du système, ça devrait rentrer dans l'ordre
tout seul, non ?
A condition qu'un fsck soit lancé un jour...
Si personne ne le fait et que le PC est rarement rebooté...

Encore 5 reboot et c'est bon :-)

Par contre, pour mon instruction personnelle, comment des fichiers qui
semblent tout de même extrêmement sensibles (comme les pilotes du noyau
peuvent-ils se corrompre ? Mauvais usage du user ? Problème avec un
logiciel qui fait appel à ces pilotes ? J'ai trouvé de nombreux
problèmes avec "watchdog" en cherchant sur le net. Comme je n'en ai pas
d'utilité, comment éviter que ces pilotes ne se chargent ? Un
blacklisting ne semble pas fonctionner.

Merci.




--
Be warned that typing \fBkillall \fIname\fP may not have the desired
effect on non-Linux systems, especially when done by a privileged user.
(From the killall manual page)



Reply to: