SLES-Bootmodul-Ladefehler: Treiber finden und beheben

Wenn SLES beim Systemstart die Meldung „Fehler beim Laden der Kernelmodule“ anzeigt, überprüfen Sie zunächst systemd-modules-load.servicedie Protokolle, um das fehlerhafte Modul zu identifizieren. Handelt es sich um einen veralteten optionalen Eintrag, entfernen Sie die entsprechende Anforderung aus der Konfiguration. Ist das Modul erforderlich, beheben Sie die Treiber- oder Kernel-Inkompatibilität, anstatt den Dienst zu deaktivieren.

Dieses Verfahren gilt für SUSE Linux Enterprise Server (SLES) 15 und verwendet die Administrationsdokumentation von SLES 15 SP7 als Referenz. Die Befehle sollten über eine lokale Konsole oder eine funktionierende SSH-Sitzung mit sudoZugriffsberechtigung ausgeführt werden.

Was die Nachricht bedeutet, bevor Sie etwas ändern

Ein Kernelmodul ist ein Treiber oder eine Kernelfunktion, die separat geladen werden kann. Beim Startvorgang systemd-modules-load.servicefordert der Prozess das Laden bestimmter Module an, einschließlich der in modules-load.dDateien definierten. Eine fehlgeschlagene Anfrage kann zum Ausfall des betreffenden Dienstes führen, selbst wenn andere Teile des Servers weiterhin funktionieren.

SUSE weist darauf hin, dass die meisten Treiber automatisch geladen werden, sobald Hardware erkannt wird. Eine manuelle Modulliste ist daher in der Regel nicht erforderlich. Ein veralteter Eintrag ist also durchaus möglich – die Bootmeldung allein beweist dies jedoch nicht. Stellen Sie den Konsolenzugriff sicher, erstellen Sie, falls verfügbar, einen System-Snapshot oder eine Konfigurationssicherung und deinstallieren Sie keine Speicher-, Netzwerk- oder Clustertreiber, nur um die Warnung zu beseitigen. Informationen zum unterstützten Modell finden Sie im SUSE -Handbuch zur Kernelmodulverwaltung .

Schritt 1: Lesen Sie den Dienststatus und das zugehörige Startprotokoll.

Beginnen Sie mit dem Status von systemd. systemd systemdist der Dienstmanager, der für das Starten von Diensten und das Melden ihres Status verantwortlich ist.

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

Das -bFlag beschränkt die Ausführung journalctlauf den aktuellen Systemstart und -uwählt diesen Dienst aus. Suchen Sie oberhalb der letzten Zeile „Fehlgeschlagen mit Ergebnis“ nach Meldungen wie „Modul nicht gefunden“, einer ungültigen Option oder einem Berechtigungs- oder Signaturfehler. Notieren Sie sich den genauen Modulnamen und den Fehlertext. Gehen Sie nicht davon aus, dass das im folgenden Beispiel genannte Modul auf Ihrem Server vorhanden ist.

Falls das Dienstprotokoll keine eindeutigen Ergebnisse liefert, überprüfen Sie die Kernelmeldungen auf weitere Details:

sudo journalctl -k -b --no-pager

Kann der Computer keine funktionierende Anmeldung erreichen, starten Sie einen älteren installierten Kernel über GRUB, sofern verfügbar, oder verwenden Sie SLES-Rettungsmedien. Bearbeiten Sie keine bootkritischen Module in einer ungetesteten Remote-Sitzung. SUSE dokumentiert Journalfilter im Kapitel zur Journalctl-Administration .

Schritt 2: Die Startkonfiguration finden, die dies anfordert.

Angenommen, die Zeitschriftennamen sind example_driver… Ersetzen Sie den Platzhalter durch den tatsächlichen Modulnamen und durchsuchen Sie dann die Modullisten:

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

Jede übereinstimmende Zeile gibt an, welche Datei das jeweilige Modul beim Systemstart anfordert. Die lokale Konfiguration eines Administrators befindet sich üblicherweise unter `/usr/local/config` /etc/modules-load.d/, während ein Paket seine Konfigurationsdatei unter `/usr/local/config` bereitstellen kann /usr/lib/modules-load.d/. Eine lokale Konfigurationsdatei mit demselben Basisnamen hat Vorrang vor der Herstellerdatei, wie im systemd-Konfigurationsleitfaden von SUSE beschrieben . Falls die Suche keine Ergebnisse liefert, prüfen Sie auch, cat /proc/cmdlineob Module beim Systemstart angefordert werden, und vergewissern Sie sich, dass der Fehlername korrekt kopiert wurde.

Öffnen Sie die entsprechende Datei und prüfen Sie, ob der Eintrag von der Hardware oder Anwendung noch benötigt wird. Ein Modul, das für ein altes, entferntes Gerät angefordert wird, unterscheidet sich von einem Speicherkontrollertreiber oder einem Cluster-Watchdog.

Schritt 3: Testen Sie das Modul und wenden Sie anschließend die passende Reparatur an.

Prüfen Sie, welcher Kernel ausgeführt wird und ob der Treiber dafür verfügbar ist. modprobeLädt Kernelmodule und löst Abhängigkeiten auf; die -nOption führt einen Testlauf durch, ohne einen Kernel einzufügen.

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

Ersetzen Sie erneut example_driver. Der Testlauf hilft, Such- oder Konfigurationsprobleme zu identifizieren, beweist aber nicht , dass ein Treiber auf Ihrer Hardware erfolgreich initialisiert wird oder die Secure-Boot-Signaturprüfungen besteht. SUSE empfiehlt die Verwendung von .de modprobeanstelle des direkten insmodLadens; Details zu den Testlauf-Flags finden Sie im modprobe-Handbuch .

Wenn ein veralteter optionaler Eintrag auf ein fehlendes Modul verweist

Sichern Sie die betreffende lokale Datei und kommentieren Sie nur die veraltete Zeile aus. Beispiel: Wenn /etc/modules-load.d/example.confes sich um die bestätigte Quelle handelt:

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

Ändern Sie einen einzelnen example_driverEintrag # example_driver, speichern Sie die Änderung und lassen Sie die übrigen Modulanforderungen unverändert. Falls die Quelle eine Paketdatei unter ist /usr/lib, bearbeiten Sie diese Paketdatei nicht direkt; verwenden Sie stattdessen eine ordnungsgemäß geprüfte lokale Überschreibung oder lassen Sie die Paketkonfiguration korrigieren. Entfernen Sie niemals eine Modulanforderung nur deshalb, weil modinfosie als fehlend gemeldet wird, wenn das entsprechende Gerät benötigt wird.

Wenn ein erforderliches Modul fehlt oder inkompatibel ist

Kommentieren Sie die Zeile nicht aus. Stellen Sie sicher, dass das Treiberpaket die Ausgabe des uname -rinstallierten SLES-Service-Packs unterstützt. Die Meldung „Modul nicht gefunden“ kann darauf hinweisen, dass der passende Treiber nicht installiert oder nach einem Kernel-Update nicht neu kompiliert wurde. Die Meldung „Ungültiges Modulformat“ deutet auf ein Kompatibilitätsproblem hin; Kernel-Logzeilen können die Ursache weiter eingrenzen. Stellen Sie den unterstützten, passenden Treiber gemäß den Anweisungen von SUSE oder des Hardwareherstellers wieder her oder installieren Sie ihn neu. Vermeiden Sie das Kopieren beliebiger .koDateien aus einem anderen Kernel.

Falls das Modul existiert, sein Abhängigkeitsindex aber nachweislich veraltet ist, erstellen Sie diesen Index für den aktuellen Kernel neu und wiederholen Sie den Testlauf:

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

Dieser Schritt installiert keinen fehlenden Treiber. Falls auf einem Secure-Boot-System die Meldung „Erforderlicher Schlüssel nicht verfügbar“ oder eine Ablehnung der Modulsignatur angezeigt wird, befolgen Sie den von SUSE beschriebenen Workflow zur Registrierung vertrauenswürdiger Schlüssel und zur Treibersignatur. Deaktivieren Sie Secure Boot nicht als allgemeine Problemumgehung. SUSE erläutert die Einschränkungen von Drittanbietertreibern in seinen Secure-Boot-Bereitstellungsrichtlinien .

Schritt 4: Sicherstellen, dass der nächste Neustart sauber ist

Nach der Korrektur der Konfiguration oder der Wiederherstellung des Treibers versuchen Sie den Ladevorgang erneut und überprüfen Sie dessen Status. Führen Sie dies erst durch, nachdem Sie sichergestellt haben, dass alle übrigen Einträge korrekt sind; durch einen Neustart werden die konfigurierten Ladevorgänge erneut versucht.

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

Wenn die Einheit erfolgreich repariert wurde, planen Sie einen kontrollierten Neustart mit Konsolenzugriff und führen Sie die Status- und Journalbefehle erneut aus. Die Reparatur ist bestätigt, wenn der Dienst nach dem Neustart nicht mehr fehlschlägt und jegliche erforderliche Hardware oder Software, die vom Modul abhängt, weiterhin funktioniert. Tritt der Fehler erneut auf, vergleichen Sie das neue Protokoll mit dem alten: Möglicherweise ist auch ein anderes aufgeführtes Modul fehlerhaft. Bewahren Sie die Sicherung auf, bis diese Prüfung erfolgreich war; maskieren Sie die Meldung nicht systemd-modules-load.servicenur, um die Startmeldung zu unterdrücken.