Salut,
j'ai ete souvent confronte sous la Redhat (5.0 en particulier) au
fait que la recompilation du noyau + relancement de lilo ne permettait
plus de charger les modules a la demande ensuite. En particulier, plus
de carte reseau, plus de modules de son, etc etc.
Le probleme est lie a lilo et a la maniere dont le boot redhat determine
le repertoire des modules, qui n'a pas l'appelation standard
(//lib/modules/<version> ou <version> est le numero de version du noyau
linux -- trois nombres separes par des points -- sans aucun suffixe).
Redhat cree au boot un lien symbolique de /lib/modules/<version> vers
/lib/modules/preferred dans le script /etc/rc.d/rc.sysinit. Et <version>
correspond a la version du noyau sous lequel vous etes en train de
demarrer. Seulement il est nomme selon les habitudes de redhat
avec une extension supplementaire. Par exemple, redhat-5.2 installe
le noyau "2.0.36-0.7". Toute la difficulte pour le script de
demarrage consiste a recuperer cette extension "-0.7" pour faire
le lien symbolique correctement.
Les moyens d'y parvenir ont varie entre la redhat-5.0 et la redhat-5.2:
redhat-5.0 (extrait de /etc/rc.d/rc.sysinit)
==========
set `cat /proc/cmdline`
while [ $# -gt 0 ]; do
if echo $1 | grep '^BOOT_IMAGE=' > /dev/null ; then
image=`echo $1 | awk -F= '{ print $2 }'`
kernelfile=`/sbin/lilo -I $image`
if [ -n "$kernelfile" ]; then
kernelname=`echo $kernelfile | awk -F- '{ print $1 }'`
versioninfo=`echo $kernelfile | sed "s|${kernelname}-||"`
if [ "$kernelname" = "/boot/vmlinuz" -a \
-d /lib/modules/$versioninfo -a \
$versioninfo != `uname -r` ]; then
ln -sf $versioninfo /lib/modules/preferred
fi
fi
fi
shift
done
La methode est ici de recuperer la sortie de /proc/cmdline
(exemple : auto BOOT_IMAGE=linux ro root=805 mem=128M), et
d'en extraire la chaine qui suit BOOT_IMAGE (ici linux). De recuperer
dans lilo le fichier noyau associe a cette entree (lilo -I linux),
qui par chance contient l'information correspondante (ici
/boot/vmlinuz-2.0.35-2), et c'est gagne. Enfin, c'est gagne, si
vous n'avez pas eu la facheuse idee de changer le noyau de boot
(par exemple /boot/vmlinuz-perso) apres une recompilation
personelle dans le /etc/lilo.conf.
Questions :
* Au fait, que se passe-t-il si l'on n'a pas installe lilo ????
* A quel moment est ce que modprobe est configure pour savoir
que les modules doivent etre charges depuis /lib/modules/preferred ?
"modeprobe -c | grep path" indique que .../preferred fait bien
partie des chemins testes, bien que ca ne soit pas ecrit
explicitement dans /etc/conf.modules...
redhat-5.2 (extrait de /etc/rc.d/rc.sysinit)
==========
# Set up kernel version-dependent symlinks.
rm -f /lib/modules/preferred
if [ -n "$USEMODULES" ]; then
ktag="`cat /proc/version`"
mtag=`grep -l "$ktag" /lib/modules/*/.rhkmvtag` 2> /dev/null
if [ -n "$mtag" ]; then
mver=`echo $mtag | sed -e 's,/lib/modules/,,' -e 's,/.rhkmvtag,,' -e 's,
[ ].*$,,'`
ln -sf /lib/modules/$mver /lib/modules/preferred
ln -sf /boot/System.map-$mver /boot/System.map
ln -sf /boot/module-info-$mver /boot/module-info
fi
fi
Dans la version 5.2, la determination du numero de version a change,
puisqu'elle ne passe plus par la config de lilo, mais par l'analyse de
la chaine de caracteres retournee par cat /proc/version. Ca suppose
par contre l'existance d'un fichier .rhkmvtag dans les repertoires
des modules...
Question :
* Que se passe-t-il si la commande "grep -l "$ktag" /lib/modules/*/.rhkmvtag"
match plusieurs fichiers ??
par exemple /lib/modules/2.0.36-0.6/.rhkmvtag et
/lib/modules/2.0.36-0.7/.rhkmvtag
si l'on tourne sous un noyau 2.0.36 (donc ktag==2.0.36)
En esperant que ca eclaire un peu les "aventuriers des modules perdus",
Fab
