Si votre noyau a un comportement surnaturel (ça m'est arrivé !), il y a des
chances pour que vous ayez oublié de faire un "make clean". Les
symptômes peuvent être un plantage de votre système, des problèmes
d'entrées-sorties étranges, une chute des performances, des reboot
aléatoires... Vérifiez que vous avez également fait un make dep.
Si votre noyau consomme beaucoup de mémoire, ou s'il est réellement gros, ou bien s'il faut une éternité pour le compiler même lorsque vous utilisez votre nouveau 986DX6/440, c'est que vous avez configuré un tas de choses (pilotes de périphériques, systèmes de fichiers) dont vous n'avez pas besoin. Si vous ne les utilisez pas, ne les configurez pas car cela prend beaucoup de place en mémoire. Le symptôme le plus visible est l'augmentation sensible du fonctionnement du swap. Si votre disque fait beaucoup de bruit, et qu'il ne s'agit pas d'un de ces vieux disques Fujitsu Eagles qui font le bruit d'un avion lors de son atterrissage lorsque vous l'éteignez, jetez un coup d'oeil à votre configuration.
Vous pouvez calculer la taille mémoire que le noyau utilise en prenant
la mémoire totale de votre machine et en soustrayant la valeur
de la mémoire totale ("total mem") dans /proc/meminfo
ou bien avec la commande "free".
Les options de configuration pour les PC sont : premièrement, dans la catégorie "General Setup" sélectionnez "Parallel port support" et "PC-style hardware". Puis dans "Character devices", sélectionnez "Parallel printer support".
Il y a ensuite le problème des noms de périphérique des imprimantes qui ont
changé dans Linux 2.2. Si vous aviez une imprimante lp1 avec votre
noyau précédent, elle s'appelle probablement lp0
maintenant. Utilisez "dmesg" ou cherchez dans les logs dans
/var/log pour le vérifier.
Si cela ne compile pas, alors un patch a probablement échoué, ou bien vous possédez des sources corrompus. Votre version de gcc peut également ne pas être correcte, ou bien endommagée (par exemple les fichiers d'include peuvent être faux). Soyez sûr que les liens que Linus décrit dans le fichier README sont corrects. En général, si un noyau standard ne compile pas, c'est qu'un truc ne tourne pas rond dans le système, et il est plus que probable que certains outils doivent être reinstallés.
Dans des cas relativement rares, gcc peut échouer en raison de problèmes de matériel. Le message d'erreur ressemble à un truc assez mystérieux "xxx exited with signal 15". Je n'en n'aurais probablement pas parlé si cela ne m'était arrivé une fois. J'avais un cache mémoire défectueux et le compilateur fonctionnait de manière plutôt aléatoire. Essayez dans un premier temps de reinstaller gcc si vous avez des problèmes. Si votre noyau compile très bien avec les caches externes vidés ou une mémoire réduite, alors vous pourrez commencer à soupçonner votre matériel.
Certaines personnes ont tendance à ne pas aimer que je mette en doute leur matériel. Je n'invente rien. Il existe une FAQ dédiée à ce sujet : http://www.bitwizard.nl/sig11/ (NdT : traduite en français à http://www.linux-france.org/article/sig11-fr/sig11-fr.html).
Soit LILO ne fonctionne pas, soit il n'est pas configuré correctement. Une
fois, un problème dans le fichier de configuration m'a posé pas mal de soucis :
j'avais mis "boot = /dev/hda1" à la place de "boot =
/dev/hda" (ce genre d'erreurs n'est pas facile à trouver, mais une
fois que vous avez un fichier de configuration qui fonctionne, il n'y a pas
de raison d'y toucher).
Argh ! La meilleure chose à faire est de booter à partir d'une disquette et
de préparer une nouvelle disquette de boot ("make zdisk"
fait cela très bien). Vous avez besoin de savoir où votre partition
racine (/) se trouve et quel est son type (ext2fs, minix,
etc). Dans l'exemple ci-dessous, vous aurez également besoin de connaître la
partition des sources du noyau (/usr/src/linux), et où elle
est montée.
Dans cet exemple,la racine / est /dev/hda1, la partition
qui supporte /usr/src/linux est /dev/hda3, normalement
montée sur /usr. Toutes les deux ont un système de fichiers de type
ext2fs. L'image du noyau se trouve dans
/usr/src/linux/arch/i386/boot/ et elle s'appelle bzImage.
L'idée est que s'il existe un noyau bzImage qui fonctionne il est
possible de l'utiliser pour la nouvelle disquette. Une autre possibilité
qui peut être meilleure ou pas est présentée après cet exemple (cela dépend
de la façon dont vous avez planté votre système).
Commencez par booter à partir d'une disquette d'installation (boot/root) ou d'une disquette de secours et montez la partition où se trouve le noyau en état de marche :
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Si mkdir vous annonce que le répertoire existe, ignorez le message.
Maintenant, allez dans le répertoire où se trouve le noyau en état de marche.
Notez que
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootInsérez une disquette formatée dans le lecteur "A:" (vérifiez qu'il ne s'agit pas de la disquette boot ou root !), faites une copie de l'image sur le disque et configurez votre partition racine :
cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
Allez à la racine /, et démontez la partition /usr :
cd / umount /mnt
Maintenant, vous devriez être capable de rebooter votre système normalement à partir de cette disquette. N'oubliez pas de lancer lilo (ou ce que vous aviez oublié) avant de rebooter !
Comme mentionné ci-dessus, il y a une autre manière très pratique. S'il se
trouve que vous avez un noyau opérationnel dans /
(/vmlinuz par exemple), on peut s'en servir. Supposons que vous
remplissiez les conditions ci-dessus, et que votre noyau s'appelle
/vmlinuz, faites comme ci-dessus en changeant /dev/hda3 en
/dev/hda1 (la partition /), /mnt/src/linux en
/mnt, et if=bzImage en if=vmlinuz. La petite
note expliquant comment aller dans /mnt/src/linux peut être
oubliée.
Utiliser LILO avec de gros disques (avec un nombre de cyclindres supérieur à 1024) peut poser des problèmes. Consultez le mini-Howto LILO ou la documentation.
Cela peut être un problème assez grave. Avec les noyaux ayant une version
supérieure à 1.0 (aux alentours du 20 avril 1994), le programme
"update" qui vide périodiquement les tampons disque a été
remplacé par "bdflush". Récupérez les sources de
"bdflush" (vous pouvez les récupérer là où vous avez
trouvé votre noyau), et compilez-le (il vaut mieux fonctionner avec un
ancien noyau pendant la compilation et pendant l'installation). Il
s'installera tout seul comme "update" et le nouveau noyau
devrait ensuite fonctionner correctement.
Aussi étrange que cela puisse paraître, beaucoup de gens n'arrivent pas à faire fonctionner leurs disques ATAPI, tout simplement parce qu'il y a un bon nombre de problèmes potentiels.
Si votre CD-ROM est le seul disque d'une interface IDE particulière il doit être configuré en "maître (master)" ou "seul (single)". C'est l'erreur la plus fréquemment rencontrée.
Creative Labs (par exemple) a mis des interfaces IDE sur ses cartes sons. Toutefois, cela pose un problème pour les gens qui ont déjà deux interfaces IDE sur leur carte mère (IRQ15 généralement). Une pratique commune est de faire de l'interface soundblaster un troisième port IDE (IRQ11 je pense).
Cela pose un problème avec Linux car les versions 1.2.x ne supportent pas une troisième interface IDE (cela est géré avec les versions 1.3.x mais ce sont des versions de développement, et la troisième interface n'est pas détectée automatiquement). Pour résoudre ce problème, vous avez plusieurs possibilités.
Si avez déjà un deuxième port IDE, il y a des chances pour que vous ne l'utilisiez pas ou qu'il n'ait pas deux périphériques connectés. Désactivez l'interface ATAPI de la carte son (vous économisez un IRQ) et connectez le disque sur votre seconde interface.
Si vous n'avez pas une seconde interface, mettez interface IDE (pas la partie son) de la carte son sur l'IRQ 15. Cela devrait fonctionner.
Récupérez des versions récentes du progamme route et de tous les
autres programmes manipulant les routes :
/usr/include/linux/route.h (qui est en fait un fichier dans
/usr/src/linux) a changé.
Passez à la version 1.2.1.
N'utilisez pas le fichier vmlinux créé dans /usr/src/linux
comme image de boot mais [..]/arch/i386/boot/bzImage.
Changez le mot dumb en linux dans l'entrée console du
fichier /etc/termcap. Il faudra peut-être aussi ajouter une entrée
terminfo.
Le source du noyau contient un certain nombre de fichiers d'en-têtes (les
fichiers se terminant par .h) qui se trouvent dans le répertoire
/usr/include. Ils sont référencés ainsi (où xyzzy.h doit
être dans /usr/include/linux) :
#include <linux/xyzzy.h>
Normalement, il y a un lien appelé linux dans /usr/include
sur le répertoire include/linux de la racine des sources du noyau
(/usr/src/linux/include/linux dans un système standard). Si ce
lien n'existe pas, ou bien pointe au mauvais endroit, bon nombre de
programmes ne compileront pas. Si vous décidez que les sources du noyau
prennent trop de place sur votre disque et que vous les détruisez, cela sera
un problème. Un autre problème qui peut arriver, c'est avec les permissions
d'accès aux fichiers. Si votre root a un umask qui n'autorise pas
les autres utilisateurs à voir ses fichiers par défaut, et que vous
désarchiviez les sources du noyau sans l'option p (conserve le
mode), les utilisateurs ne pourront pas utiliser le compilateur C. Vous
pouvez alors utiliser la commande chmod pour résoudre le problème
mais il est probablement plus facile de réinstaller les fichiers include.
Vous pouvez procéder de la même manière que lors de l'installation des
sources au début, en ajoutant un argument pour n'extraire que les includes :
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Notez que "make config" va recréer le lien
/usr/src/linux s'il n'existe pas.
Ces quelques exemples de commandes peuvent être assez utiles à ceux qui se demandent comment augmenter certaines limites logicielles imposées par le noyau :
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages