Scroll to navigation

MODPROBE.D(5) modprobe.d MODPROBE.D(5)

NAZWA

modprobe.d - katalog konfiguracji modprobe

SKŁADNIA

/etc/modprobe.d/*.conf

/run/modprobe.d/*.conf

/usr/local/lib/modprobe.d/*.conf

/usr/lib/modprobe.d/*.conf

/lib/modprobe.d/*.conf

OPIS

Ze względu na zależności między modułami, polecenie modprobe może dodawać lub usuwać więcej niż pojedynczy moduł, zatem potrzebna jest metoda podawania opcji, jakie mają być używane z tymi modułami. Można w ten sposób także tworzyć wygodne aliasy: czyli alternatywne nazwy dla modułów lub zupełnie przesłaniać zwykłe zachowanie modprobe w przypadku specjalnych wymagań (np. dodawania więcej niż jednego modułu).

Proszę zwrócić uwagę, że nazwy aliasów i modułów (podobnie jak inne nazwy modułów) mogą zawierać znaki - lub _: oba można stosować zamiennie we wszystkich poleceniach związanych z modułami, ponieważ konwersja znaków podkreślenia następuje automatycznie.

FORMAT KONFIGURACJI

Pliki konfiguracyjne zawierają po jednym poleceniu na wiersz, przy czym puste wiersze oraz wiersze zaczynające się od „#” są ignorowane (przydatne do dodawania komentarzy). Znak „\” na końcu wiersza powoduje, że następny wiersz staje się kontynuacją poprzedniego, co czyni pliki nieco czytelniejszymi.

Więcej informacji w poniższym rozdziale POLECENIA.

KATALOGI KONFIGURACJI I PIERWSZEŃSTWO

Pliki konfiguracyjne są odczytywane z katalogów wyszczególnionych w SKŁADNI, w tej kolejności. Po załadowaniu pliku o danej nazwie, pliki o tej samej nazwie z kolejnych katalogów są ignorowane.

Wszystkie pliki konfiguracyjne są sortowane w kolejności leksykograficznej, niezależnie od katalogu, z jakiego pochodzą. Pliki konfiguracyjne mogą być albo zupełnie zastąpione (przez nowy plik konfiguracyjny, o tej samej nazwie, w katalogu o wyższym priorytecie) albo częściowo zastąpione (przez plik konfiguracyjny dalszy w kolejności).

UWAGA: Katalogi konfiguracyjne można zmienić zmienną środowiskową MODPROBE_OPTIONS. Więcej informacji w rozdziale ŚRODOWISKO w podręczniku modprobe(8).

POLECENIA

alias wieloznacznik nazwa-modułu

Pozwala nadać modułowi alternatywną nazwę. Przykładowo „alias moj-mod naprawde-dluga-nazwa-modulu” oznacza, że można używać „modprobe moj-mod” zamiast „modprobe naprawde-dluga-nazwa-modulu”. Można też korzystać z wieloznaczników powłoki, zatem „alias moj-mod* naprawde-dluga-nazwa-modulu” oznacza, że „modprobe moj-mod-costam” również zadziała. Nie można tworzyć aliasów do innych aliasów (to prowadziłoby do szaleństwa), ale aliasy mogą posiadać opcje, które zostaną dodane do wszelkich innych opcji.

Moduły mogą zawierać swoje własne aliasy, które można poznać poleceniem modinfo. Aliasy te są używane w ostatniej kolejności (tj. jeśli nie ma rzeczywistego modułu o takiej nazwie, ani w konfiguracji nie ma polecenia install, remove lub alias).

blacklist nazwa-modułu

Moduły mogą zawierać swoje własne aliasy: zwykle są to aliasy opisujące obsługiwane urządzenia, np. „pci:123...”. Te „wewnętrzne” aliasy można przesłonić zwykłymi słowami kluczowymi „alias”, ale niekiedy zdarza się, że dwa lub więcej modułów obsługuje te same urządzenia albo moduł nieprawidłowo zgłasza obsługę urządzenia, którego nie obsługuje: słowo kluczowe blacklist wskazuje, że wszystkie wewnętrzne aliasy danego modułu należy zignorować.

install nazwa-modułu polecenie...

Polecenie instruuje modprobe, aby uruchomiło podane polecenie zamiast umieszczać moduł w jądrze w zwykły sposób. Polecenie to może być dowolnym poleceniem powłoki: w ten sposób można dokonać dowolnie skomplikowanego przetwarzania. Przykładowo, jeśli moduł „fred” działa lepiej z już zainstalowanym modułem „barney” (ale nie jest od niego zależny, więc modprobe nie załaduje go automatycznie), można podać „install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred”, co da oczekiwany efekt. Proszę odnotować --ignore-install, które powstrzymuje drugi przebieg modprobe od ponownego uruchomienia tego samego polecenia install. Zob. też remove poniżej.

Długoterminowa przyszłość tego polecenia jako rozwiązania problemów z zapewnianiem dodatkowych zależności modułom nie jest pewna; planuje się jego zastąpienie ostrzeżeniem o przyszłym usunięciu lub uznaniu za przestarzałe w którymś z przyszłych wydań. Obecność polecenia komplikuje automatyczne określanie zależności modułów przez narzędzia dystrybucji takie jak mkinitrd (ponieważ wymaga jakiejś interpretacji tego, co może robić polecenie install). W idealnym świecie moduły zapewniałyby wszelkie informacje o zależnościach bez niniejszego polecenia i trwają prace nad implementacją obsługi miękkich zależności w jądrze Linux.

Jeśli w poleceniu użyje się łańcucha „$CMDLINE_OPTS”, zostanie on zastąpiony opcjami podanymi w wierszu polecenia modprobe. Może być to przydatne, ponieważ użytkownicy oczekują, że „modprobe fred opt=1” przekaże argument „opt=1” do modułu nawet, jeśli w pliku konfiguracyjnym występuje polecenie install. Tak więc powyższy przykład przyjmie w ten sposób postać: „install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred $CMDLINE_OPTS”.

options nazwa-modułu opcja...

Polecenie to pozwala dodawać opcje do modułu nazwa-modułu (które może być aliasem) za każdym razem, gdy zostanie on dodany do jądra: bezpośrednio (za pomocą modprobe nazwa-modułu) lub ze względu na zależność innego dodawanego modułu.

Wszystkie opcje są dodawane razem: mogą pochodzić z opcji option samego modułu, jego aliasu oraz z wiersza polecenia.

remove nazwa-modułu polecenie...

Podobne do powyższego polecenia install, tyle że wywoływane przy uruchomieniu polecenia „modprobe -r”.

softdep nazwa-modułu pre: moduły... post: moduły...

Polecenie softdep pozwala zdefiniować zależności miękkie (opcjonalne). Moduł nazwa-modułu może być używany bez instalacji tych opcjonalnych modułów, ale zwykle nie będzie wówczas w pełni funkcjonalny. Na przykład sterownik adaptera HBA może wymagać załadowania innego modułu, aby korzystać z funkcji zarządzania przestrzenią dyskową.

Po pre i post następują listy nazw i/lub aliasów innych modułów, które modprobe spróbuje zainstalować (lub usunąć), w zadanej kolejności, przed (pre) i po (post) głównym module podanym w argumencie nazwa-modułu.

Przykład: W konfiguracji zapisano polecenie „softdep c pre: a b post: d e”. Uruchomienie „modprobe c” staje się teraz równoważne „modprobe a b c d e” bez softdep. Opcje takie jak --use-blacklist są stosowane do wszystkich podanych modułów, natomiast parametry modułów - tylko do modułu c.

Uwaga: jeśli z tym samym argumentem nazwa-modułu występują też polecenia install lub remove, softdep ma pierwszeństwo.

weakdep nazwa-modułu moduły...

Polecenie weakdep pozwala na zdefiniowanie słabych zależności modułów. Są podobne do zależności miękkich typu pre z tą różnicą, że przestrzeń użytkownika nie próbuje załadować tej zależności przed podanym modułem. Jądro może zażądać jednego lub kilku z nich w trakcie sondowania modułu, w zależności od przypisań sprzętowych. Przeznaczeniem zależności słabych jest możliwość zdefiniowania przez sterownik, że określona zależność może być potrzebna, zatem powinna być obecna w systemie plików (np. w initramfs) gdy moduł jest sondowany.

Przykład: Zdefiniowano „weakdep c a b”. Program tworzący initramfs wie o tym, że powinien dodać a, b i c do systemu plików, ponieważ a i b mogą być wymagane/oczekiwane w trakcie rozruchu. Gdy c jest ładowany i sondowany, może wywołać request_module(), powodując załadowanie również a lub b.

ZGODNOŚĆ

Przyszła wersja kmod będzie zawierała wyraźne ostrzeżenie o konieczności unikania korzystania z install, jak wyjaśniono powyżej. Stanie się tak po ukończeniu pełnej obsługi zależności miękkich w jądrze. W ramach tego, istniejąca obsługa za pośrednictwem niniejszego narzędzia zostanie uzupełniona przez zapewnianie takich zależności bezpośrednio z modułów.

PRAWA AUTORSKIE

Pierwotne autorstwo niniejszego podręcznika systemowego: Copyright 2004, Rusty Russell, IBM Corporation.

ZOBACZ TAKŻE

modprobe(8), modules.dep(5)

USTERKI

Zgłoszeń błędów prosimy dokonywać w systemie śledzenia błędów pod adresem https://github.com/kmod-project/kmod/issues/, wraz z informacją o wersji programu, krokach potrzebnych do odtworzenia problemu oraz oczekiwanym rezultacie.

AUTORZY

Wielu współautorów pochodzi z listy dyskusyjnej linux-modules pod adresem <linux-modules@vger.kernel.org> oraz z Githuba. Mając sklonowane repozytorium kmod.git, wynik polecenia git-shortlog(1) i git-blame(1) ukaże autorów danej części projektu.

Projektem opiekuje się aktualnie Lucas De Marchi <lucas.de.marchi@gmail.com>.

TŁUMACZENIE

Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net.

25 kwietnia 2025 r. kmod