Fix “Failed to Start Load Kernel Modules” on SLES Boot

The SLES boot message “Failed to Start Load Kernel Modules” usually means systemd-modules-load.service tried to load at least one kernel module and one request failed. The useful goal is not merely to hide the red boot line. A good repair leaves the service healthy, removes stale module requests, preserves any driver the machine actually needs, and survives the next reboot.

This guide is written for SUSE Linux Enterprise Server 15 and is aligned with the current SLES 15 SP7 Administration Guide. SUSE documents that systemd-modules-load.service loads modules named in /etc/modules-load.d/*.conf, while most modern hardware modules are normally loaded automatically when devices are detected. That distinction matters: if a stale static entry points to a module that no longer exists, deleting or correcting that entry is often safer than forcing an obsolete driver back into the system. See SUSE's Managing kernel modules documentation for SLES 15 SP7.

What a successful fix should look like

Before changing anything, define the result you want. After the repair:

• systemctl status systemd-modules-load.service should no longer report a failed result.
• The journal should no longer show the same module-load error during a fresh boot.
• If the module is genuinely required, modprobe MODULE_NAME should succeed and the related hardware or feature should work.
• If the module is obsolete, the stale request should be removed rather than replaced with an unrelated module.
• If the problem is tied to early boot, the initramfs should be rebuilt and the machine should complete a reboot normally.

If those checks do not all apply to your situation, use the ones that match the failing component. For example, a server can boot successfully even while an optional module fails. That is still worth cleaning up, but it is different from a missing storage driver that prevents the root file system from appearing.

Step 1: Confirm the failed unit and capture the exact module error

Start with the service itself instead of guessing from the splash-screen message:

sudo systemctl status systemd-modules-load.service --no-pager

Look for a module name and an error such as Module ... not found, No such device, Operation not permitted, or a message that an unsupported module was refused. The exact wording determines the next action.

If the status output is truncated, do not edit configuration yet. Get the complete boot log first.

Step 2: Read the boot journal before changing module files

Query only this service for the current boot:

sudo journalctl -b -u systemd-modules-load.service --no-pager

You can also inspect kernel messages around module loading:

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

Der erste Befehl gibt Auskunft darüber , welche statische Ladeanforderung fehlgeschlagen ist . Das Kernel-Protokoll kann zusätzlichen Kontext liefern, z. B. einen Treiber, der das erkannte Gerät ablehnt, eine Firmware-Abhängigkeit, Signaturprobleme oder einen anderen Fehler auf niedrigerer Ebene.

Ein solches Ergebnis Module foo not found in directory /lib/modules/...deutet in der Regel auf eine veraltete Konfiguration, eine Kernel-/Paketinkompatibilität oder einen Drittanbietertreiber hin, der nicht für den aktiven Kernel neu kompiliert wurde. No such deviceAnders verhält es sich hier: Die Moduldatei kann zwar vorhanden sein, aber die aktuelle Hardware oder das virtuelle Gerät entspricht möglicherweise nicht den Erwartungen des Treibers.

Schritt 3: Ermitteln Sie, wer SLES auffordert, dieses Modul zu laden.

Suchen Sie die normalen Speicherorte für statische Lasten und die modprobe-Konfiguration:

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Ersetzen Sie dies MODULE_NAMEdurch den Namen aus dem Journal. Unter SLES 15 SP7 sind lokale Einträge in `modules-load.d` /etc/modules-load.d/der standardmäßige, vom Administrator verwaltete Ort für Module, die beim Systemstart geladen werden müssen, während Paket-Einträge unter `modules-load.d` vorhanden sein können /usr/lib/modules-load.d/. SUSE weist darauf hin, dass die meisten Module überhaupt keinen manuellen Eintrag in `modules-load.d` benötigen.

Prüfen Sie anschließend, ob der aktive Kernel das Modul tatsächlich enthält:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Wenn das Modul veraltet ist

Entfernen oder deaktivieren Sie die lokale Datei, die diese anfordert. Löschen Sie keine Herstellerdatei, /usr/libnur um den Fehler zu unterdrücken, da Paketaktualisierungen sie wiederherstellen können. Falls Sie feststellen, dass eine lokale /etc/modules-load.d/*.confDatei für veraltete Hardware oder Software erstellt wurde, entfernen Sie diesen Eintrag und testen Sie erneut.

Wenn das Modul existieren sollte, modinfo es aber nicht finden kann

Prüfen Sie, ob der laufende Kernel mit dem installierten Modulbaum übereinstimmt:

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

Eine gängige Qualitätsprüfung ist einfach: /lib/modules/$(uname -r)Die benötigten Module für den aktuell laufenden Kernel müssen vorhanden sein. Wurde ein Drittanbietertreiber für einen älteren Kernel kompiliert, installieren oder kompilieren Sie diesen Treiber mit dem aktuellen SLES-Kernel gemäß der vom Hersteller bereitgestellten Vorgehensweise neu. Vermeiden Sie es, .koDateien aus einer anderen Kernelversion zu kopieren, nur um modprobeetwas zu finden; Unterschiede in der Kernel-ABI oder -Signatur können dies unsicher oder wirkungslos machen.

Wenn das Modul auf der Blacklist steht

Suche nach einer Blacklist oder installiere eine Überschreibung:

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

Eine Blacklist sollte erst entfernt werden, nachdem der Grund für ihre Hinzufügung geklärt ist. Eine Blacklist kann das System vor inkompatiblen Treibern schützen. Die Moduldokumentation von SUSE beschreibt sowohl permanente als auch temporäre Blacklisting-Einträge, die während der GRUB-Zeit erstellt werden. Daher kann es sinnvoll sein, die statische Ladeanforderung zu entfernen, anstatt die Blacklist selbst.

Wenn SLES ein nicht unterstütztes Modul meldet

Aktivieren Sie nicht automatisch das Laden nicht unterstützter Module. SLES kennzeichnet Kernelmodule hinsichtlich ihres Supportstatus. Das Erzwingen des Ladens eines nicht unterstützten Moduls kann die Supportfähigkeit beeinträchtigen. SUSE dokumentiert den Ausnahmemechanismus für Tests oder Hotfixes von Herstellern in seinem Administrationshandbuch. Verwenden Sie ihn nur, wenn Sie die Auswirkungen auf den Support verstehen und eine berechtigte Treiberanforderung haben. Das aktuelle SUSE-Handbuch finden Sie unter SLES 15 SP7 Administration Guide .

Schritt 4: Initramfs nur dann neu erstellen, wenn die Änderung den frühen Systemstart betrifft.

Falls das fehlerhafte Modul innerhalb der initramfs benötigt wird oder Sie eine für den Bootvorgang kritische Treiber- oder Blacklist-Konfiguration geändert haben, die sich dort widerspiegeln muss, generieren Sie das Image neu:

sudo dracut -f

SUSE dokumentiert detailliert den Neuaufbau der initramfs nach Treiberänderungen, die den Bootvorgang beeinflussen. Die aktuelle Anleitung zum Bootvorgang erklärt, wann Treiber zur initramfs hinzugefügt werden müssen und wie dracutdiese neu generiert wird: Einführung in den Bootvorgang in SLES 15 SP7 .

Führen Sie diesen Vorgang nicht dracut -froutinemäßig bei jedem Fehler in optionalen Modulen aus. Wenn ein gewöhnliches Post-Boot-Modul lediglich in /etc/modules-load.dder Datei `/etc/initramfs` aufgeführt ist, kann die Korrektur dieser Datei ausreichend sein. Der Neuaufbau von `initramfs` ist vor allem dann relevant, wenn die fehlerhafte Konfiguration im Boot-Image eingebettet ist oder der benötigte Treiber verfügbar sein muss, bevor das eigentliche Root-Dateisystem vollständig eingebunden wird.

Prüfen Sie die Reparatur, bevor Sie den Vorfall als abgeschlossen betrachten.

Erster Test ohne Neustart, sobald dies gefahrlos möglich ist:

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

Falls das benötigte Modul nun geladen werden sollte, bestätigen Sie dies bitte:

lsmod | grep -w MODULE_NAME

Starten Sie das System anschließend während eines geeigneten Wartungsfensters neu und überprüfen Sie den neuen Startvorgang:

sudo reboot

Nach dem Einloggen:

systemctl --failed
journalctl -b -u systemd-modules-load.service --no-pager

Das stärkste Erfolgssignal ist nicht, dass die Konsolenmeldung einmalig verschwunden ist. Es ist vielmehr, dass nach einem Neustart derselbe Modulfehler nicht erneut auftritt und die Hardware oder das Subsystem, das von dem Modul abhängt, weiterhin funktioniert.

Wann sollte man den Ansatz ändern?

Grenzen dieser Lösung

Die Meldung „Fehler beim Laden der Kernelmodule“ ist ein Symptom, kein eigenständiger Fehler. Dieses Verfahren behebt Fehler, die durch statische Modulanforderungen, fehlende oder nicht übereinstimmende Module, Blacklists und die Synchronisierung von initramfs verursacht werden. Es ersetzt jedoch weder die Hardware-Diagnose noch die Unterstützung von Drittanbietertreibern, die Signierung von Secure Boot oder die Datenwiederherstellung, wenn das Root-Gerät selbst nicht verfügbar ist.

Bei produktiven SLES-Systemen ist die Supportfähigkeit zu gewährleisten: Verwenden Sie vorzugsweise das für Ihren SLES-Kernel bereitgestellte Modul, achten Sie darauf, dass Drittanbietertreiber mit der Supportmatrix des jeweiligen Herstellers übereinstimmen, und nutzen Sie die von SUSE dokumentierten Mechanismen, anstatt Prüfungen zu umgehen, nur um einen Dienstausfall zu beheben. Die Reparatur ist abgeschlossen, wenn der Dienststatus, das Boot-Journal und die abhängige Hardware übereinstimmend bestätigen, dass das Problem behoben ist.