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'

Pierwsze polecenie odpowiada na pytanie , które żądanie statycznego ładowania nie powiodło się . Dziennik jądra może dodać kontekst, taki jak odrzucenie wykrytego urządzenia przez sterownik, zależność oprogramowania sprzętowego, problemy z sygnaturą lub inny błąd niższego poziomu.

Wynik taki Module foo not found in directory /lib/modules/...zwykle wskazuje na nieaktualną konfigurację, niezgodność jądra/pakietu lub sterownik innej firmy, który nie został przebudowany dla aktywnego jądra. No such devicejest inny: plik modułu może istnieć, ale bieżący sprzęt lub urządzenie wirtualne może nie odpowiadać temu, czego oczekuje sterownik.

Krok 3: Znajdź osobę, która prosi SLES o załadowanie tego modułu

Przeszukaj normalne lokalizacje obciążenia statycznego i konfigurację modprobe:

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

Zastąp MODULE_NAMEnazwą z dziennika. W systemie SLES 15 SP7 wpisy lokalne w /etc/modules-load.d/to standardowe miejsce zarządzane przez administratora dla modułów, które muszą zostać załadowane podczas rozruchu, natomiast wpisy spakowane mogą istnieć w /usr/lib/modules-load.d/. SUSE zauważa, że ​​większość modułów w ogóle nie wymaga ręcznego wpisu w pliku modules-load.d.

Następnie sprawdź, czy aktywne jądro faktycznie posiada ten moduł:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Jeśli moduł jest przestarzały

Usuń lub wyłącz plik lokalny, który tego żąda. Nie usuwaj pliku dostawcy /usr/libtylko po to, aby wyciszyć błąd, ponieważ aktualizacje pakietów mogą go przywrócić. Jeśli stwierdzisz, że /etc/modules-load.d/*.confplik lokalny został utworzony dla wycofanego sprzętu lub starego oprogramowania, usuń ten wpis lokalny i przetestuj ponownie.

Jeśli moduł powinien istnieć, ale modinfo nie może go znaleźć

Sprawdź, czy uruchomione jądro jest zgodne z zainstalowanym drzewem modułów:

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

Typowa kontrola jakości jest prosta: /lib/modules/$(uname -r)musi istnieć i zawierać moduły jądra, które jest aktualnie uruchomione. Jeśli sterownik innej firmy został skompilowany dla starszego jądra, należy go ponownie zainstalować lub przebudować, aby odpowiadał aktualnemu jądru SLES, zgodnie z procedurą obsługiwaną przez dostawcę. Unikaj kopiowania pliku .koz innej wersji jądra tylko po to, aby modprobecoś znaleźć; różnice w ABI lub sygnaturach jądra mogą sprawić, że takie działanie będzie niebezpieczne lub nieskuteczne.

Jeśli moduł jest na czarnej liście

Wyszukaj czarną listę lub zastąp instalację:

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

Usuń czarną listę dopiero po potwierdzeniu przyczyny jej dodania. Czarna lista może chronić system przed konfliktem sterowników. Przewodnik po modułach SUSE opisuje zarówno trwałe, jak i tymczasowe czarne listy w czasie działania GRUB-a, więc właściwym rozwiązaniem może być usunięcie statycznego żądania ładowania zamiast usuwania czarnej listy.

Jeśli SLES zgłasza nieobsługiwany moduł

Nie włączaj automatycznie ładowania nieobsługiwanych modułów. SLES oznacza moduły jądra jako objęte wsparciem, a wymuszenie nieobsługiwanego modułu może wpłynąć na możliwość wsparcia. SUSE dokumentuje mechanizm wyjątków dla scenariuszy testowania lub poprawek dostawców w swoim Podręczniku administratora. Używaj go tylko wtedy, gdy rozumiesz konsekwencje wsparcia i masz uzasadnione wymagania dotyczące sterownika. Ten sam aktualny podręcznik SUSE jest dostępny w Podręczniku administratora SLES 15 SP7 .

Krok 4: Przebuduj initramfs tylko wtedy, gdy zmiana wpłynie na wczesny rozruch

Jeśli uszkodzony moduł jest potrzebny w initramfs lub zmieniłeś konfigurację sterownika krytycznego dla rozruchu lub czarnej listy, która musi zostać tam odzwierciedlona, ​​wygeneruj obraz ponownie:

sudo dracut -f

SUSE szczegółowo dokumentuje odbudowę initramfs po zmianach sterowników wpływających na rozruch. Aktualny przewodnik po procesie rozruchu wyjaśnia, kiedy należy dodać sterowniki do initramfs i jak dracutgo zregenerować: Wprowadzenie do procesu rozruchu w SLES 15 SP7 .

Nie uruchamiaj tego programu dracut -frutynowo przy każdym błędzie modułu opcjonalnego. Jeśli zwykły moduł po uruchomieniu został jedynie wymieniony w /etc/modules-load.dpliku, jego naprawa może wystarczyć. Przebudowa initramfs jest najbardziej istotna, gdy błędna konfiguracja jest osadzona w obrazie rozruchowym lub wymagany sterownik musi być dostępny przed pełnym zamontowaniem rzeczywistego systemu plików głównego.

Przed uznaniem incydentu za zamknięty należy sprawdzić naprawę

Pierwszy test wykonaj bez ponownego uruchamiania, gdy będzie to bezpieczne:

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

Jeżeli wymagany moduł powinien zostać załadowany, potwierdź to:

lsmod | grep -w MODULE_NAME

Następnie uruchom ponownie w odpowiednim oknie konserwacyjnym i sprawdź nowy rozruch:

sudo reboot

Po zalogowaniu:

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

Najsilniejszym sygnałem sukcesu nie jest to, że komunikat konsoli zniknął raz. Chodzi o to, że po ponownym uruchomieniu nie ma powtórzenia tego samego błędu modułu, a sprzęt lub podsystem zależny od modułu nadal działa.

Kiedy zmienić podejście

Ograniczenia tej poprawki

Komunikat „Failed to Start Load Kernel Modules” (Nie udało się uruchomić ładowania modułów jądra) to objaw, a nie pojedyncza usterka. Ta procedura rozwiązuje problemy spowodowane statycznymi żądaniami modułów, brakującymi lub niedopasowanymi modułami, czarnymi listami i synchronizacją initramfs. Nie zastępuje ona diagnostyki sprzętu, obsługi sterowników innych firm, podpisywania Secure Boot ani odzyskiwania pamięci masowej, gdy samo urządzenie główne jest niedostępne.

W przypadku produkcyjnych systemów SLES należy zachować dostępność wsparcia: preferuj moduł dostarczony dla jądra SLES, dostosuj sterowniki innych firm do macierzy wsparcia ich dostawców i korzystaj z udokumentowanych mechanizmów SUSE, zamiast pomijać sprawdzanie tylko po to, by usunąć awarię usługi. Naprawa jest zakończona, gdy stan usługi, dziennik rozruchu i zależny sprzęt zgodnie potwierdzą, że problem zniknął.