Man page - modprobe.conf(5)

Packages contains this manual

Package: kmod
apt-get install kmod

Manuals in package:

Documentations in package:

libkmod2

Available languages:

en fr pl ro de

Manual

MODPROBE.D

NOM
SYNOPSIS
DESCRIPTION
FORMAT DE CONFIGURATION
RÉPERTOIRES DE CONFIGURATION ET PRIORITÉS
COMMANDES
COMPATIBILITÉ
COPYRIGHT
VOIR AUSSI
BOGUES
AUTEURS
TRADUCTION

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

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 .