Remediați eroarea „Eșuat la pornirea încărcării modulelor kernel” la bootarea SLES

Mesajul de boot SLES „Failed to Start Load Kernel Modules” (Eșuat la pornirea încărcării modulelor kernelului) înseamnă de obicei că systemd-modules-load.services-a încercat încărcarea a cel puțin unui modul kernel și o solicitare a eșuat. Scopul util nu este doar ascunderea liniei roșii de boot. O reparație bună lasă serviciul sănătos, elimină solicitările de module învechite, păstrează orice driver de care mașina are nevoie și supraviețuiește următoarei reporniri.

Acest ghid este scris pentru SUSE Linux Enterprise Server 15 și este aliniat cu Ghidul de administrare SLES 15 SP7 actual. Documentele SUSE systemd-modules-load.serviceîncarcă modulele numite în /etc/modules-load.d/*.conf, în timp ce majoritatea modulelor hardware moderne sunt în mod normal încărcate automat atunci când sunt detectate dispozitive. Această distincție contează: dacă o intrare statică învechită indică un modul care nu mai există, ștergerea sau corectarea acelei intrări este adesea mai sigură decât reinstalarea forțată a unui driver învechit în sistem. Consultați documentația SUSE privind gestionarea modulelor kernel pentru SLES 15 SP7 .

Cum ar trebui să arate o reparație reușită

Înainte de a schimba ceva, definește rezultatul dorit. După reparație:

• systemctl status systemd-modules-load.servicenu ar trebui să mai raporteze un rezultat eșuat.
• Jurnalul nu ar trebui să mai afișeze aceeași eroare de încărcare a modulelor în timpul unei noi porniri.
• Dacă modulul este într-adevăr necesar, modprobe MODULE_NAMEar trebui să funcționeze corect, iar hardware-ul sau funcția aferentă ar trebui să funcționeze.
• Dacă modulul este învechit, cererea învechită ar trebui eliminată, nu înlocuită cu un modul fără legătură.
• Dacă problema este legată de o pornire timpurie, fișierul initramfs ar trebui reconstruit, iar mașina ar trebui să repornească în mod normal.

Dacă aceste verificări nu se aplică toate situației dvs., utilizați-le pe cele care corespund componentei defecte. De exemplu, un server poate porni cu succes chiar dacă un modul opțional eșuează. Acest lucru merită totuși curățat, dar este diferit de lipsa unui driver de stocare care împiedică apariția sistemului de fișiere rădăcină.

Pasul 1: Confirmați unitatea defectă și capturați eroarea exactă a modulului

Începeți cu serviciul în sine, în loc să ghiciți din mesajul de pe ecranul de pornire:

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

Căutați numele unui modul și o eroare precum Module ... not found, No such device, Operation not permitted, sau un mesaj care indică refuzul unui modul neacceptat. Formularea exactă determină următoarea acțiune.

Dacă ieșirea de stare este trunchiată, nu editați încă configurația. Obțineți mai întâi jurnalul de bootare complet.

Pasul 2: Citiți jurnalul de boot înainte de a modifica fișierele modulului

Interogați doar acest serviciu pentru pornirea curentă:

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

De asemenea, puteți inspecta mesajele kernelului în jurul încărcării modulului:

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

Prima comandă răspunde la întrebarea care solicitare de încărcare statică a eșuat . Jurnalul kernelului poate adăuga context, cum ar fi un driver care refuză dispozitivul detectat, o dependență de firmware, probleme de semnătură sau o altă eroare de nivel inferior.

Un rezultat precum Module foo not found in directory /lib/modules/...indică de obicei o configurație învechită, o nepotrivire kernel/pachet sau un driver terț care nu a fost reconstruit pentru kernelul activ. No such deviceeste diferit: fișierul modulului poate exista, dar hardware-ul sau dispozitivul virtual curent poate să nu corespundă cu ceea ce așteaptă driverul.

Pasul 3: Găsiți cine îi cere SLES să încarce acel modul

Căutați locațiile normale de încărcare statică și configurația 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

Înlocuiți MODULE_NAMEcu numele din jurnal. Pe SLES 15 SP7, intrările locale din /etc/modules-load.d/reprezintă locul standard gestionat de administrator pentru modulele care trebuie încărcate la pornire, în timp ce intrările pachet pot exista sub /usr/lib/modules-load.d/. SUSE observă că majoritatea modulelor nu necesită deloc o intrare manuală modules-load.d.

Apoi verificați dacă kernelul activ are de fapt modulul:

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

Dacă modulul este învechit

Eliminați sau dezactivați fișierul local care îl solicită. Nu ștergeți un fișier furnizor /usr/libdoar pentru a silenționa eroarea, deoarece actualizările pachetului îl pot restaura. Dacă constatați că un /etc/modules-load.d/*.conffișier local a fost creat pentru hardware retras sau software vechi, eliminați intrarea locală respectivă și testați din nou.

Dacă modulul ar trebui să existe, dar modinfo nu îl poate găsi

Verificați dacă kernelul care rulează se potrivește cu arborele de module instalat:

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

O verificare obișnuită a calității este simplă: /lib/modules/$(uname -r)trebuie să existe și să conțină modulele pentru kernelul care rulează efectiv. Dacă un driver terț a fost compilat pentru un kernel mai vechi, reinstalați sau reconstruiți driverul respectiv pentru kernelul SLES curent folosind procedura acceptată de furnizor. Evitați copierea unui .kofișier dintr-o altă versiune de kernel doar pentru modprobea găsi ceva; diferențele de ABI sau semnătură ale kernelului pot face ca acest lucru să fie nesigur sau ineficient.

Dacă modulul este pe lista neagră

Căutați o listă neagră sau instalați o altă opțiune:

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

Eliminați o listă neagră doar după confirmarea motivului pentru care a fost adăugată. O listă neagră poate proteja sistemul de un driver conflictual. Ghidul modulelor SUSE documentează atât includerea persistentă în listele negre, cât și includerea temporară în listele negre în timp real GRUB, așadar rezultatul corect ar putea fi eliminarea solicitării de încărcare statică în loc de eliminarea listei negre.

Dacă SLES raportează un modul neacceptat

Nu activați automat încărcarea modulelor neacceptate. SLES marchează modulele kernel pentru starea de suport, iar forțarea unui modul neacceptat poate afecta suportabilitatea. SUSE documentează mecanismul de excepții pentru testare sau scenarii de remediere rapidă de la furnizor în Ghidul său de administrare. Utilizați-l numai atunci când înțelegeți consecințele suportului și aveți o cerință legitimă pentru driver. Același ghid SUSE actual este disponibil în Ghidul de administrare SLES 15 SP7 .

Pasul 4: Reconstruiți initramfs doar atunci când modificarea afectează pornirea timpurie

Dacă modulul defect este necesar în interiorul initramfs sau dacă ați modificat driverul critic pentru bootare sau configurația listei negre care trebuie să fie reflectată acolo, regenerați imaginea:

sudo dracut -f

SUSE documentează în mod specific reconstruirea fișierului initramfs după modificările driverelor care afectează bootarea. Ghidul său actual privind procesul de bootare explică când trebuie adăugate drivere la initramfs și cum dracutse utilizează pentru regenerarea acestuia: Introducere în procesul de bootare în SLES 15 SP7 .

Nu rulați dracut -fca un ritual pentru fiecare eroare de modul opțional. Dacă un modul obișnuit post-boot era doar listat în /etc/modules-load.d, corectarea acelui fișier ar putea fi suficientă. Reconstruirea fișierului initramfs este cea mai relevantă atunci când configurația greșită este încorporată în imaginea de boot sau driverul necesar trebuie să fie disponibil înainte ca sistemul de fișiere rădăcină real să fie montat complet.

Verificați reparația înainte de a considera incidentul închis

Primul test fără repornire când este sigur să faceți acest lucru:

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

Dacă modulul necesar ar trebui încărcat acum, confirmați-l:

lsmod | grep -w MODULE_NAME

Apoi reporniți sistemul în timpul unei ferestre de întreținere adecvate și verificați noua pornire:

sudo reboot

După autentificare:

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

Cel mai puternic semnal de succes nu este că mesajul consolei a dispărut o dată. Ci că o nouă pornire nu are nicio repetare a aceleiași erori de modul și hardware-ul sau subsistemul care depinde de modul încă funcționează.

Când să schimbi abordarea

Limitele acestei remedieri

Linia „Începerea încărcării modulelor kernelului a eșuat” este un simptom, nu un singur defect. Această procedură abordează erorile cauzate de solicitările statice de module, modulele lipsă sau nepotrivite, listele negre și sincronizarea initramfs. Nu înlocuiește diagnosticarea hardware, asistența pentru drivere terțe, semnarea Secure Boot sau recuperarea spațiului de stocare atunci când dispozitivul rădăcină în sine nu este disponibil.

Pentru sistemele SLES de producție, păstrați suportabilitatea: preferați modulul livrat pentru kernelul SLES, mențineți driverele terțe aliniate cu matricea de suport a furnizorului lor și utilizați mecanismele documentate de SUSE în loc să ocoliți verificările pur și simplu pentru a remedia o eroare de serviciu. Repararea este completă atunci când starea serviciului, jurnalul de boot și hardware-ul dependent sunt de acord că problema a dispărut.