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 effondrement de votre système, des problèmes d'entrées sorties étranges, une chute des performances, des reboot aléatoires,... Vérifiez que 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 786DX6/440, c'est que vous avez configuré
un bon nombre de périphériques 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. Si vous avez moins de 16 Mo de mémoire, répondez bien
y à la question "limit memory to low 16MB".
Cela améliore assez bien les performances (surtout sur un système
possédant 4Mo).
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 ce vieux disques Fujitsu Eagles qui fait le bruit
d'un avion lors de son attérissage 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".
Vous pouvez trouver ces renseignement avec la commande "dmesg"
(ou bien en regardant le fichier log du noyau, lorsqu'il existe sur
votre système).C'est une ligne de ce genre :
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
Mon 386 (qui a été volontairement mal configuré) indique :
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
Si malgrè tout vous avez un noyau trop gros, faîtes un
make bzimage. Vous devrez toutefois avoir installé une version
récente de LILO.
Si cela ne compile pas, alors le patch a sûrement échoué, ou bien vous possédez des sources corrompus. Votre version de gcc peut également ne pas être correcte. Soyez sûr que les liens que Linus décrit dans le fichier README sont corrects. En général, si un noyau ne compile pas, c'est qu'un truc ne tourne pas rond, et il est plus que probable que certains outils doivent être reinstallés.
Ou peut-être vous ètes en train de compiler un noyau 1.2.x avec un compilateur
ELF (gcc 2.6.3 et supérieur). Si vous obtenez un message du genre
so-and-so undefined pendant la compilation, il y a des chances
que cela soit ce problème. La solution est très simple. Ajoutez ces lignes
au début de votre fichier
arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/includePuis, relancez
make dep et zImage.
Dans des cas relativement rares, gcc peut échouer en raison de problèmes de matériel. Le message d'erreur ressemble à un truc assez mysterieux "xxx exited with signal 15". Je n'en n'aurais probablement pas parlé si cela ne m'étais arrivé une fois. J'avais un cache mémoire deffectueux et le compilateur avait un résultat plutôt aléatoire. Essayez dans un premier de reinstaller gcc si vous avez des probmlèmes. Vous devriez vous méfier si votre noyaux compile très bien avec les caches externes vidés, une mémoire réduite, etc.
Cela semble géner certaines personnes lorsque je met en doute
leur matériel. Je ne le fais pas exprès. Il existe une FAQ
dédiée à ce sujet : http://www.bitwizard.nl/sig11/.
Soit LILO ne fonctionne pas, soit il n'est pas configuré correctement.
Une fois, un problème dans le fichier de config m'a posé pas mal
de soucis : j'avais mis "boot = /dev/hda1" à la place
de "boot = /dev/hda" (cela peut sembler ennuyant à première vue,
mais une fois que vous avez un fichier de configuration qui fonctionne,
vous ne devez pas avoir besoin d'y retoucher).
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ù il 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. Ils sont
tous deux des systèmes de type ext2fs. L'image du noyau se trouve dans
/usr/src/linux et elle s'appelle zImage.
L'idée est que s'il existe un noyau qui fonctionne dans
/usr/src/linux et qui s'appelle zImage, il est alors possible
de l'utiliser pour la nouvelle disquette.
Une autre alternative, qui peut marcher ou pas est présentée après
cet exemple (cela dépend des systèmes).
En premier, bootez à partir d'une disquette d'installation (boot/root) ou d'une disquette de secours. Ensuite, 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/boot
Insé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=zImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
Allez à la racine /, et démontez la partition /usr :
cd / umount /mnt
Maintenant, vous devriez être capables de rebooter votre système normalement à partir de cette disquette. N'oubliez pas de lancer lilo avant de rebooter !
Comme mentionné ci-dessus, il y a une autre manière très pratique. S'il
vous arrive d'avoir un noyau fonctionnant 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 juste ceci :
changez
/dev/hda3 en /dev/hda1 (la partition /),
/mnt/src/linux en
/mnt, et if=zImage 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ème. Consultez le mini-Howto LILO ou d'autre documentation à ce sujet.
Cela peut être un problème assez grave. Avec les noyaux ayant une
version supérieure à 1.0 (je n'arrive pas à me souvenir laquelle
exactement, mais c'était aux alentours du 20 Avril 1994), un programme
appelé "update" qui vide périodiquement les buffers
du gestionnaire de fichiers a été amélioré. 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 système devrait fonctionner correctement après cela.
Vous possédez probablement un compilateur ELF (gcc et supérieur) et les
sources du noyau 1.2.x. La correction a apporter et d'ajouter les lignes
suivantes au début du fichier arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Cela compilera un noyau 1.2.x avec les bibliothèques a.out.
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 choses qui ne fonctionnent pas.
Si votre CD-ROM est le seul disque d'une interface IDE particulière il doit être configuré pour étant "maître" ou "esclave". C'est l'erreur la plus fréquemment rencontrée.
Creative Labs (par exemple) a mis des interfaces IDE sur leurs cartes sons. Toutefois, cela pose un certain problème car certaines personnes ne possèdent qu'une seule interface mais beaucoup ont deux interfaces IDE sur leur carte mère (IRQ15 généralement), donc une pratique commune est de mettre la troisième interface IDE soundblaster à l'IRQ11.
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 choix.
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 et connectez le disque sur votre seconde interface.
Si vous n'avez pas une seconde interface, l'interface IDE de la carte son est normalement sur l'IRQ 15. Cela devrait fonctionner.
Si pour certaines raisons, vous devez réellement utiliser la
"troisième" interface, utilisez un noyau 1.3.x (par exemple 1.3.57), et
lisez drivers/block/README.ide. Il y a beaucoup plus d'information.
Récupérez une nouvelle version du progamme route ainsi que tout
autre programme effectuant le même genre de manipulations :
/usr/include/linux/route.h (qui est actuellement un fichier
dans /usr/src/linux) a changé.
Mettez à jour à la version 1.2.1.
N'utilisez pas le fichier vmlinux créé dans
/usr/src/linux comme image de boot :
[..]/arch/i386/boot/zImage est la bonne.
Changez le mot dumb en linux dans l'entrée
console du fichier /etc/termcap. Vous devrez également
le faire dans le fichier terminfi.
Le noyau Linux contient un certain nombre de fichiers includes
(les fichiers se terminant par .h) qui se
trouvent dans le répertoire /usr/include.
Ils sont référencés comme cela (ou 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 votre répertoire source
Linux (/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 de voir ses fichiers
par défaut, et que vous désarchiviez les sources du noyau avec
l'option p (conserve le mode),
les utilisateurs ne pourront pas utiliser le compilateur C. Vous devrez
alors utiliser la commande chmod pour résoudre le problème. Il est
plus facile de résoudre ce problème en réinstallant les fichiers includes.
Vous pouvez procéder de la même manière que lors de l'installation des
sources au début, en ajoutant un argument :
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.
Les quelques commandes qui suivent 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
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