Kernel panic

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 6 giorni, 20 ore fa da 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 6 giorni, 13 ore fa da Silvan.
• Questa risposta è stata modificata 6 giorni, 13 ore fa da Silvan.
• Questa risposta è stata modificata 6 giorni, 13 ore fa da Silvan.
• Questa risposta è stata modificata 6 giorni, 13 ore fa da Silvan.