modprobe - Manipulations haut niveau de modules chargeables.

modprobe [-adnqv] [-C config] module [symbole=valeur ... ]
modprobe [-adnqv] [-C config] [-t type] pattern
modprobe -l [-C config] [-t type] pattern
modprobe -c [-C config]
modprobe -r [-dnv ] [-C config] [ module ...]
modprobe -Vh

-a, --all

Charge tous les modules au lieu de s'arrêter après le premier chargement réussi.

-c, --showconfig

Affiche la configuration courante.

-C, --config config

Utilise le fichier de configuration configfile plutôt que (le facultatif) /etc/modules.conf pour le paramétrage. La variable d'environnement MODULECONF peut être aussi utilisée pour sélectionner (et surcharger) un fichier de configuration différent du fichier par défaut /etc/modules.conf, ou /etc/conf.modules (à éviter).

Quand la variable d'environnement UNAME_MACHINE est remplie, modutils l'utilisera à la place du champ "machine" de l'appel-système uname(). Ceci est surtout utile si vous compilez des modules 64 bits dans un espace utilisateur 32 bits ou inversement ; remplissez UNAME_MACHINE avec le type de modules construits. La version actuelle de modutils ne supporte pas la construction croisée complète de modules, elle est limitée au choix entre 32 et 64 bits de l'architecture hôte.

-d, --debug

Affiche des informations sur la représentationt interne de la pile de modules.

-h, --help

Affiche une page d'aide et se termine.

-k, --autoclean

Marque les modules pour auto-nettoyage. Utilisé par le noyau quand il appelle modprobe pour satisfaire les dépendances manquantes. L'option -q est impliquée par -k. Ces options seront directement transmises à insmod.

-l, --list

Affiche les modules chargeables.

-n, --show

Ne rien faire en réalité, indiquer juste ce qui serait fait.

-q, --quiet

Ne se plaint pas si insmod échoue au chargement d'un module. Continue en silence à essayer d'autres possibilités. Cette option sera directement transmise à insmod.

-r, --remove

Enlève le module (ou la pile) ou exécute un auto-nettoyage suivant s'il y a des modules indiqués ou non sur la ligne de commande.

-s, --syslog

Envoyer les messages à syslog plutôt que sur la sortie d'erreur. Cette option sera directement transmise à insmod.

-t moduletype; --type moduletype

Ne considère que les modules du type indiqué. modprobe ne s'occupera que des modules dont le répertoire inclut exactement "/moduletype/". Il peut contenir plusieurs noms ; par exemple "-t drivers/net" listera tous les modules dans xxx/drivers/net/ et ses sous-répertoires.

-v, --verbose

Affiche les commandes au fur et à mesure qu'elles sont exécutées.

-V, --version

Affiche le numéro de version de modprobe.

Note :

Les noms de modules ne contenir ni chemin d'accès (pas de '/'), ni de suffixe modprobe, /lib/modules/2.4.21/kernel/char/lp ou lp.o sont invalides. Ceci concerne la ligne de commande et les entrées dans les fichiers de configuration.

Les utilitaires modprobe et depmod rendent un noyau Linux modulaire plus facilement gérable pour tous les utilisateurs, administrateurs et les développeurs de distribution.
modprobe utilise un fichier de type "Makefile" pour les dépendances, créé par depmod, pour charger automatiquement les modules corrects depuis l'ensemble des modules disponibles dans les répertoires prédéfinis.
modprobe sert à charger un seul module, la pile de modules dépendants, ou tous les modules marqués par une étiquette spécifique.
modprobe chargera automatiquement la base de modules nécessaire à un ensemble, comme décrit dans le fichier de dépendances modules.dep. Si un chargement échoue, la totalité des modules chargés par la commande sera déchargée automatiquement.
modprobe a deux façons pour charger des modules. La première (le mode d'essai) essaiera de charger un module de la liste (définie par pattern). modprobe arrête le chargement dès qu'un modules est chargé avec succès. Cela peut être utilisé pour charger automatiquement un pilote de carte ethernet parmi d'autres.
Sinon, modprobe peut charger tous les modules d'une liste. Voir les EXEMPLES ci dessous.
Avec l'option -r, modprobe déchargera automatiquement l'ensemble des modules, de la même façon qu'en utilisant rmmod -r. On peut noter que modprobe -r seul fera le ménage parmi les modules inutilisés et lancera les commandes de pré- et de post-enlèvement dans le fichier de configuration /etc/modules.conf.
Avec l'option -l combinée avec l'option -t une liste de tous les modules disponibles d'un type donné sera affichée.
L'option -c affichera la configuration courante (par défaut et le fichier de configuration).

Le comportement de modprobe (et de depmod) peut être modifié par le fichier (optionnel) de configuration /etc/modules.conf.
Pour une description plus détaillée de ce que peut contenir ce fichier, ainsi que la configuration par défaut de depmod et de modprobe, voir modules.conf(5).
Note : les commandes de pré- et de post-enlèvement ne seront pas exécutées si un module est déchargé (car ce module est marqué 'autoclean') par kerneld ! Voir plutôt le support des données persistantes.
Si vous voulez utiliser les caractéristiques de pré et de post-installation, vous devez enlever l'option 'autoclean' pour kerneld et plutôt mettre une commande dans votre "crontab" (c'est utilisé par les systèmes kmod); pour effectuer un rafraîchissement toutes les deux minutes :

 */2 * * * * test -f /proc/modules && /sbin/modprobe -r

L'idée est que modprobe regardera en premier dans le répertoire contenant les modules compilés pour la version spécifique du noyau en cours d'exécution (/lib/modules/2.2.12-20/ par exemple). Si le module n'est pas trouvé ici, modprobe ira dans le répertoire commun de la version du noyau (ex. 2.0, 2.2).
Quand vous installez un nouveau noyau, les modules sont déplacés dans le répertoire relatif à la version spécifique (et à la version générale) du noyau que vous installez. Alors vous devez créer un lien symbolique de ce répertoire vers le répertoire par défaut.
Chaque fois que vous compilez un nouveau noyau, la commande make modules_install créera un nouveau répertoire, mais ne change pas le lien par défaut.
Quand vous avez un module non relié à la distribution du noyau vous devez le mettre dans un des répertoires indépendants de la version sous /lib/modules.
C'est la stratégie par défaut. On peut passer outre avec /etc/modules.conf.

modprobe -t net

Charge un des modules qui sont stockés dans le répertoire étiqueté "net". Chaque module est essayé jusqu'à réussite.

modprobe -a -t boot

Tous les modules qui sont dans les répertoires étiquetés boot seront chargés.

modprobe slip

Cela tentera de charger le module slhc.o si il n'a pas déjà été chargé, car le module slip a besoin de fonctionnalités du module slhc. Cette dépendance est décrite dans le fichier "modules.dep" qui est créé automatiquement par depmod

modprobe -r slip

déchargera le module slip. Il enlèvera aussi le module slhc automatiquement, s'il n'est pas utilisé par d'autres modules bien sûr (comme ppp).

/etc/modules.conf, (aussi mais à éviter: /etc/conf.modules)
/lib/modules/*/modules.dep,
/lib/modules/*

depmod(8), lsmod(8), kerneld(8), ksyms(8), rmmod(8)

Si l'UID effectif n'est pas égal à l'UID réel, alors modprobe traite ses entrées avec suspicion. Le dernier paramètre est toujours considéré comme un nom de module, même s'il débute par '-'. Il ne peut y avoir qu'un nom de module, et les options de la type "variable=valeur" sont interdites. Le nom de module est toujours traité comme une chaîne, et aucun développement n'est réalisé en mode de sécurité renforcé. Toutefois les développements sont toujours appliqués aux données lues dans le fichier de configuration.
L'UID effectif peut être différent de l'UID quand modprobe est invoqué par le noyau, depuis le 2.4.0-test11. Dans un monde idéal, modprobe pourrait faire confiance au noyau pour ne lui fournir que des paramètres valides. Malheureusement, il y a eu au moins une attaque basée sur le passage de paramètres non-vérifiés par du code de haut-niveau du noyau. Depuis modprobe ne fait plus confiance au noyau.
modprobe bascule automatiquement en mode de sécurité renforcé quand l'environnement n'est constitué que de ces chaînes :

 HOME=/
 TERM=linux
 PATH=/sbin:/usr/sbin:/bin:/usr/bin

Ceci correspond à l'exécution de modprobe par le noyau depuis le 2.2 jusqu'au 2.4.0-test11, même si UID == E-UID, ce qui se produisait sur les noyaux anciens.

Si le répertoire /var/log/ksymoops existe et si modprobe est lancé avec un option de chargement ou déchargement de module, alors modprobe journalisera ses actions et codes de retour dans /var/log/ksymoops/`date +%Y%m%d.log`. Il n'y a pas d'option pour désactiver cet enregistrement automatique. Si vous voulez l'éviter, ne créez pas /var/log/ksymoops. Lorsque ce répertoire existe, il doit appartenir à root, avoir le mode 644 ou 600 et il faudrait lancer le script insmod_ksymoops_clean quotidiennement.

depmod(8), insmod(8).

Le motif pattern fourni à modprobe aura souvent besoin d'être protégé pour s'assurer qu'il sera correctement interprété.

Jacques Gelinas (jack@solucorp.qc.ca)
Bjorn Ekwall (bj0rn@blox.se)

Jérome Signouret, 2000.
Christophe Blaess, 2003.