Moudules de recompil du noyau (Redhat)

Top Page

Reply to this message
Author: Fabrice Bellet
Date:  
To: guilde
Old-Topics: Re: SMP & modules
Subject: Moudules de recompil du noyau (Redhat)
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