Provided by: manpages-de_4.27.0-1_all 
BEZEICHNUNG
modprobe.d - Konfigurationsverzeichnis für Modprobe
ÜBERSICHT
/etc/modprobe.d/*.conf
/run/modprobe.d/*.conf
/usr/local/lib/modprobe.d/*.conf
/usr/lib/modprobe.d/*.conf
/lib/modprobe.d/*.conf
BESCHREIBUNG
Da der Befehl modprobe mehr als ein Modul hinzufügen oder entfernen kann und ein Modul über
Abhängigkeiten verfügen kann, wird eine Methode benötigt, um die mit diesen Modulen verwendeten Optionen
anzugeben. Sie können auch für bequeme Aliase verwandt werden: alternative Namen für ein Modul oder sie
können das normale Verhalten von modprobe insgesamt für solche außer Kraft setzen, die besondere
Anforderungen haben (wie beispielsweise das Einfügen von mehr als einem Modul).
Beachten Sie, dass Modul- und Aliasnamen (wie andere Modulnamen) »-« oder »_« enthalten können: beide
können in sämtlichen Modulnamen austauschbar verwandt werden, da Unterstriche automatisch umgewandelt
werden.
KONFIGURATIONSFORMAT
Die Konfigurationsdateien enthalten einen Befehl pro Zeile, wobei leere Zeilen und Zeilen, die mit »#«
beginnen, ignoriert werden (nützlich zur Aufnahme von Kommentaren). Ein \' am Zeilenende führt dazu, dass
die Zeile auf der nächsten Zeile fortgeführt wird, wodurch die Dateien etwas ordentlicher werden.
Siehe den nachfolgenden Abschnitt BEFEHLE für weiteres.
KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE
Konfigurationsdateien werden aus den in der ÜBERSICHT aufgeführten Verzeichnissen in der dortigen
Reihenfolge gelesen.. Sobald eine Datei des angegebenen Dateinamens geladen ist, werden alle Dateien mit
dem gleichen Namen in nachfolgenden Verzeichnissen ignoriert.
Alle Konfigurationsdateien werden in lexikographischer Reihenfolge sortiert, unabhängig von dem
Verzeichnis, in dem sie sich befinden. Konfigurationsdateien können entweder komplett ersetzt (indem eine
Konfigurationsdatei mit dem gleichen Namen in einem Verzeichnis mit höherer Priorität abgelegt wird) oder
teilweise ersetzt werden (indem eine Konfigurationsdatei vorhanden ist, die später einsortiert ist).
HINWEIS: Die Konfigurationsverzeichnisse können mit der Umgebungsvariablen MODPROBE_OPTIONS verändert
werden. Siehe den Abschnitt ENVIRONMENT in modprobe(8).
BEFEHLE
alias Platzhalter Modulname
Dies ermöglicht Ihnen die Angabe von Ersatznamen für ein Modul. Beispiel: »alias mein-mod
wirklich_langer_Modulname« bedeutet, dass Sie »modprobe mein-mod« anstelle von »modprobe
wirklich_langer_Modulname« verwenden können. Sie können auch Shell-artige Platzhalter verwenden, so
dass »alias mein-mod* wirklich_langer_Modulname« bedeutet, dass »modprobe mein-mod-irgendetwas« die
gleiche Auswirkung hat. Sie können keine Aliase auf andere Aliase haben (das würde verrückt machen),
aber Aliase können Optionen haben, die zu anderen Optionen hinzugefügt werden.
Beachten Sie, dass Module auch ihre eigenen Aliase enthalten können, die Sie mittels modinfo(8) sehen
können. Diese Aliase werden als Ultima Ratio verwandt (d.h. falls es kein echtes Modul oder den
Befehl install, remove oder alias in der Konfiguration gibt).
blacklist Modulname
Module können ihre eigenen Aliase enthalten: normalerweise gibt es Aliase, die die unterstützten
Geräte beschreiben, wie »pci:123…«. Diese »internen« Aliase können durch normale
»alias«-Schlüsselwörter außer Kraft gesetzt werden, aber es gibt Fälle, bei denen zwei oder mehr
Module beide das gleiche Gerät unterstützen oder ein Modul fälschlicherweise behauptet, ein Gerät zu
unterstützen: das Schlüsselwort blacklist zeigt an, dass alle internen Aliase des bestimmten Moduls
ignoriert werden sollen.
install Modulname Befehl…
Dieser Befehl weist modprobe(8) an, den Befehl auszuführen anstatt das Modul normal in den Kernel
einzufügen. Dieser Befehl kann jeder Shell-Befehl sein: dies ermöglicht Ihnen eine beliebig komplexe
Verarbeitung. Falls beispielsweise das Modul »fred« besser funktioniert, wenn das Modul »barney«
bereits installiert ist (es hängt nicht von ihm ab, daher wird modprobe(8) es nicht automatisch
installieren), könnten Sie »install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred«
angeben, womit das gewünschte passiert. Beachten Sie das --ignore-install, was das zweite modprobe(8)
daran hindert, den gleichen install-Befehl erneut auszuführen. Siehe auch remove weiter unten.
Langfristig ist die Zukunft dieses Befehls als Lösung des Problems, zusätzliche Modulabhängigkeiten
bereitzustellen, nicht sichergestellt. Es wird geplant, diesen Befehl in einer zukünftigen
Veröffentlichung durch eine Warnung zu ersetzen, dass er als veraltet anzusehen sei und
voraussichtlich entfernt werde. Seine Verwendung kompliziert die automatische Bestimmung von
Modulabhängigkeiten durch Distributions-Hilfswerkzeuge wie mkinitrd (da diese derzeit irgendwie
auswerten müssen, was der Befehl install tun könnte). In einer perfekten Welt würden Module alle
Abhängigkeitsinformationen ohne den Einsatz dieses Befehls bereitstellen und es laufen Arbeiten, um
schwache Abhängigkeiten innerhalb des Linux-Kernels zu unterstützen.
Falls Sie die Zeichenkette »$CMDLINE_OPTS« in dem Befehl verwenden, wird sie durch alle auf der
modprobe(8)-Befehlszeile angegebenen Optionen ersetzt. Dies kann nützlich sein, da Benutzer von
»modprobe fred opt=1« erwarten, dass das Argument »opt=1« an das Modul übergeben wird, selbst wenn es
einen Installationsbefehl in der Konfigurationsdatei gibt. Daher wird unser obiges Beispiel zu
»install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred $CMDLINE_OPTS«.
options Modulname Option…
Dieser Befehl erlaubt es Ihnen, jedes Mal beim Einfügen in den Kernel Optionen zu dem Modulnamen (der
ein Alias sein könnte) hinzuzufügen: ob direkt (mittels modprobe Modulname) oder da das eingefügte
Modul von diesem Modul abhängt.
Alle Optionen werden zusammengefügt: sie können von einer Option für das Modul selbst, für einen
Alias oder auf der Befehlszeile kommen.
remove Modulname Befehl…
Dies ist ähnlich zum obigen Befehl install, außer dass es bei der Ausführung von »modprobe -r«
aufgerufen wird.
softdep Modulname pre: Module… post: Module…
Der Befehl softdep erlaubt es Ihnen, schwache oder optionale Modulabhängigkeiten festzulegen.
Modulname kann verwandt werden, ohne dass diese optionalen Module installiert sind, aber
normalerweise fehlen dann Funktionalitäten. Beispielsweise könnte ein Treiber für ein Speicher-HBA
das Laden eines anderen Modules benötigen, um die Verwaltungsfunktionalitäten zu verwenden.
pre-deps- und post-deps-Module sind Listen von Namen und/oder Aliase von anderen Modulen, die
modprobe(8) vor oder nach dem im angegebenen Hauptmodul Modulname zu installieren (oder entfernen)
versucht.
Beispiel: Sei »softdep c pre: a b post: d e« in der Konfiguration bereitgestellt. Die Ausführung von
»modprobe c« ist jetzt äquivalent zu »modprobe a b c d e« ohne die schwache Abhängigkeit. Schalter
wie --use-blacklist werden auf alle angegebenen Module angewandt, während Modulparameter nur auf das
Modul c angewandt werden.
Hinweis: Falls es install- oder remove-Befehle mit dem gleichen Modulname-Argument gibt, hat softdep
Vorrang.
weakdep Modulname Module…
Der Befehl weakdep erlaubt Ihnen die Angabe schwacher Modulabhängigkeiten. Diese sind ähnlich zu »pre
softdep«, mit dem Unterschied, dass der Anwendungsraum nicht versucht, die Abhängigkeit vor dem
angegebenen Modul zu laden.. Stattdessen kann der Kernel eines oder mehrere von ihnen während der
Modulprüfung anfragen, abhängig von der Hardware, an die angebunden wird. Der Zweck der schwachen
Abhängigkeit ist es, einem Treiber zu erlauben, dass eine bestimmte Abhängigkeit benötigt werden
könnte, so dass diese im Dateisystem vorhanden ist (z.B. in einer Initramfs), wenn das Modul geprüft
wird.
Beispiel: Sei »weakdep c a b«. Ein Programm, das eine Initramfs erstellt, weiß, dass es a, b und c zu
dem Dateisystem hinzufügen soll, da zur Laufzeit a und b benötigt/erwünscht sind. Wenn c geladen wird
und die Prüfung erfolgt, könnte es Aufrufe an request_module() erteilen, wodurch a oder b auch
geladen werden.
KOMPATIBILITÄT
Eine zukünftige Version von kmod(8) wird eine ausdrücklichen Warnung ausgeben, um die Verwendung von
install zu vermeiden (wie oben beschrieben). Dies passiert, sobald die Unterstützung für schwache
Abhängigkeiten im Kernel vollständig ist. Die Unterstützung wird die bestehende Softdep-Unterstützung
innerhalb dieses Hilfswerkzeuges ergänzen, indem es solche Abhängigkeiten direkt innerhalb von Modulen
bereitstellt.
COPYRIGHT
Das Urheberrecht für diese Seite war ursprünglich © 2004 Rusty Russell, IBM Corporation.
SIEHE AUCH
modprobe(8), modules.dep(5)
FEHLER
Bitte leiten Sie alle Fehlerberichte (auf Englisch) an die Fehlerdatenbank von kmod unter
https://github.com/kmod-project/kmod/issues/ zusammen mit der verwandten Version, Schritten zum
Nachvollziehen des Problems und dem erwarten Ergebnis weiter.
AUTOREN
Eine Vielzahl von Beiträgen kamen von der Linux-Modules-Mailingliste <linux-modules@vger.kernel.org> und
Github. Falls Sie einen Klon von kmod.git selbst haben, kann Ihnen die Ausgabe von git-shortlog(1) und
git-blame(1) die Autoren für bestimmte Teile des Projekts darstellen.
Lucas De Marchi <lucas.de.marchi@gmail.com> ist der aktuelle Betreuer des Projekts.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.
kmod 25. April 2025 MODPROBE.D(5)