Linux ne prend pas en charge (commande free) plus de 64 Mo de RAM. Ou bien, le nombre de fichiers, d'i-noeuds ou de processus simultanément employés excède les limites du noyau.
Plus de 64 Mo RAM : utiliser un noyau 2.0.36 ou postérieur suffit, avec certaines machines. À défaut employer le paramètre de démarrage mem=xM où x remplace le nombre de Mo de mémoire installés (lire à ce propos la section consacrée au « Paramètres communiqués au noyau »).
SETUP de la machine : ne pas laisser de "memory hole" (à 15 Mo).
J. Bertrand :
Certaines cartes mères (dont les Micronics) possèdent une option dans le BIOS qui s'appelle je crois 'Gestion de la memoire OS/2 / non OS/2'. En activant la gestion de la memoire OS/2 (si on a plus de 64 Mo), les transferts d'information ne se font plus en 16 bits, et Linux reconnaît toute la mémoire.
R. Card :
Dans sa version 2.0, le noyau Linux ne gère plus les descripteurs d'i-noeuds en mémoire et de fichiers ouverts sous forme de tables statiques, mais utilise des listes dont la taille peut varier de manière dynamique.
La taille maximale de ces deux « tables » est définie par deux variables du noyau dont la valeur peut être modifiée grâce à l'appel système sysctl(2). Il est également possible d'accéder à la valeur de ces variables via les fichiers virtuels /proc/sys/kernel/file-max et /proc/sys/kernel/inode-max (fichiers accessibles en lecture comme en écriture).
Afin de modifier le nombre maximal de descripteurs d'i-noeuds en mémoire et de fichiers ouverts, il suffit donc de modifier le contenu de ces fichiers virtuels. Par exemple, sur ftp.lip6.fr, le fichier de commandes rc.local contient :
echo 16384 > /proc/sys/kernel/inode-max echo 8192 > /proc/sys/kernel/file-max
Le nombre maximal de processus est défini par la constante NR_TASKS, déclarée dans le fichier d'en-tête <linux/task.h>. Sa valeur par défaut est 512, ce qui est assez raisonnable. Toutefois, si l'on souhaite modifier cette limite, il est nécessaire de recompiler le noyau car les processus sont gérés sous forme d'une table de taille statique.
Quelle version de noyau dois-je utiliser ?
S. Écolivet :
La version du noyau apparait sous la forme de trois nombres : X.Y.Z.
Après compilation et installation d'un noyau datant de mai-juin 1998 le système ne redémarre plus ou bien les logiciels fonctionnent mal.
O. Tharan explique :
Cela vient du compilateur utilisé ; la version recommandée est la 2.7.2.3 (ni antérieur, ni postérieur). Ne pas utiliser gcc 2.8 et supérieurs, ainsi qu'egcs. Je conseille d'installer gcc pour la compatibilité et la partie d'egcs pour le C++.
R. Card : (utilisation de gcc 2.7.2.3 nécessaire à cause d') un bug dans le noyau 2.0 visant à contourner un bug dans gcc 2.7 (bug qui a été corrigé dans gcc 2.8 et dans egcs et qui entraîne des problèmes si le noyau est compilé avec ces versions récentes des compilateurs).
Je suis en train de compiler un noyau et tout à coup, j'ai l'erreur suivante :
System is 520 kB System is too big. Try using bzImage or modules. make[1]: *** [zImage] Error 1
O. Tharan :
Effectivement, le noyau est trop gros. Ceci est dû à la fameuse barrière des 640 Ko ! En effet, au démarrage le processeur est en mode réel et ne peut accéder qu'aux premiers 640 Ko, il faut dans cet espace charger à la fois LILO (512 octets) et le noyau. De plus, le noyau a besoin de cet espace pour se décompacter et se lancer, il faut donc ruser (source : Linux Device Drivers).
Il faut donc compiler le noyau de sorte qu'il puisse se charger correctement. Pour cela, utilisez la commande "make bzImage" et non "make zImage" pour pouvoir compiler un gros noyau. Mettre les pilotes qui ne vous servent pas tout le temps en module, afin qu'ils soient chargés à la demande et que le noyau soit plus petit.
Il est d'ailleurs recommandé de toujours utiliser la cible bzImage, même si le noyau est petit. Les rares cas où il faudra utiliser la cible zImage se trouvent avec des problèmes matériels ou une version de LILO trop ancienne (cf. documentation du noyau).
Affichage console très lent, avec carte mère DFI PVB3+
A. Buret de Longagne : Dans le SETUP :
CHIPSET FEATURES SETUP ... CPU TO PCI WRITE BUFFER : DISABLED
JC Delépine :
Le noyau fait appel à kmod (ou kerneld, si antérieur à 2.2), qui demande à modprobe, lequel recherche dans les répertoires définis dans le fichier /etc/conf.modules ou, à défaut dans les répertoires /lib/modules/`uname - r`/*
Configuration de modprobe : modprobe -c.
Module Howto, /usr/src/linux/Documentation/modules.txt
Lors de la compilation du noyau, j'ai l'erreur suivante :
make[1]: Entering directory `/usr/src/linux/arch/i386/boot' as86 -0 -a -o bootsect.o bootsect.s make[1]: as86: Command not found make[1]: *** [bootsect.o] Error 127
O. Tharan :
Il manque l'assembleur 16 bits (as86) ; Installer le paquetage correspondant : bin86.
J'ai un problème au début de la compilation de mon noyau, avec les erreurs suivantes :
$ make xconfig [ ... ] gcc -I/usr/src/linux-2.0.36/include -02 -fomit-frame-pointer -g -Wall *c -o tkparse.o tkparse.c tkparse.c:21:stdlib.h: aucun fichier ou repertoire de ce type
O. Tharan :
Les fichiers d'en-tête (include) de la libc ne sont pas installés. Installez le paquet glibc-devel (Red Hat) ou libc6-dev (Debian 2.1) pour installer les fichiers .h dans /usr/include, qui seront utilisés pour compiler ce dont vous avez besoin.
Note à ceux qui objecteront que les fichiers d'en-tête de la libc ne sont pas nécessaires pour compiler le noyau : cette erreur survient pendant la compilation de l'outil de configuration du noyau, ce n'est pas encore la compilation du noyau !
Depuis le passage en 2.2, on voit souvent la question : Je viens de mettre le kernel 2.2.1, mais à la compilation il dit: "error in checksum.c"
O. Tharan :
Tu as une version de patch trop vieille. Fais :
rm arch/i386/lib/checksum.[co] make zImage
Messages du système lors du démarrage, de l'arrêt ou de l'utilisation de certains programmes réseau :
insmod: NOM_DE_FONCTION: wrong version or undefined [ ... nombreux ... ] Loading failed! The module symbols (from linux-NUMERO_VERSION) don't match your linux-NUMERO_VERSION
En ce qui concerne les modules réseau : ajouter au fichier /etc/modules.conf
alias net-pf-3 off # si pas AX25 alias net-pf-4 off # si pas de module IPX (protocole reseau Novell Netware) alias net-pf-5 off # si pas de module Appletalk (protocole reseau Apple)
E. Lassauge Les messages de depmod, après recompilation d'un noyau Red Hat, sont dus au initrd standard de cette distribution. Grâce à cette directive de LILO, on monte au boot un système de fichiers dans un RamDisk (dit initrd, init Ram Disk). Avec certaines configurations Red Hat (par exemple la 4.0), ce système de fichiers contient « ce qu'il faut » pour forcer le chargement du module du pilote du disque dur. Si on recompile le noyau, le initrd cherche quand même à charger un module éventuellement ancien.
La solution consiste à utiliser un autre initrd pour le nouveau noyau. Pour cela, il faut modifier le fichier de config de LILO. Consulter le fichier /usr/src/linux/Documentation/initrd.txt (les pointeurs y sont un peu anciens mais j'ai fini par tout trouver, surtout le très utile initrd-example.tgz).
Exemple de /etc/lilo/conf avec 2 initrd :
boot=/dev/sda map=/boot/map install=/boot/boot.b message = /boot/boot.message-2.0.x image=/boot/vmlinuz-2.0.30 label=linux root=/dev/sda1 noinitrd read-only image=/boot/vmlinuz-2.0.18 label=redh root=/dev/sda1 initrd=/boot/initrd-2.0.18 read-only
depmod), que des modules inutiles existent (cas des Red Hat après recompilation du noyau sans mise-à-jour). On peut s'en affranchir en détruisant /lib/modules/NUMÉRO_DE_VERSION avant de réinstaller les modules (make modules_install) mais cela n'en vaut pas la peine car risque de rendre inopérant le noyau livré par la distribution ;modules.conf ou conf.modules. Mais si les deux existent, alors c'est le deuxième qui sera lu.La compilation d'un noyau échoue avec un message concernant objdump, par exemple "objdump: 0x100000: No such file or directory".
objdump et objcopy a changé. Ca ne marche plus avec les Makefiles du noyau 2.0.x ;/usr/bin/encaps, comme cela est dit dans release.binutils-2.8.1.0.1. En effet, le Makefile du noyau teste la présence de encaps pour déterminer quelle version des binutils on a. Si encaps est présent, objdump est utilisé, sinon c'est objcopy qui l'est.Recompiler un noyau avec prise en charge du système de fichiers ("filesystem") de type iso9660.
make zlilo » ne fonctionne pasDécommenter la ligne #INSTALL_PATH=/boot du Makefile.
Les devices sont numérotés selon leur ordre d'apparition et non en fonction de leurs addresses comme sur les Unix classiques.
Si la config hardware change par rajout de carte ou de périphèriques, il faut modifier /etc/fstab pour pouvoir amorcer Linux... Penser aussi aux périphériques SCSI qui s'autoconfigurent en termes d'ID ou qui sont "hot pluggables"
É. Dumas :
La solution s'appelle devfs. Bien ce cela stable depuis des lustres, il ne se trouve toujours pas le noyau.