ifconfig ? Le code du noyau a été modifié pour permettre le chargement
des familles de protocoles réseau (comme IPX, AX25 et AppelTalk)
comme modules vers la version 1.3.80. Cela a eu pour effet
d'ajouter une nouvelle requête pour kerneld,
net-pf-X, où X est un nombre identifiant le
protocole (voir le fichier
/usr/src/linux/include/linux/socket.h pour la
signification de ces nombres).
Malheureusement, ifconfig envoie ces messages, donc
un bon nombre de personnes recoivent ces messages lors le
système se lance et qu'il exécute ifconfig pour
initialiser le périphérique loopback. Ces messages sont
sans danger et vous pouvez les retirer en ajoutant les lignes
suivantes :
alias net-pf-3 off # oubliez AX.25
alias net-pf-4 off # oubliez IPX
aliad net-pf-5 off # oubliez AppleTalk
au fichier /etc/conf.modules. Biensûr, si vous utilisez
IPX comme module, n'ajoutez pas la ligne qui retire IPX.
kerneld, mon système ralentit
quand j'active ma connexion PPP Il y a bon nombre de messages à ce sujet. Il semble qu'il y ait
une malheureuse interaction entre kerneld et le script
tkPPP qui est utilisé sur certains systèmes pour
configurer et surveiller la connexion PPP. Le script exécute
apparemment des boucles quand il lance ifconfig.
Celui-ci déclenche kerneld pour rechercher les modules
net-pf-X (voir ci-dessous), ce qui provoque une
surcharge du système et l'envoi possible de messages ``Cannot
locate module for net-pf-X''. Il n'y a pas d'autres
solutions que de ne pas utiliser tkPPP ou de changer sa
façon de surveiller la connexion.
kerneldne charge pas mon gestionnaire SCSI
Ajoutez une entrée pour la carte SCSI au fichier
/etc/conf.modules. Regardez la description de l'entrée
scsi_hostadapter plus haut.
modprobe se plaint que gcc2_compiled
n'est pas défini Ceci est une erreur dans module-utilities qui ne se
voit qu'avec binutils 2.6.0.9 ou supérieur et elle est
aussi documentée dans les notes de mises à jour du paquetage
binutils. Lisez-le donc ou mettez à jour le paquetage
des modules par un qui corrige ce problème, par exemple le
modules-2.0.0.
Les options de configuration d'un modules sont stockées dans
le module lui-même quand il est chargé. Donc, quand
kerneld décharge un module, la configuration que vous
aviez faite est perdue et la prochaine fois que le module sera
chargé, il héritera de la configuration par défaut.
Vous pouvez indiquer à kerneld de configurer un
module en exécutant un programme après son chargement
automatique. Voir la section sur l'entrée post-install.
kerneld
peut-il les charger ? Vous ne pouvez pas. Aucune des versions de dosemu
(officielles ou de développement) ne gèrent le chargement des
modules à travers kerneld. Cependant, if vous avez un
noyau 2.0.26 ou supérieur, vous n'avez pas besoin de modules
dosemu particuliers. Installez juste dosemu 0.66.1.
Quand le noyau envoit une requête à kerneld, il
s'attend à recevoir un acquittement dans un délai d'une seconde. Si
kerneld n'envoie pas cet acquittement, ce message est
diffusé. La requête est retransmise et peut éventuellement réussir
Cela arrive couramment sur des systèmes lourdement chargés.
kerneld étant un processus en mode utilisateur, il
est ordonnancé comme tout processus du système. Sous de
fortes charges, il peut ne pas s'exécuter pour envoyer
l'acquittement avant l'expiration du délai.
Si cela se produit quand la charge est faible, essayez de
redémarrer kerneld. Tuez le processus
kerneld et redémarrez-le avec la commande
/usr/sbin/kerneld. Si le problème persiste, vous
devrez envoyer un message d'erreur à
linux-kernel@vger.rutgers.edu mais, s'il vous
plaît soyez sûr que votre version du noyau et de
kerneld soient à jour avant d'envoyer un message sur ce
problème.
mount n'attend pas que kerneld charge
le module du système de fichier Il existe un certain nombre de messages sur le fait que la
commande mount(8) n'attende pas que kerneld
ait chargé le module du système de fichiers. lsmod
montre que kerneld a chargé le module et si vous
répétez la commande mount immédiatement, le montage
sera réussi. Cela semble être une erreur dans le paquetage
modules version 1.3.69f qui affecte des utilisateurs de
Debian (elle peut être corrigée en installant la dernière version
de ce paquetage).
kerneld n'arrive pas à charger le module
ncpfs Vous devez compiler les utilitaires ncpfs avec
l'option -DHAVE_KERNELD. Voir le fichier
Makefile de ncpfs.
kerneld n'arrive pas à charger le module
smbfs Vous utilisez une vieille version des utilitaires
smbmount. Prenez la dernière version (0.10 ou
supérieure) à
ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/.
kerneld n'arrive pas à charger le module du système de fichier racine. Vous ne pouvez pas tout mettre sous forme de modules
: le noyau doit avoir assez de gestionnaires pour monter votre
système de fichiers racine et exécuter les programmes
nécessaires au démarrage de kerneld. Donc vous ne
pouvez pas mettre sous forme de modules :
init,
kerneld et d'autres prgrammes.En fait ce n'est pas vrai. Les dernières version 1.3.x et
toutes les 2.x du noyau, supportent l'utilisation d'un disque ram
qui est chargé par lilo ou loadlin et
il est possible de charger des modules de ce ``disque'' très tôt
dans le processus de démarrage. La marche à suivre est décrite
dans le fichier Documentation/initrd.txt dans
l'arborescence des sources du noyau.
kerneldne se lance pas lors de l'amorçage de la
machine : il veut libgdbm Les nouvelles versions de kerneld ont besoin de la
librairie GNU dbm, libgdbm.so pour fonctionner. La
plupart des installations ont ce fichier dans /usr/lib
mais vous avez probablement lancé kerneld avant que le
système de fichiers de /usr ne soit monté. Un des
symptomes de ceci est que kerneld ne marche pas lors du
démarrage du système et de l'exécution des script rc, mais
fonctionne parfaitement si vous le lancez à la main après. La
solution est soit de déplacer le lancement de kerneld
après que /usr ne soit monté, soit de mettre la librairie
gdbm dans le système de fichiers racine (par exemple
dans /lib).
L'installation de la Slackware (et peut-être d'autres) crée
un fichier /etc/rc.d/rc.modules par défaut qui fait un
modprobe explicite sur une grande variété de modules.
Quels modules exactement sont ``modprobés'' ?, cela dépend de la
configuration initiale du noyau. Vous avez probablement
reconfiguré votre noyau pour enlever un ou plusieurs modules qui
est modprobé dans rc.modules, d'où les messages
d'erreur. Mettez à jour votre fichier rc.modules en
commentant tout module que vous n'utilisez plus, ou enlevez
entièrement ce fichier et laissez kerneld charger les
modules quand on en a besoin.
Vous avez probablement reconfiguré et recompilé votre noyau
et exclu des modules. Vous avez d'anciens modules que vous
n'utilisez pas dans le répertoire /lib/modules.
La solution la plus simple est d'effacer le répertoire
/lib/modules/x.y.z et de retaper make
modules_install depuis le répertoire des sources du noyau.
Notez que ce problème arrive seulement quand vous reconfigurez le
noyau sans changer de version. Si vous voyez cette erreur quand
vous passer à une nouvelle version du noyau, vous avez un autre
problème.
Linux 2.1 est un noyau de développement. Pour cette raison, il se peut que certaines choses ne fonctionnent pas de temps en temps. La façon dont les modules sont manipulés a changé de façon significative. Richard Henderson a la charge du développement du noyau des modules.
En bref, si vous voulez utiliser les modules avec un noyau 2.1, vous devez :
Documentation/Changes et voir
quels paquetages doivent être mis à jour sur votre système ;modutils,
disponible sur
ftp://ftp.redhat.com/pub/alphabits/ ou sur le site
mirroir
ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/Je recommande le noyau 2.1.29, si vous voulez utiliser les modules avec un noyau 2.1.
kerneld peut à l'origine gérer l'établissement de
connexions réseau à travers le réseau téléphonique à la demande
: essayer d'envoyer des paquets à un réseau sans être connecté,
peut entraîner kerneld à lancer le script
/sbin/request_route pour initialiser une connexion PPP
ou SLIP.
Il s'est avéré que c'était une mauvaise idée. Alan Cox, bien connu pour ses travaux sur le réseau dans Linux a écrit sur la liste de diffusion linux-kernel que :
``Le truc request-route est obsolète, cassé et non requis... Il est aussi enlevé des versions 2.1.x.''
A la place d'utiliser le script request-route et
kerneld, je vous encourage vivement à installer le
paquetage diald d'Eric Schenk, disponible à l'url
http://www.dna.lth.se/~erics/diald.html