Provided by: manpages-fr_4.27.0-1_all 
NOM
modprobe.d – Répertoire de configurations pour modprobe
SYNOPSIS
/etc/modprobe.d/*.conf
/run/modprobe.d/*.conf
/usr/local/lib/modprobe.d/*.conf
/usr/lib/modprobe.d/*.conf
/lib/modprobe.d/*.conf
DESCRIPTION
Comme la commande modprobe peut ajouter ou supprimer plus d'un module, et à cause des modules qui ont des
dépendances, il y a eu besoin d'une méthode pour spécifier quelles options utiliser avec les modules..
Ils peuvent également être utilisés pour créer des alias pratiques : des noms alternatifs pour un module,
ou ils peuvent remplacer le comportement normal de modprobe pour ceux qui ont des exigences particulières
(comme l'insertion de plus d'un module).
Notez que les noms de module et d'alias (comme d'autres noms de modules) peuvent avoir les signes - ou _
dans leurs noms ; les deux sont interchangeables pour toutes les commandes sur les modules, la conversion
du tiret bas étant automatique.
FORMAT DE CONFIGURATION
Les fichiers de configuration comprennent une commande par ligne, avec les lignes blanches et celles
commençant par un croisillon # ignorées (ce qui est pratique pour ajouter des commentaires). Une
contre-oblique \fP à la fin de la ligne la fait continuer sur la ligne suivante, ce qui rend ces fichiers
un peu plus propres.
Voir la section COMMANDES plus loin pour plus d'informations.
RÉPERTOIRES DE CONFIGURATION ET PRIORITÉS
Les fichiers de configuration sont lus à partir des répertoires listés dans SYNOPSIS dans cet ordre de
préséance. Une fois qu'un fichier d'un nom donné est chargé, tout fichier du même nom dans les
répertoires suivants est ignoré.
Tous les fichiers de configuration sont triés par ordre lexicographique, quel que soit le répertoire dans
lequel ils se trouvent. Ces fichiers de configuration peuvent être complètement remplacés (en ayant un
nouveau fichier de configuration portant le même nom dans un répertoire de priorité plus élevée) ou
remplacés partiellement (en ayant un fichier de configuration ordonné plus tard).
NOTE : les répertoires de configuration peuvent être modifiés au moyen de la variable d'environnement
MODPROBE_OPTIONS. Voir la section ENVIRONNEMENT dans modprobe(8).
COMMANDES
alias nom_aternatif nom_du_module
Cette commande permet de donner un nom alternatif à un module. Par exemple : « alias mon_mod
le_super_long_nom_de_module » signifie que vous pouvez utiliser « modprobe mon_mod » au lieu de
« modprobe le_super_long_nom_de_module ». Il est possible aussi d'utiliser les caractères jokers de
type interpréteur de commande, ainsi « alias mon_mod* le_super_long_nom_de_module » signifie que
« modprobe mon_mod_qqchose » aura le même effet. Il ne peut pas y avoir d'alias vers d'autres alias
(cela mènerait à la folie), mais les alias peuvent avoir des options qui seront ajoutées aux autres
options.
Notez que les modules peuvent aussi contenir leurs propres alias, ce qui est visible en utilisant
modinfo. Ces alias ne sont utilisés qu'en dernier ressort lorsque il n'y a pas réellement de module,
de commande install, remove ou alias dans la configuration.
blacklist nom_du_module
Les modules peuvent contenir leurs propres alias : habituellement ce sont des alias décrivant le
périphérique pris en charge, tel que « pci:123... ». Ces alias « internes » peuvent être écrasés par
des mots clés d' « alias » habituels, mais il y a des cas où deux ou plus modules prennent en charge
les mêmes périphériques, ou un module non valable déclare prendre en charge un périphérique alors
qu'il ne le fait pas : le mot clé blacklist indique que tous les alias « internes » de ce module
particulier sont ignorés.
install nom_du_module commande...
Cette commande indique à modprobe d'exécuter votre commande au lieu d'ajouter le module au noyau
comme normalement. La commande peut être toute commande d'interpréteur : cela vous permet de faire
autant de procédures complexes que vous le souhaitez. Par exemple, si le module « fred » fonctionne
mieux avec le module « barney » déjà installé, (mais qui n'est pas une dépendance, donc modprobe ne
le chargera pas automatiquement), vous pouvez taper « install fred /sbin/modprobe barney;
/sbin/modprobe --ignore-install fred », qui fera ce que vous voulez. Notez que l'option
--ignore-install empêchera le second modprobe d'exécuter encore la même commande install. Voir aussi
remove ci-dessous.
L'avenir à long terme de cette commande en tant que solution au problème de la fourniture de
dépendances de modules supplémentaires n'est pas assuré et il est prévu de remplacer cette commande
par un avertissement quant à son éventuelle suppression ou obsolescence à un moment. Son utilisation
complique la détermination automatisée des dépendances des modules par les utilitaires des
distributions, tels que mkinitrd (car ils doivent maintenant interpréter d'une manière ou d'une autre
ce que les commandes install pourraient faire). Dans un monde parfait, les modules devraient fournir
toutes les informations de dépendances sans l'utilisation de cette commande et des travaux sont en
cours pour implémenter la prise en charge des dépendances « soft » dans le noyau Linux.
L'utilisation de la chaîne « $CMDLINE_OPTS » entraînera son remplacement par toutes les options
indiquées sur la ligne de commande de modprobe. Cela peut être utile, car les utilisateurs
s'attendent à ce que « modprobe fred opt=1 » passe l'argument « opt=1 » au module, même s'il y a une
commande install dans le fichier de configuration. Ainsi notre exemple ci-dessus devient « install
fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred $CMDLINE_OPTS ».
options nom_de_module option...
Cette commande permet d'ajouter des options au module nom_de_module (qui peut être un alias) chaque
fois qu'il est ajouté au noyau : soit directement (en utilisant modprobe nom_de_module) ou parce
qu'un module qui a été chargé en dépend.
Toutes les options sont ajoutées ensemble, elles peuvent venir d'une option pour le module, pour un
alias ou sur la ligne de commande.
remove nom_de_module commande...
Cette commande est similaire à la commande install ci-dessus, à part qu'elle est invoquée lors de
l'exécution de « modprobe -r ».
softdep nom_de_module pre: modules... post: modules...
La commande softdep permet d'indiquer des dépendances de module « soft » ou optionnelles.
nom_de_module peut être utilisé sans les modules optionnels installés, mais généralement il manque
quelques fonctionnalités. Par exemple, un pilote pour un stockage HBA peut avoir besoin qu'un autre
module soit chargé pour utiliser toutes les fonctionnalités de gestion.
Les modules « pre-deps » et « post-deps » sont des listes de noms et/ou d'alias d'autres modules que
modprobe essaiera d'installer (ou de supprimer) dans l'ordre avant et après le module principal donné
dans l'argument nom_de_module.
Exemple : assumer que « softdep c pre: a b post: d e » est fourni dans la configuration. Exécuter
« modprobe c » est maintenant équivalent à « modprobe a b c d e » sans les « softdep ». Des arguments
tels que --use-blacklist sont appliquées à tous les modules indiqués, alors que les paramètres du
module ne s'appliquent qu'au module c.
Note : s'il y a des commandes install ou remove avec le même argument nom_de_module, softdep prend la
préséance.
weakdep nom_de_module modules...
La commande weakdep permet de spécifier les dépendances faibles des modules. Elles sont similaires
aux pre softdeps, avec la différence que l'espace utilisateur ne prévoit pas de charger cette
dépendance avant le module indiqué. À la place, le noyau doit en appeler une ou plusieurs durant
l'essai du module, en fonction du matériel auquel il est lié. L'objectif du module faible est
d'accepter qu'un pilote indique que certaines dépendances peuvent être nécessaires, donc elles
devraient être présentes dans le système de fichier (par exemple dans initramfs) lorsque le module
est essayé.
Exemple : passer « weakdep c a b ». Un programme créant un initramfs sait qu'il doit ajouter a, b et
c au système de fichiers puisque a et b peuvent être demandés/exigés au lancement. Lorsque c est
chargé et a été éprouvé, il peut lancer des appels request_module() entrainant a et b à être aussi
chargés.
COMPATIBILITÉ
Une future version de kmod viendra avec un avertissement sérieux pour empêcher l'usage de la commande
install comme expliqué ci-dessus. Cela arrivera lorsque la prise en charge des dépendances « soft » sera
effective. Cette prise en charge améliorera la prise en charge actuelle des softdeps par cet outil en
fournissant de telles dépendances directement dans le module.
COPYRIGHT
Cette page de manuel était originellement sous copyright 2004, Rusty Russell, IBM Corporation.
VOIR AUSSI
modprobe(8), modules.dep(5)
BOGUES
Merci d'envoyer les rapports de bogues directement au suivi des bogues de kmod à
https://github.com/kmod-project/kmod/issues/ avec la version utilisée, les étapes pour reproduire le
bogue et le retour espéré.
AUTEURS
De nombreuses contributions proviennent de la liste de diffusion linux-modules
<linux-modules@vger.kernel.org> et de Github. Si vous avez une copie de kmod.git lui-même, les sorties de
git-shortlog(1) et de git-blame(1) vous indiquerons les auteurs de certaines parties du projet.
Lucas De Marchi <lucas.de.marchi@gmail.com> est le responsable actuel du projet.
TRADUCTION
La traduction française de cette page de manuel a été créée par bubu <bubub@no-log.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
kmod 25 avril 2025 MODPROBE.D(5)