Modprobe

Aus
Version vom 18. August 2011, 21:13 Uhr von Mahgue (Diskussion | Beiträge) (modprobe howto)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

Wozu modprobe ?

Module für den Kern des Betriebssystems (Dateien mit *.ko) sind Dateien mit binärem Code der zur Laufzeit mit dem bereits laufenden Code des Kerns verbunden (linked) werden kann. Dabei werden neue Funktionen zur Verfügung gestellt die entweder direkt von Applikationen genutzt werden können oder wieder von anderen Modulen. Verwendet ein Modul Funktionen eines anderen so kann es nur geladen werden wenn das andere Modul bereits geladen und initialisiert ist. Das führt dazu das manche Module einen ganze Baum von anderen Modulen benötigen. Mit Änderungen an den Modulen können sich auch die Abhängigkeiten verändern. Das Tool modprobe sorgt beim Laden eines Moduls dafür dass alle Module von denen das zu ladende Module direkt oder indirekt abhängig ist vorher in der richtigen Reihenfolge auch geladen werden. Später kann man das Modul auch wieder mit modprobe -r entfernen und das Tool sogt dafür das danach nicht mehr benötigte Module ebenfalls in der passenden Reihenfolge entfernt werden. Es ist keine Gute Idee derartige Ketten von insmod Aufrufen explizit in Scripte zu schreiben. Mit dem nächsten Kernel- oder auch nur Modul-Update kann sich das schon wieder ändern.

Auf großen Systemen ist modprobe selbstverständlich von Anfang an mit installiert. Auf Embedded-Systemen lohnt sich das erst bei komplexeren Setups. Auf unserer Diskstation lohnt es sich erst wenn man mit IPKG installierten Diensten arbeitet die mehr als ein Modul benötigen.

Vorbereitung

Es muss ipkg installiert sein. Damit modprobe die Abhängigkeiten analysieren kann müssen sie erst mal bestimmt werden. Dazu gibt es depmod. Es liest alle Module und deren Symbole durch und erstellt eine Datei aus der modprobe die Abhängigkeiten lesen kann. Gibt man einfach depmod ein erhält man erst mal einen Fehlermeldung:

depmod
WARNING: Couldn't open directory /opt/lib/modules/2.6.15: No such file or directory
FATAL: Could not open /opt/lib/modules/2.6.15/modules.dep.temp for writing: No such file or directory

Als Optware-Tool erwartet depmod die Module in /opt/lib/modules und dort wie bei den großen Systemen in einem Verzeichnis das den Namen der laufenden Kern-Release hat. Auf der Diskstation liegen die Module aber unabhängig von der Kern-Version in /lib/modules. Da wir auf der Diskstation nicht ständig mehrere Kerne vorhalten oder austauschen lösen wir das ganze hier etwas unsauber aber schnell mit einem symbolischen Link.

mkdir /opt/lib/modules
ln -s /lib/modules /opt/lib/modules/$(uname -r)
depmod

Jetzt ist in /opt/lib/modules ein symbolischer Link der so heißt wie die Release des Kerns und auf /lib/modules verweist. Damit ist depmod zufrieden und erzeugt dort die Datei modules.dep. Damit sollte modprobe jetzt auch laufen.

Testen

Einfach mal ein Modul laden das Abhängigkeiten hat. Versuchen wir es mit insmod so wird es scheitern.

insmod iptable_nat.ko
insmod: error inserting 'iptable_nat.ko': -1 Unknown symbol in module

Versuchen wir es mit modprobe werden die nötigen drei anderen Module einfach vorher auch geladen.

modprobe iptable_nat
lsmod | grep iptable_nat
iptable_nat             6564  0 
ip_nat                 16370  1 iptable_nat
ip_tables              19840  1 iptable_nat
ip_conntrack           46000  2 iptable_nat,ip_nat

Würden wir das Modul mit rmmod wieder entfernen würden die anderen nutzlos im Speicher liegen bleiben. Machen wir es mit modprobe -r wird alles wieder korrekt aufgeräumt.

modprobe -r iptable_nat
lsmod | grep ip

Dieser Mechanismus ist vor allem für ordentliche mit start- und stop-Option versehene Optware-Scripte sehr praktisch. Siehe z.B. das Start-Script für openvpn mit NAT.