MODPROBE.D(5)

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 (https://www.gnu.org/licenses/gpl-3.0.html) 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).