Kernel-Module unter Linux verwalten: lsmod, modprobe und Co.

1. Was Kernel-Module sind und warum sie zaehlen

Ein Kernel-Modul ist ein Stueck Code, das zur Laufzeit in den laufenden Linux-Kernel geladen oder aus ihm entfernt werden kann, ohne dass ein Neustart noetig ist. Treiber fuer Netzwerkkarten, Dateisystemtreiber wie XFS oder Btrfs, Firewall-Backends wie nf_tables oder virtuelle Geraete wie das Loopback-Device werden fast immer als Kernel-Module ausgeliefert statt fest in den Kernel einkompiliert zu sein. Das reduziert die Groesse des laufenden Kernels im Speicher, weil nur die tatsaechlich benoetigten Subsysteme geladen sind, und erlaubt es Distributionen, einen einzigen Kernel fuer sehr unterschiedliche Hardware auszuliefern.

Fuer Systemadministratoren sind Kernel-Module vor allem deshalb relevant, weil sie eine der ersten Anlaufstellen bei Hardware- und Netzwerkproblemen sind. Fehlt ein Treiber fuer eine RAID-Controller-Karte, laedt der Kernel das passende Modul nicht automatisch, und die Platten bleiben unsichtbar. Ist ein Kernel-Modul fehlerhaft konfiguriert, kann es Kernel-Panics ausloesen oder Netzwerkschnittstellen in einen inkonsistenten Zustand versetzen. Die Werkzeuge lsmod, modinfo und modprobe bilden zusammen das Standard-Set, mit dem sich der Modul-Zustand eines Systems vollstaendig nachvollziehen und gezielt veraendern laesst.

2. lsmod: geladene Kernel-Module auflisten und verstehen

Der Befehl lsmod liest die Datei /proc/modules aus und zeigt in einer formatierten Tabelle jedes aktuell geladene Kernel-Modul mit drei Spalten an: Name, Groesse in Bytes und Nutzungszaehler mit den Namen der Module, die von ihm abhaengen. Ein Modul mit Nutzungszaehler 0 ist zwar geladen, wird aber von keinem anderen Modul und keinem laufenden Prozess mehr referenziert, was es zu einem Kandidaten fuer das Entladen macht. Ein Nutzungszaehler groesser als 0 bedeutet, dass ein Entladeversuch mit rmmod fehlschlaegt, solange die Abhaengigkeit besteht.

In der Praxis kombiniert man lsmod fast immer mit grep, um gezielt nach einem bestimmten Treiber oder Subsystem zu suchen, etwa bei der Frage, ob das Kernel-Modul fuer eine bestimmte Netzwerkkarte oder ein Dateisystem ueberhaupt geladen ist. Da lsmod lediglich eine lesbare Formatierung von /proc/modules liefert, laesst sich derselbe Zustand auch direkt ueber cat /proc/modules abrufen, was in Skripten ohne lsmod-Abhaengigkeit nuetzlich ist. Der Output ist deterministisch und eignet sich gut fuer Monitoring-Checks, die pruefen, ob ein sicherheitsrelevantes Modul wie overlay fuer Container ueberhaupt aktiv ist.

# List all currently loaded kernel modules
lsmod

# Typical output columns: Module, Size, Used by
# Module                  Size  Used by
# nf_tables             172032  10 nft_ct,nft_chain_nat,...
# xt_conntrack           16384  1
# ip6table_filter        16384  1
# xfs                  2072576  1

# Search for a specific driver or subsystem
lsmod | grep -i xfs

# Check whether the overlay filesystem module (used by Docker) is loaded
lsmod | grep overlay

# Same information without lsmod, straight from the proc filesystem
cat /proc/modules | column -t

# Count how many modules are currently loaded
lsmod | tail -n +2 | wc -l

3. modinfo: Metadaten und Abhaengigkeiten pruefen

Waehrend lsmod nur zeigt, was gerade geladen ist, liefert modinfo detaillierte Metadaten zu einem beliebigen Kernel-Modul, unabhaengig davon, ob es aktuell geladen ist. Dazu gehoeren der Dateipfad im Modul-Verzeichnisbaum unter /lib/modules/$(uname -r), die Lizenz, der Autor, eine Kurzbeschreibung, die Liste der Abhaengigkeiten (depends) und alle Parameter, die das Modul beim Laden akzeptiert. Diese Parameterliste ist besonders wichtig, weil viele Treiber ihr Verhalten ueber Modul-Parameter steuern lassen, etwa das Debug-Level eines Netzwerktreibers oder die maximale Anzahl unterstuetzter Geraete.

Ein haeufiger Anwendungsfall in der Praxis: Vor dem Laden eines unbekannten Kernel-Moduls auf einem Produktivsystem prueft man mit modinfo zuerst, welche anderen Module als Voraussetzung geladen sein muessen, und ob das Modul signiert ist. Signierte Module sind bei aktivem Secure Boot Pflicht, unsignierte Module werden vom Kernel sonst mit einer Fehlermeldung abgelehnt. Die Ausgabe von modinfo -F depends liefert genau die Abhaengigkeitskette, die modprobe anschliessend automatisch aufloest.

# Show full metadata for a module, whether loaded or not
modinfo xfs

# Typical fields returned:
# filename:       /lib/modules/6.8.0-generic/kernel/fs/xfs/xfs.ko
# license:        GPL
# description:    SGI XFS with ACLs, security attributes...
# depends:        libcrc32c
# retpoline:      Y
# intree:         Y
# signature:      (signed, appended)

# Query a single field, useful in scripts
modinfo -F depends xfs
modinfo -F version nf_tables

# List every parameter a module accepts
modinfo -p e1000e

# Check module signature status for Secure Boot compliance
modinfo -F signer nvidia 2>/dev/null || echo "module unsigned or not present"

4. modprobe: Kernel-Module laden und entladen mit Abhaengigkeitsaufloesung

Der zentrale Befehl fuer den Alltag ist modprobe, weil er im Gegensatz zu insmod automatisch alle Abhaengigkeiten eines Kernel-Moduls aufloest und in der richtigen Reihenfolge laedt. Ruft man modprobe nf_nat auf, sorgt modprobe dafuer, dass zuerst nf_conntrack geladen wird, falls es fehlt, weil nf_nat davon abhaengt. Diese Aufloesung basiert auf einer Datenbank, die aus den depends-Feldern aller Module im Verzeichnis /lib/modules/$(uname -r) generiert wird und mit depmod aktuell gehalten werden muss, insbesondere nach dem manuellen Kopieren neuer Modul-Dateien.

Zum Entladen dient modprobe -r, das ebenfalls rekursiv vorgeht: Alle Module, die durch das Laden automatisch mitgekommen sind und nun keinen anderen Verwender mehr haben, werden mit entfernt. Das unterscheidet sich deutlich von rmmod, das ausschliesslich das exakt angegebene Kernel-Modul entfernt und bei bestehenden Abhaengigkeiten mit einem Fehler abbricht. Fuer Testzwecke ist modprobe --dry-run -v hilfreich, weil es genau die Ladereihenfolge anzeigt, ohne tatsaechlich etwas zu veraendern.

# Load a module, resolving all dependencies automatically
modprobe nf_nat

# Dry run: show what WOULD be loaded, without changing anything
modprobe --dry-run -v nf_nat

# Load a module with custom parameters (not persisted across reboots here)
modprobe e1000e InterruptThrottleRate=3000

# Unload a module and every dependency no longer in use
modprobe -r nf_nat

# Rebuild the module dependency database after adding new module files
depmod -a

# Force a re-scan of module aliases (useful after driver package updates)
depmod -a "$(uname -r)"

5. insmod und rmmod: der direkte, risikoreichere Weg

insmod laedt ein Kernel-Modul direkt aus einer angegebenen .ko-Datei, ohne die Modul-Datenbank zu befragen und ohne Abhaengigkeiten selbst aufzuloesen. Fehlt eine Voraussetzung, meldet der Kernel einen Fehler wie Unknown symbol, und der Administrator muss die fehlenden Module manuell identifizieren und in der richtigen Reihenfolge selbst nachladen. Dieser Weg ist vor allem beim Testen selbst kompilierter Treiber relevant, etwa waehrend der Entwicklung eines eigenen Kernel-Moduls, bei dem das Modul noch nicht in /lib/modules installiert und in der depmod-Datenbank erfasst ist.

rmmod ist das Gegenstueck zum Entladen und funktioniert ebenfalls ohne automatische Aufloesung von Abhaengigkeiten. Ein Versuch, ein Kernel-Modul zu entfernen, das noch von einem anderen Modul referenziert wird, schlaegt mit der Fehlermeldung rmmod: ERROR: Module ... is in use fehl. In produktiven Umgebungen empfiehlt sich fast immer modprobe -r statt rmmod, weil die automatische Aufloesung Fehler durch vergessene Abhaengigkeiten vermeidet. insmod und rmmod bleiben dennoch wichtig, weil sie das genaue, kontrollierte Werkzeug fuer Situationen sind, in denen man exakt wissen will, was gerade passiert, etwa beim Debuggen eines fehlerhaften Modul-Ladevorgangs.

# Load a module directly from a .ko file (no dependency resolution)
sudo insmod /lib/modules/6.8.0-generic/kernel/drivers/net/dummy.ko

# If dependencies are missing, the kernel log shows something like:
# dummy: Unknown symbol register_netdevice (err -2)
# In that case, load the dependency first, then retry insmod

# Remove an exact module (fails if still referenced elsewhere)
sudo rmmod dummy

# Typical failure when dependencies still reference the module:
# rmmod: ERROR: Module nf_conntrack is in use by: nf_nat

# Force removal (dangerous, can destabilize the running kernel)
sudo rmmod -f some_module   # avoid on production systems

6. Kernel-Module beim Systemstart automatisch laden

Systemd bringt mit /etc/modules-load.d/ einen deklarativen Mechanismus mit, um bestimmte Kernel-Module bei jedem Boot automatisch zu laden. Jede Datei in diesem Verzeichnis mit der Endung .conf enthaelt eine Liste von Modulnamen, jeweils einer pro Zeile, und wird vom Dienst systemd-modules-load.service beim Systemstart abgearbeitet. Das ist der bevorzugte Weg gegenueber dem aelteren /etc/modules, das auf Systemen ohne systemd noch verwendet wird, aber weniger Struktur fuer mehrere Konfigurationsquellen bietet.

Ein typisches Beispiel aus dem Container-Umfeld: Damit Docker oder Podman zuverlaessig funktionieren, muessen die Kernel-Module overlay und br_netfilter geladen sein, letzteres insbesondere fuer korrektes Bridge-Netzwerk-Filtering mit iptables. Wird eines dieser Module nicht automatisch beim Boot geladen, funktionieren Container-Netzwerke inkonsistent, oft erst nach einem manuellen modprobe. Die Konfiguration ueber modules-load.d macht dieses Verhalten reproduzierbar und dokumentiert gleichzeitig, welche Module ein System bewusst benoetigt.

# /etc/modules-load.d/containers.conf
# Kernel modules loaded automatically at every boot via systemd-modules-load.service
overlay
br_netfilter

# /etc/modules-load.d/network.conf
# Bonding driver required for NIC teaming on this host
bonding

# Verify the service picked up the configuration after a reboot
# systemctl status systemd-modules-load.service
# journalctl -u systemd-modules-load.service --boot

7. Module blacklisten und Parameter dauerhaft setzen

Manchmal soll ein Kernel-Modul gerade nicht geladen werden, obwohl der Kernel es automatisch waehlen wuerde, etwa weil ein alternativer Treiber bevorzugt wird oder ein Modul bekannte Stabilitaetsprobleme mit bestimmter Hardware hat. Dafuer existiert das Blacklisting ueber Dateien in /etc/modprobe.d/ mit der Direktive blacklist modulname. Wichtig zu verstehen: Blacklisting verhindert nur das automatische Laden durch die Hardware-Erkennung (Udev-Aliase), nicht aber ein explizites modprobe modulname durch einen Administrator oder ein anderes Modul, das es als Abhaengigkeit anfordert.

Fuer Parameter, die dauerhaft und nicht nur fuer eine einzelne Sitzung gelten sollen, nutzt man dieselben /etc/modprobe.d/-Dateien mit der Direktive options modulname parameter=wert. Das ist der korrekte Ort fuer produktive Konfiguration, im Gegensatz zu Parametern, die direkt beim manuellen modprobe-Aufruf uebergeben werden und nach einem Reboot verloren gehen. Nach Aenderungen an /etc/modprobe.d/ muss in der Regel die initramfs neu gebaut werden (update-initramfs -u unter Debian/Ubuntu, dracut -f unter RHEL-basierten Systemen), damit auch fruehe Boot-Module die neue Konfiguration beruecksichtigen.

# /etc/modprobe.d/blacklist-nouveau.conf
# Prevent the open-source nouveau driver from loading automatically,
# because the proprietary NVIDIA driver should take over instead.
blacklist nouveau
options nouveau modeset=0

# /etc/modprobe.d/network-tuning.conf
# Persist a module parameter across reboots for a specific NIC driver
options e1000e InterruptThrottleRate=3000

# After changing files in /etc/modprobe.d/, rebuild the initramfs so early
# boot stages also respect the new configuration:
# update-initramfs -u          (Debian/Ubuntu)
# dracut -f                    (RHEL/CentOS/Fedora)

8. Fehlerdiagnose: wenn ein Kernel-Modul nicht laedt

Wenn ein erwartetes Kernel-Modul nicht laedt, ist der erste Schritt fast immer dmesg, gefiltert auf den Modulnamen. Der Kernel schreibt jeden Ladefehler mit einer konkreten Ursache in den Kernel-Ringpuffer, etwa fehlende Symbole, ein Versionsmismatch zwischen kompiliertem Modul und laufendem Kernel, oder eine fehlende Signatur bei aktivem Secure Boot. Zusaetzlich lohnt sich ein Blick in journalctl -k, das dieselben Kernel-Meldungen persistent ueber Boots hinweg speichert, waehrend dmesg ohne persistente Konfiguration nur den aktuellen Boot zeigt.

Ein zweiter haeufiger Fehler ist eine veraltete Modul-Datenbank nach einem Kernel-Update: Wurde ein neuer Kernel installiert, aber depmod nicht fuer die neue Version ausgefuehrt, findet modprobe das Kernel-Modul unter Umstaenden gar nicht, obwohl die Datei physisch vorhanden ist. Der Befehl modprobe --show-depends modulname zeigt die aufgeloeste Abhaengigkeitskette und macht sichtbar, an welcher Stelle die Aufloesung abbricht. Bei Modulen aus DKMS-Paketen (Dynamic Kernel Module Support) lohnt zusaetzlich ein Blick in /var/lib/dkms/, ob der Build fuer die aktuell laufende Kernel-Version ueberhaupt erfolgreich war.

# First stop for module load failures: filter kernel ring buffer
dmesg | grep -i -A2 modulename

# Persistent kernel log across boots (systemd-journald with persistent storage)
journalctl -k --boot | grep -i modulename

# Show the resolved dependency chain modprobe would use
modprobe --show-depends modulename

# Confirm the module file actually exists for the running kernel
find /lib/modules/"$(uname -r)" -name "modulename.ko*"

# Rebuild module dependencies after a kernel update
sudo depmod -a "$(uname -r)"

# For DKMS-built modules: check build status for the current kernel
dkms status

9. Kernel-Module-Werkzeuge im Vergleich

Jedes der beschriebenen Werkzeuge loest einen anderen Teil des Kernel-Modul-Lebenszyklus, und die Wahl des richtigen Werkzeugs entscheidet, ob eine Aenderung reproduzierbar und sicher ist oder nur fuer die aktuelle Sitzung gilt.

Fuer den taeglichen Betrieb heisst das: Diagnose immer mit lsmod und modinfo, aktive Aenderungen fast ausschliesslich mit modprobe, und dauerhafte Konfiguration ueber /etc/modules-load.d/ und /etc/modprobe.d/. insmod und rmmod bleiben Werkzeuge fuer gezielte Ausnahmefaelle und Kernel-Modul-Entwicklung, nicht fuer die Standardverwaltung produktiver Systeme.

10. Zusammenfassung

Der Umgang mit Kernel-Modulen ist eine der grundlegenden Faehigkeiten fuer die Linux-Systemadministration, weil fast jeder Treiber und viele Kernsubsysteme als ladbare Module implementiert sind. lsmod zeigt den aktuellen Zustand, modinfo liefert Metadaten und Abhaengigkeiten vor dem Laden, und modprobe ist das zentrale Werkzeug fuer sicheres Laden und Entladen mit automatischer Aufloesung von Abhaengigkeiten. insmod und rmmod bleiben fuer Sonderfaelle relevant, in denen die volle Kontrolle ohne automatische Aufloesung gebraucht wird.

Fuer produktive Systeme zaehlt vor allem die dauerhafte, dokumentierte Konfiguration ueber /etc/modules-load.d/ und /etc/modprobe.d/, statt Module manuell und ohne Nachvollziehbarkeit zu laden. Wer Fehler bei Kernel-Modulen diagnostizieren muss, startet fast immer mit dmesg und journalctl -k, ergaenzt durch eine aktuelle Modul-Datenbank via depmod -a. Diese Kombination aus Anzeige-, Lade- und Diagnosewerkzeugen deckt den kompletten Lebenszyklus eines Kernel-Moduls ab.

11. FAQ: Kernel-Module unter Linux verwalten