Le code réseau a été modifié vers les versions 1.3.80 du noyau,
pour permettre le chargement de familles de protocole réseau
(par exemple IPX, AX.25 et AppleTalk) sous la forme de modules.
Cela a provoqué l'ajout de certaines requêtes kerneld :
net-pf-X, où X est un numéro identifiant
le protocole (voir le fichier /usr/src/linux/include/linux/socket.h
pour la liste de ces nombres). Malheureusement, ifconfig
provoque l'envoie de ces messages, donc bon nombre de personnes reçoivent
ces messages lors de l'amorçage de leur machine et lorsqu'ils lancent
ifconfig pour configurer les périphériques loopback.
Ces messages sont uniquement informatifs et ne cassent rien. Vous
pouvez les retirer en ajoutant les lignes suivantes :
alias net-pf-3 off # oublier AX.25
alias net-pf-4 off # oublier IPX
alias net-pf-5 off # oublier AppleTalk
au fichier /etc/conf.modules. Bien sur, si vous utilisez
IPX comme module, n'ajoutez pas la ligne pour désactiver IPX.
Après avoir lancé kerneld, mon système commence à ralentir
lorsque j'active ma connexion PPP.
Il y a eu un certain nombre de messages à ce sujet. Il semble qu'il y a
une interaction malheureuse entre kerneld et le script tkPPP
qui utilisé sur certains système pour configurer et surveiller
la connexion PPP. Le script semble boucler lorsqu'il exécute ifconfig.
kerneld, pour rechercher les modules net-pf-X (voir plus haut dans
ce document), charge un peu la machine et il est possible que vous
obteniez quelques messages Cannot locate module for net-pf-X.
Il n'y a pas actuellement de solution, si ce n'est de ne plus utiliser
tkPPP, ou de le modifier pour qu'il change sa manière de surveiller la connexion.
Ajoutez une entrée pour la carte SCSI dans le fichier
/etc/conf.modules. Lisez la partie décrivant l'entrée
scsi_hostadapter dans ce document.
gcc2_compiled n'est pas définitC'est une erreur dans les utilitaires des modules qui ne se révèle
qu'avec le paquetage binutils2.6.0.9 ou plus ancien,
et c'est documenté dans les notes de mises à jour du paquetage
binutils, donc lisez-la, ou bien mettez à jour le paquetage
des modules qui corrige ce problème.
Les configurations d'un modules sont stockées dans le module lui-même
lorsqu'il est chargé. Donc lorsque kerneld décharge automatiquement
un module, toute configuration particulière disparaît, et lors du prochain
chargement, c'est la configuration par défaut qui sera appliquée.
Vous pouvez spécifier à kerneld de configurer un module en
exécutant un programme après le chargement du module. Consultez la
section traitant l'entrée post-install.
Vous ne pouvez pas. Aucune des versions de dosemu (que cela
soit la version officielle ou de développement) ne gère le
chargement des modules via kerneld.
Toutefois, si vous utilisez les noyaux 2.0.26 ou supérieur,
vous n'avez pas besoin de modules dosemu particuliers?
Installez tout simplement, la version dosemu 0.66.1, ou supérieure.
Lorsque le noyau envoie une requête au démon kerneld, il s'attend
à recevoir un acquittement dans la seconde qui suit. Si kerneld
ne lui renvoie pas cet acquittement, alors ce message est diffusé. La
requête est alors réémise.
Cela arrive sur des systèmes très fortement chargés, comme kerneld
est un processus en mode utilisateur, il est ordonnancé comme n'importe
quel autre processus du système. Si la charge de la machine est importante,
il ne sera pas en exécuté avant que le timeout du noyau intervienne.
Si cela se produit lorsque la charge est faible, essayez de
relancer kerneld (tuez le processus
est relancez le avec la commande /usr/sbin/kerneld).
Si le problème persiste, vous devriez envoyer un courrier électronique
dans la liste linux-kernel@vger.rutgers.edu,
mais assurez-vous que les versions du noyau et de
kerneld sont à jour avant de diffuser un message relatant un
tel problème.
Il y a certains rapports comme quoi la commande
mount(8) n'attend pas que kerneld charge le module du système de
fichiers, et si vous répétez l'opération immédiatement après, cela
fonctionnera. Cela semble être une erreur dans les utilitaires des modules
version 1.3.69f qui affecte certains utilisateurs de distribution
Debian - il peut être corrigé en récupérant en
version plus récente des utilitaires.
Vous devez compiler les outils ncpfs avec l'option -DHAVE_KERNELD.
Regardez le fichier Makefile de ncpfs.
Vous utilisez une vieille version de smbmount.
Récupérez la dernière version (0.10 ou supérieure) sur
ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/.
Vous ne pouvez pas tout transformer en modules : le noyau doit avoir
assez de gestionnaires pour être capable de monter sa racine, et exécuter
certains programmes pour lancer kerneld. Donc, vous ne
pouvez pas modulariser :
init, kerneld, ...En fait, cela n'est vrai qu'à moitié. Les derniers versions du noyau 1.3.x et 2.x permettent l'utilisation d'une ram disque d'initialisation qui est chargée par LILO ou LOADLIN, et donc il est possible de charger le module du système de fichiers de la racine sous cette forme. Consultez le fichier Documentation/initrd.txt situé dans les sources du noyau pour plus d'informations !
Les nouvelles versions de kerneld ont besoin de la bibliothèque
GNU dbm pour s'exécuter, libgdbm.so. Bon
nombre d'installations ont cette bibliothèque installée dans le
répertoire /usr/lib, mais vous avez probablement
lancé kerneld avant que le système de fichier
monté sur le répertoire /usr ne soit monté. Un symptôme
de cette configuration est que kerneld ne se lancera pas
lors de l'amorçage de la machine (à partir de vos fichiers rc), mais
tournera parfaitement si vous le lancez à la main. La solution et
de soit déplacer le lancement de kerneld après que /usr
soit monté, soit de déplacer la bibliothèque dans le système de fichiers
racine, comme par exemple dans le répertoire /lib.
L'installation de la Slackware (et éventuellement d'autres
distributions) crée un fichier /etc/rc.d/rc.modules par
défaut qui effectue une modprobe explicite sur
un certain nombre de modules. Les modules qui sont parcourus dépendent
du noyau initial. Vous avez sûrement reconfiguré votre noyau pour
exclure un certain nombre de ces modules, d'où le message d'erreur.
Mettez à jour le fichier rc.modules en mettant en
commentaires tous les modules que vous n'utilisez plus. Une autre
solution consiste à supprimier le fichier rc.modules
et à laisser kerneld charger les modules lorsqu'il
le juge nécessaire.
Vous avez sûrement reconfiguré/recompilé votre noyau
et exclus certains modules. Vous possédez certains
anciens modules que vous n'utilisez plus mais qui se trouvent
toujours dans le répertoire /lib/modules. La solution
la plus simple conssite à détruire le répertoire /lib/modules/x.y.z
et à effectuer un make modules_install depuis les sources
du noyau. Il est utile de préciser que ce problème n'intervient
que lorsque vous reconfigurez votre noyau sans changer de version?
Si vous voyez cette erreur lors d'un passage à une nouvelle version c'est
qu'il y a un autre problème.
Linux 2.1 est le noyau actuellement en cours de développement. En tant que tel, il faut s'attendre à ce que des problèmes se posent de temps en temps. Une des grandes modifications de la version 2.1 est la gestion des modules ainsi que l'endroit où les modules sont chargés en mémoire. De plus, Richard Henderson est désormais chargé du développement des modules dans le noyau.
En résumé, si vous souhaitez utiliser les modules avec un noyau 2.1, vous devez :
Documentation/Changes et voir quels
paquetage vous devez mettre à jour sur votre système ;modutils que l'on peut
récupérer sur les sites :
ftp://ftp.redhat.com/pub/alphabits/ ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre