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 pas
Dé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.