Eroare la încărcarea modulului de pornire SLES: Găsiți driverul și remediați-l

Când SLES afișează mesajul „Failed to Start Load Kernel Modules” (Eșuat la pornirea încărcării modulelor kernelului) în timpul pornirii, verificați mai întâi systemd-modules-load.servicejurnalele pentru a identifica modulul care a eșuat. Dacă modulul este o intrare opțională învechită, eliminați acea solicitare din configurația sa; dacă este necesară, reparați nepotrivirea driverului sau a kernelului în loc să dezactivați serviciul.

Această procedură se aplică pentru SUSE Linux Enterprise Server (SLES) 15, utilizând ca referință documentația de administrare SLES 15 SP7. Comenzile trebuie executate dintr-o consolă locală sau dintr-o sesiune SSH funcțională cu sudoacces.

Ce înseamnă mesajul înainte să schimbi ceva

Un modul kernel este un driver sau o caracteristică a kernelului care poate fi încărcată separat. În timpul pornirii, systemd-modules-load.serviceprocesează cererile de încărcare a anumitor module, inclusiv cele definite în modules-load.dfișiere. O cerere nereușită poate duce la eșecul serviciului respectiv chiar și atunci când alte părți ale serverului continuă să ruleze.

SUSE observă că majoritatea driverelor se încarcă automat atunci când este detectat hardware. O listă manuală de module este de obicei inutilă, așadar o intrare învechită este o posibilitate rezonabilă - dar mesajul de pornire în sine nu dovedește acest lucru. Păstrați accesul la consolă, faceți o instantanee a sistemului sau o copie de rezervă a configurației, acolo unde este disponibilă, și nu descărcați driverele de stocare, rețea sau cluster doar pentru a face avertismentul să dispară. Consultați ghidul de administrare a modulelor kernel de la SUSE pentru modelul acceptat.

Pasul 1: Citiți starea serviciului și jurnalul de pornire a acestuia

Începeți cu starea systemd. systemdeste managerul de servicii responsabil pentru pornirea serviciilor și raportarea stării acestora.

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

Steagul -brestricționează journalctlla pornirea curentă și -uselectează acest serviciu. Verificați deasupra liniei finale „Eșuat cu rezultat” mesaje precum „Eșuat la găsirea modulului”, o opțiune nevalidă sau o eroare de permisiune sau semnătură. Înregistrați numele exact al modulului și textul erorii. Nu presupuneți că modulul numit în exemplul de mai jos există pe serverul dvs.

Dacă jurnalul de service este neconcludent, verificați mesajele kernelului pentru detalii suplimentare:

sudo journalctl -k -b --no-pager

Dacă computerul nu poate accesa o autentificare utilizabilă, porniți un kernel instalat mai vechi din GRUB, dacă este disponibil unul, sau utilizați mediul de salvare SLES. Nu editați modulele critice pentru bootare dintr-o sesiune netestată, doar la distanță. SUSE documentează filtrele de jurnal în capitolul său de administrare journalctl .

Pasul 2: Găsiți configurația de pornire care o solicită

Să presupunem că jurnalul denumește example_driver. Înlocuiți acel titlu substituent cu numele real al modulului, apoi căutați în listele de module:

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

Fiecare linie corespondentă vă spune ce fișier solicită acel modul la pornire. Configurația locală a unui administrator se află de obicei sub /etc/modules-load.d/, în timp ce un pachet își poate furniza fișierul sub . Un fișier local cu același nume de bază are prioritate față de fișierul furnizorului, așa cum este descris în ghidul de configurare systemd/usr/lib/modules-load.d/ al SUSE . Dacă căutarea nu găsește nimic, examinați și solicitările de module la pornire și verificați dacă numele erorii a fost copiat corect.cat /proc/cmdline

Deschideți fișierul corespunzător și identificați dacă intrarea este încă necesară de către hardware sau aplicație. Un modul solicitat pentru un dispozitiv vechi, eliminat, este diferit de un driver de controler de stocare sau de un watchdog de cluster.

Pasul 3: Testați modulul, apoi aplicați repararea corespunzătoare

Verifică ce kernel rulează și dacă driverul este disponibil pentru acesta. modprobeîncarcă modulele kernelului și rezolvă dependențele; -nopțiunea sa efectuează o rulare fără a introduce unul.

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

Din nou, înlocuiți example_driver. Rularea simulată ajută la identificarea problemelor de căutare sau de configurare, dar nu dovedește că un driver se va inițializa cu succes pe hardware sau va trece verificările de semnătură Secure Boot. SUSE recomandă încărcarea modprobedirectă insmod; detalii despre semnalizatoarele de rulare simulată apar în manualul modprobe .

Dacă o intrare opțională învechită indică un modul lipsă

Faceți o copie de rezervă a fișierului local specific și comentați doar linia învechită. De exemplu, dacă /etc/modules-load.d/example.confeste sursa confirmată:

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

Schimbați o singură example_driverintrare în # example_driver, salvați și lăsați celelalte solicitări de modul intacte. Dacă sursa este un fișier pachet sub /usr/lib, nu editați direct fișierul pachet; utilizați o suprascriere locală verificată corespunzător sau corectați configurația pachetului. Nu eliminați niciodată o solicitare de modul doar pentru că modinforaportează că lipsește dacă dispozitivul corespunzător este necesar.

Dacă un modul necesar lipsește sau este incompatibil

Nu comentați. Confirmați că pachetul de drivere acceptă ieșirea uname -rși pachetul service pack SLES instalat. Un mesaj „modul negăsit” poate indica faptul că driverul corespunzător nu a fost instalat sau nu a fost reconstruit după o actualizare a kernelului. Un mesaj „format de modul nevalid” sugerează o problemă de compatibilitate; liniile de jurnal ale kernelului pot restrânge și mai mult problema. Restaurați sau reinstalați driverul corespunzător acceptat prin SUSE sau prin instrucțiunile furnizorului de hardware. Evitați copierea .kofișierelor arbitrare dintr-un kernel diferit.

Dacă modulul există, dar indicele său de dependență este demonstrabil învechit, reconstruiți acel indice pentru kernelul curent și încercați din nou rularea de probă:

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

Acest pas nu instalează un driver lipsă. Dacă vedeți mesajul „Cheia necesară nu este disponibilă” sau respingerea semnăturii modulului pe un sistem Secure Boot, urmați fluxul de lucru SUSE pentru înscrierea cheilor de încredere și semnarea driverelor; nu dezactivați Secure Boot ca soluție generică. SUSE explică restricțiile driverelor terțe în ghidul său de implementare Secure Boot .

Pasul 4: Confirmați că următoarea pornire este curată

După corectarea configurației sau restaurarea driverului, încercați din nou încărcătorul și verificați starea acestuia. Efectuați această operațiune numai după validarea faptului că toate intrările rămase sunt corecte; repornirea va încerca din nou încărcările configurate.

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

Dacă unitatea funcționează cu succes, programați o repornire controlată cu acces la consolă și executați din nou comenzile status și journal. Remedierea este confirmată atunci când serviciul nu mai eșuează la noua pornire și orice hardware sau software necesar care depinde de modul încă funcționează. Dacă eroarea reapare, comparați noul jurnal cu cel vechi: este posibil ca un alt modul listat să eșueze, de asemenea. Păstrați copia de rezervă până când verificarea trece; nu mascați systemd-modules-load.servicedoar pentru a suprima mesajul de pornire.