Kernel panic

[ercolinux]

Ciao, 3 giorni fa durante un aggiornamento si è verificato un kernel panic e da allora è diventato impossibile avviare openmamba in quanto si blocca dopo pochi secondi dalla selezione del sistema in GRUB: indipendentemente dalla versione di kernel che seleziono all’avvio il sistema si freeza dopo 5-6 secondi, senza generare un log (ho verificato montando il disco da una live). Avviando in modalità debug si vede la schermata che allego.

Ho controllato avviando Windows da un’altra partizione e openmamba da una chiavetta live che il PC non avesse problemi hardware (esclusi anche da un memtest e un controllo approfondito del disco fisso con badblocks).

Attachments:

1. 

   log-errore.jpeg
   

[Silvan]

Ciao,
se è avvenuto un crash del sistema mentre l’aggiornamento era in corso molti files dei pacchetti che erano in fase di aggiornamento potrebbero risultare mancanti o troncati, in particolare delle librerie o eseguibili importanti per l’avvio del sistema.
Un modo per diagnosticare e provare a correggere il problema è

1) avviare il sistema live di openmamba ed effettuare il mount del root filesystem con i bind mount necessari. Il codice seguente tratto da /usr/bin/sb-setup fornisce un suggerimento sui comandi da eseguire assumendo che il root filesystem sia il devie /dev/sda2:

`
# Sample chroot mount:
# sudo mkdir /mnt/sda2
# sudo mount /dev/sda2 /mnt/sda2
# sudo mount -o bind /dev /mnt/sda2/dev
# sudo mount -o bind /sys /mnt/sda2/sys
# sudo mount -o bind /proc /mnt/sda2/proc
# sudo mount -o bind /run /mnt/sda2/run
# sudo mount -o bind /mnt/sda1 /mnt/sda2/boot/efi
# sudo mount -o bind /sys/firmware/efi/efivars /mnt/sda2/sys/firmware/efi/efivars/
`

2) eseguire chroot nel sistema:

`
sudo chroot /mnt/sda2
`

Si dovrebbe avviare una shell nell’ambiente chroot ma già a questo punto potrebbero verificarsi degli errori che danno indicazione di file e librerie che sono rimasti corrotti nel sistema.

3) devono essere reinstallati gli rpm cui si riferiscono i problemi, dall’esterno se il comando chroot di cui sopra, o il comando dnf, non funziona, altrimenti si può usare sudo dnf reinstall .. da dentro chroot  con la rete funzionante, questa procedura può essere più o meno complessa a seconda del grado di corruzione del filesystem.

Riguardo al crash durante l’aggiornamento, come si capisce che si sia trattato di un kernel panic? L’ambiente desktop è switchato sulla console nera che ha fornito la segnalazione di KERNEL PANIC? Non vedo succedere questo tipo di problema da molto tempo con i kernel recenti e normalmente dovrebbe riferirsi ad un grave problema hardware.

 

• Questa risposta è stata modificata 3 giorni, 7 ore fa da Silvan.

[ercolinux]

Domani provo a ripristinare il sistema come mi hai consigliato

Silvan wrote:

Riguardo al crash durante l’aggiornamento, come si capisce che si sia trattato di un kernel panic? L’ambiente desktop è switchato sulla console nera che ha fornito la segnalazione di KERNEL PANIC? Non vedo succedere questo tipo di problema da molto tempo con i kernel recenti e normalmente dovrebbe riferirsi ad un grave problema hardware.

Quando si è bloccato durante l’aggiornamento si è congelato tutto e lo schermo è rimasto con l’immagine che stava mostrando e il led del capslock ha iniziato a lampeggiare in continuo, che da cosa so è il segnale per indicare un kernel panic. Anche quando si blocca durante l’avvio il led lampeggia in continuo.

 

[ercolinux]

Faccio una piccola aggiunta: tentando di riavviare il PC per vedere se riuscivo a leggere la parte inziale del log si è fermato con un errore diverso rispetto a prima e con le scritte parzialmente danneggiate. Ho provato a lasciar girare la live per un po’ anche con diverse programmi aperti e non mi ha dato nessun problema.

Attachments:

1. 

   errore.jpg
   

[Silvan]

Dalla seconda immagine noto la versione del BIOS che potrebbe denotare un hardware relativamente recente a meno che non sia recente l’aggiornamento del BIOS stesso.
Il problema si verifica durante lo switch del filesystem dal quale dovrebbero essere caricati ed eseguiti lo stesso systemd ed altri componenti che potrebbero essere stati corrotti durante l’aggiornamento.
Se il problema sembra evidentemente conseguenza dell’aggiornamento potrebbe essere utile capire la portata di questo aggiornamento, ovvero potrebbe aver aggiornato i componenti di un certo giorno, dell’ultima settimana, mese o più, a seconda di questa informazione si definisce la misura del campo delle possibili cause, se dipende dall’aggiornamento di qualche componente.
Tra i vari metodi di debugging ci sono anche:
1) invece di avviare systemd, dopo lo switch del filesystem di root si può provare ad avviare una shell aggiungendo init=/bin/bash alla riga di comando del kernel, questo semplificherebbe la diagnostica e possibilità di intervenire sul filesystem
2) si può attivare un maggiore logging di debug aggiungendo parametri alla riga di comando del kernel, ad esempio per systemd: systemd.log_level=debug, per dracut: rd.debug

• Questa risposta è stata modificata 3 giorni fa da Silvan.
• Questa risposta è stata modificata 3 giorni fa da Silvan.
• Questa risposta è stata modificata 3 giorni fa da Silvan.
• Questa risposta è stata modificata 3 giorni fa da Silvan.

[ercolinux]

Intanto ti ringrazio per la sollecitudine nelle risposte. Il PC è relativamente recente (un Lenovo T480s di 5-6 anni fa) ma come hai supposto avevo aggiornato da poco il BIOS e l’aggiornamento dei pacchetti dovrebbe comprendere quelli dei 4-5 giorni precedenti al problema (quindi a grandi linee quelli da 9/10 al 15 di dicembre).

Alla fine  usano il metodo del chroot ho visto che non erano aggiornati correttamente udev, systemd con le relative librerie e libgnutls: reinstallati quelli si avvia fino ad una schermata nera con il puntatore del mouse, nei prossimi giorni tenterò di sistemare il resto dei pacchetti non installati correttamente ma da qui in poi dovrebbe essere più semplice capire cosa c’è di non installato correttamente.

[Autore]

Articoli