Errore di caricamento del modulo di avvio SLES: individua il driver e risolvilo

Quando SLES visualizza il messaggio "Impossibile avviare il caricamento dei moduli del kernel" durante l'avvio, per prima cosa esamina systemd-modules-load.servicei log per identificare il modulo che ha causato l'errore. Se il modulo è una voce opzionale obsoleta, rimuovi la relativa richiesta dalla sua configurazione; se invece è necessario, correggi l'incompatibilità del driver o del kernel anziché disabilitare il servizio.

Questa procedura si applica a SUSE Linux Enterprise Server (SLES) 15, utilizzando come riferimento la documentazione di amministrazione di SLES 15 SP7. I comandi devono essere eseguiti da una console locale o da una sessione SSH funzionante con sudoaccesso.

Cosa significa il messaggio prima di modificare qualsiasi cosa

Un modulo del kernel è un driver o una funzionalità del kernel che può essere caricato separatamente. Durante l'avvio, systemd-modules-load.serviceelabora le richieste di caricamento di moduli specifici, inclusi quelli definiti nei modules-load.dfile. Una richiesta non andata a buon fine può causare l'interruzione del servizio anche se altre parti del server continuano a funzionare.

SUSE fa notare che la maggior parte dei driver si carica automaticamente quando viene rilevato l'hardware. Un elenco manuale dei moduli di solito non è necessario, quindi una voce obsoleta è una possibilità plausibile, ma il solo messaggio di avvio non lo dimostra. Mantieni l'accesso alla console, crea uno snapshot di sistema o un backup della configurazione, se disponibile, e non disinstallare i driver di archiviazione, di rete o del cluster solo per far scomparire l'avviso. Consulta la guida all'amministrazione dei moduli del kernel di SUSE per il modello supportato.

Passaggio 1: Leggere lo stato del servizio e il relativo registro di avvio.

Inizia con lo stato di systemd. systemd systemdè il gestore dei servizi responsabile dell'avvio dei servizi e della segnalazione del loro stato.

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

Il -bflag limita journalctll'avvio corrente e -useleziona questo servizio. Sopra la riga finale "Errore con risultato" cerca messaggi come "Impossibile trovare il modulo", un'opzione non valida o un errore di autorizzazione o di firma. Annota il nome esatto del modulo e il testo dell'errore. Non dare per scontato che il modulo indicato nell'esempio seguente esista sul tuo server.

Se il registro di servizio non è conclusivo, controllare i messaggi del kernel per ulteriori dettagli:

sudo journalctl -k -b --no-pager

Se il computer non riesce a raggiungere un login utilizzabile, avviare un kernel installato in una versione precedente tramite GRUB, se disponibile, oppure utilizzare il supporto di ripristino SLES. Non modificare moduli critici per l'avvio da una sessione remota non testata. SUSE documenta i filtri del journal nel capitolo relativo all'amministrazione di journalctl .

Passaggio 2: Trova la configurazione di avvio che lo richiede

Supponiamo che i nomi delle riviste siano example_driver. Sostituisci quel segnaposto con il nome effettivo del modulo, quindi cerca negli elenchi dei moduli:

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

Ogni riga corrispondente indica quale file richiede quel modulo all'avvio. La configurazione locale di un amministratore si trova solitamente in /etc/modules-load.d/, mentre un pacchetto può fornire il suo file in /usr/lib/modules-load.d/. Un file locale con lo stesso nome base ha la precedenza sul file del fornitore, come descritto nella guida alla configurazione di systemd di SUSE . Se la ricerca non trova nulla, esamina anche cat /proc/cmdlinele richieste di moduli all'avvio e verifica che il nome dell'errore sia stato copiato correttamente.

Apri il file corrispondente e verifica se la voce è ancora necessaria all'hardware o all'applicazione. Un modulo richiesto per un dispositivo vecchio e rimosso è diverso da un driver del controller di archiviazione o da un watchdog del cluster.

Passaggio 3: testare il modulo, quindi applicare la riparazione corrispondente

Verifica quale kernel è in esecuzione e se il driver è disponibile per esso. modprobeCarica i moduli del kernel e risolve le dipendenze; ​​la sua -nopzione esegue una simulazione senza inserirne uno.

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

Di nuovo, sostituisci example_driver. La prova a secco aiuta a identificare problemi di ricerca o di configurazione, ma non dimostra che un driver si inizializzerà correttamente sul tuo hardware o supererà i controlli della firma di Secure Boot. SUSE consiglia di utilizzare modprobepiuttosto che insmodcaricare direttamente; i dettagli dei flag di prova a secco sono riportati nel manuale di modprobe .

Se una voce facoltativa obsoleta punta a un modulo mancante

Esegui il backup del file locale specifico e commenta solo la riga obsoleta. Ad esempio, se /etc/modules-load.d/example.confquesta è la fonte confermata:

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

Modifica una singola example_drivervoce in # example_driver, salva e lascia intatte le altre richieste di modulo. Se la sorgente è un file di pacchetto in /usr/lib, non modificare direttamente tale file di pacchetto; utilizza un override locale opportunamente verificato oppure fai correggere la configurazione del pacchetto. Non rimuovere mai una richiesta di modulo solo perché modinfosegnala che manca se il dispositivo corrispondente è richiesto.

Se un modulo richiesto è mancante o incompatibile

Non commentare questa parte. Verifica che il pacchetto del driver supporti l'output uname -re il service pack SLES installato. Un messaggio "modulo non trovato" potrebbe indicare che il driver corrispondente non è stato installato o non è stato ricompilato dopo un aggiornamento del kernel. Un messaggio "formato modulo non valido" suggerisce un problema di compatibilità; le righe del log del kernel possono aiutare a circoscriverlo ulteriormente. Ripristina o reinstalla il driver compatibile supportato tramite SUSE o le istruzioni del produttore dell'hardware. Evita di copiare .kofile arbitrari da un kernel diverso.

Se il modulo esiste ma il suo indice di dipendenza è palesemente obsoleto, ricostruisci tale indice per il kernel corrente e riprova la simulazione:

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

Questo passaggio non installa un driver mancante. Se visualizzi il messaggio "Chiave richiesta non disponibile" o un errore di firma del modulo su un sistema Secure Boot, segui la procedura di registrazione della chiave attendibile e di firma del driver di SUSE; non disabilitare Secure Boot come soluzione generica. SUSE illustra le restrizioni relative ai driver di terze parti nella sua guida alla distribuzione di Secure Boot .

Passaggio 4: Verificare che il successivo avvio sia pulito

Dopo aver corretto la configurazione o ripristinato il driver, riprovare il caricamento e verificarne lo stato. Eseguire questa operazione solo dopo aver verificato che tutte le voci rimanenti siano corrette; il riavvio tenterà nuovamente i caricamenti configurati.

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

Se l'unità funziona correttamente, pianifica un riavvio controllato con accesso alla console ed esegui nuovamente i comandi di stato e di registro. La correzione è confermata quando il servizio non fallisce più al nuovo avvio e qualsiasi hardware o software necessario che dipende dal modulo funziona ancora. Se l'errore si ripresenta, confronta il nuovo registro con quello precedente: anche un altro modulo elencato potrebbe essere in errore. Conserva il backup finché questo controllo non viene superato; non mascherare systemd-modules-load.serviceil messaggio solo per sopprimerlo all'avvio.