Błąd ładowania modułu rozruchowego SLES: znajdź sterownik i napraw go

Gdy podczas rozruchu SLES wyświetla komunikat „Nie udało się uruchomić modułu ładowania jądra”, najpierw sprawdź systemd-modules-load.servicelogi, aby zidentyfikować moduł, który uległ awarii. Jeśli moduł jest przestarzałym, opcjonalnym wpisem, usuń to żądanie z jego konfiguracji; jeśli jest wymagane, napraw niezgodność sterownika lub jądra zamiast wyłączać usługę.

Niniejsza procedura dotyczy systemu SUSE Linux Enterprise Server (SLES) 15 i opiera się na dokumentacji administracyjnej systemu SLES 15 SP7. Polecenia należy uruchamiać z konsoli lokalnej lub z działającej sesji SSH z sudodostępem.

Co oznacza wiadomość, zanim cokolwiek zmienisz

Moduł jądra to sterownik lub funkcja jądra, którą można załadować osobno. Podczas uruchamiania systemd-modules-load.serviceprzetwarza żądania załadowania określonych modułów, w tym tych zdefiniowanych w modules-load.dplikach. Nieudane żądanie może spowodować awarię usługi, nawet gdy inne części serwera nadal działają.

SUSE zauważa, że ​​większość sterowników ładuje się automatycznie po wykryciu sprzętu. Ręczna lista modułów jest zazwyczaj zbędna, więc nieaktualny wpis jest uzasadniony – ale sam komunikat rozruchowy tego nie potwierdza. Zachowaj dostęp do konsoli, wykonaj migawkę systemu lub kopię zapasową konfiguracji, jeśli jest dostępna, i nie zwalniaj pamięci sterowników pamięci masowej, sieci ani klastra tylko po to, aby ostrzeżenie zniknęło. Informacje na temat obsługiwanego modelu można znaleźć w podręczniku administratora modułów jądra SUSE .

Krok 1: Odczytaj stan usługi i jej dziennik rozruchu

Zacznij od systemd status. systemdJest to menedżer usług odpowiedzialny za uruchamianie usług i raportowanie ich stanu.

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

Flaga -bogranicza się journalctldo bieżącego rozruchu i -uwybiera tę usługę. Sprawdź powyżej ostatniego wiersza „Niepowodzenie z wynikiem” komunikaty takie jak „Nie znaleziono modułu”, nieprawidłowa opcja lub błąd uprawnień lub podpisu. Zapisz dokładną nazwę modułu i tekst błędu. Nie zakładaj, że moduł o nazwie podanej w poniższym przykładzie istnieje na Twoim serwerze.

Jeśli dziennik serwisowy nie daje jednoznacznych odpowiedzi, sprawdź komunikaty jądra, aby uzyskać dodatkowe szczegóły:

sudo journalctl -k -b --no-pager

Jeśli komputer nie może nawiązać użytecznego logowania, uruchom starsze jądro z GRUB-a, jeśli jest dostępne, lub skorzystaj z nośnika ratunkowego SLES. Nie edytuj modułów krytycznych dla rozruchu z nieprzetestowanej sesji zdalnej. SUSE dokumentuje filtry dziennika w rozdziale poświęconym administracji journalctl .

Krok 2: Znajdź konfigurację startową, która tego wymaga

Załóżmy, że nazwy czasopism example_driver… Zastąp ten symbol zastępczy rzeczywistą nazwą modułu, a następnie przeszukaj listy modułów:

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

Każdy pasujący wiersz wskazuje, który plik żąda danego modułu podczas rozruchu. Lokalna konfiguracja administratora zazwyczaj znajduje się w /etc/modules-load.d/, podczas gdy pakiet może udostępniać swój plik w . Plik lokalny o tej samej nazwie bazowej ma pierwszeństwo przed plikiem dostawcy, zgodnie z opisem w podręczniku konfiguracji systemd w systemie/usr/lib/modules-load.d/ SUSE . Jeśli wyszukiwanie nic nie da, należy również sprawdzić żądania modułów podczas rozruchu i upewnić się, że nazwa błędu została poprawnie skopiowana.cat /proc/cmdline

Otwórz pasujący plik i sprawdź, czy wpis jest nadal potrzebny sprzętowi lub aplikacji. Moduł żądany dla starego, usuniętego urządzenia różni się od sterownika kontrolera pamięci masowej lub mechanizmu nadzorującego klaster.

Krok 3: Przetestuj moduł, a następnie zastosuj odpowiednią naprawę

Sprawdź, które jądro jest uruchomione i czy dostępny jest dla niego sterownik. modprobeŁaduje moduły jądra i rozwiązuje zależności. Ta -nopcja przeprowadza próbę bez konieczności instalowania żadnego z nich.

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

Ponownie, zastąp example_driver. Próbny rozruch pomaga zidentyfikować problemy z wyszukiwaniem lub konfiguracją, ale nie dowodzi , że sterownik zainicjuje się poprawnie na sprzęcie lub przejdzie kontrolę podpisu Secure Boot. SUSE zaleca, modprobeaby nie insmodładować bezpośrednio; szczegóły dotyczące flag próbnego rozruchu znajdują się w podręczniku modprobe .

Jeśli przestarzały opcjonalny wpis wskazuje na brakujący moduł

Utwórz kopię zapasową konkretnego pliku lokalnego i zakomentuj tylko przestarzały wiersz. Na przykład, jeśli /etc/modules-load.d/example.confjest to potwierdzone źródło:

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

Zmień pojedynczy example_driverwpis na # example_driver, zapisz i pozostaw inne żądania modułów nienaruszone. Jeśli źródłem jest plik pakietu w /usr/lib, nie edytuj tego pliku bezpośrednio; użyj poprawnie sprawdzonego lokalnego nadpisania lub popraw konfigurację pakietu. Nigdy nie usuwaj żądania modułu tylko dlatego, że modinfozgłasza jego brak, podczas gdy odpowiednie urządzenie jest wymagane.

Jeśli wymagany moduł jest nieobecny lub niezgodny

Nie należy tego komentować. Upewnij się, że pakiet sterowników obsługuje dane wyjściowe uname -rzainstalowanego pakietu serwisowego SLES. Komunikat „nie znaleziono modułu” może wskazywać, że pasujący sterownik nie został zainstalowany lub nie został przebudowany po aktualizacji jądra. Komunikat „nieprawidłowy format modułu” sugeruje problem ze zgodnością; wiersze logów jądra mogą go dodatkowo zawęzić. Przywróć lub ponownie zainstaluj obsługiwany pasujący sterownik za pomocą systemu SUSE lub instrukcji producenta sprzętu. Unikaj kopiowania dowolnych .koplików z innego jądra.

Jeżeli moduł istnieje, ale jego indeks zależności jest ewidentnie nieaktualny, utwórz ponownie ten indeks dla bieżącego jądra i spróbuj ponownie przeprowadzić próbę:

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

Ten krok nie instaluje brakującego sterownika. Jeśli w systemie Secure Boot pojawi się komunikat „Wymagany klucz niedostępny” lub odrzucenie podpisu modułu, należy postępować zgodnie z procedurą rejestracji zaufanego klucza i podpisywania sterowników firmy SUSE; nie należy wyłączać funkcji Secure Boot jako ogólnego obejścia. Firma SUSE wyjaśnia ograniczenia dotyczące sterowników innych firm w swoich wskazówkach dotyczących wdrażania funkcji Secure Boot .

Krok 4: Sprawdź, czy kolejny rozruch jest czysty

Po poprawieniu konfiguracji lub przywróceniu sterownika, spróbuj ponownie uruchomić moduł ładujący i sprawdź jego status. Zrób to dopiero po upewnieniu się, że wszystkie pozostałe wpisy są poprawne; ponowne uruchomienie spowoduje ponowną próbę załadowania skonfigurowanych elementów.

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

Jeśli jednostka zakończy się powodzeniem, zaplanuj kontrolowany restart z dostępem do konsoli i ponownie uruchom polecenia status i journal. Naprawa zostanie potwierdzona, gdy usługa nie będzie już awariować po nowym uruchomieniu, a wszelki wymagany sprzęt lub oprogramowanie zależne od modułu nadal będzie działać. Jeśli błąd wystąpi ponownie, porównaj nowy dziennik ze starym: inny wymieniony moduł również może być uszkodzony. Zachowaj kopię zapasową do momentu pomyślnego zakończenia kontroli; nie maskuj jej systemd-modules-load.servicetylko po to, aby ukryć komunikat startowy.