OM non si avvia dopo l’aggiornamento al kernel 6.18.38

Il kernel 6.18.33 è disponibile dal 17 luglio tuttavia qui non ci sono riferimenti temporali per poter fare deduzioni utili riguardo all’insorgenza del problema.
Sembra di capire che il kernel 6.18.38 non si avvii neanche dopo aver premuto CTRL-D (sebbene venga riportato solo un warning, però il titolo è “OM non va”).
Sembra invece più certo che l’avvio avvenga correttamente selezionando la versione di kernel 6.18.33 disponibile nel menù di avvio di Grub.
Dopo aver avviato quindi con il kernel 6.18.33 suggerisco di provare a ricreare l’initramfs per il kernel più recente con il seguente comando:
dracut -H -f /boot/initramfs-6.18.38-1mamba-x86_64.img 6.18.38-1mamba-x86_64

• Questa risposta è stata modificata 2 days, 23 hours fa da Silvan.

sudo dracut -H -f /boot/initramfs-6.18.38-1mamba-x86_64.img 6.18.38-1mamba-x86_64

• Questa risposta è stata modificata 2 days, 21 hours fa da Silvan.

Per proseguire con la richiesta di supporto si ritiene utile oppure necessario conoscere i codici UUID degli storage visti dal sistema. Ciò è possibile copiando l’output fornito dai seguenti comandi:

grep -i uuid /etc/fstab

sudo grep -E 'menuentry|root=UUID' /boot/grub/grub.cfg

sudo bikid | grep -i uuid

Questi andranno confrontati con il codice completo che fa parte del messaggio di avvio citato warning: /dev/disk/by-uuld/…… does not exist..

Qualora non risultassero stranezze negli UUID tra i vari files e messaggi, il problema potrebbe risiedere nella mancanza del driver dello storage nell’initramfs del kernel più recente, questo potrebbe però più essere imputabile al fallimento della modalità host-only (-H) di dracut piuttosto che al fatto che tra il kernel 6.18.33 e 6.18.38 possa essere cambiato qualcosa a questo livello.

• Questa risposta è stata modificata 1 day, 11 hours fa da Silvan.

L’UUID in fstab (639ed944-...) coincide esattamente con il root=UUID= di tutte le voci grub, comprese quelle per 6.18.38. Quindi il problema non è un disallineamento fstab/grub, il riferimento è corretto.

È da controverificare che comunque l’errore all’avvio si riferisca esattamente all’UUID 639ed944-0cd9-4bad-9b25-d77739d27c77, ovvero non ad esempio all’UUID della partizione /home, in tal caso il problema sarebbe altro.

Questo fa pensare a un problema di driver: il kernel 6.18.38 (o il suo initramfs) probabilmente non riesce a rilevare il disco/controller prima di montare /. Prossimo passo, prova a:

1) Trovare quale driver serve per il disco di root (dal kernel funzionante):
sudo journalctl -k -b -1 | grep -iE 'ahci|nvme|scsi|virtio_blk'
(il -b -1 prende il boot precedente; se nel frattempo hai già riavviato con 6.18.33, usa -b 0 oppure omettilo)

Una volta identificato il driver si può anche fare una ricerca nel Changelog del kernel per eventuali regression introdotte upstream.

2) Verificare se quel modulo è incluso nell’initramfs 6.18.38 rigenerato:
lsinitrd -m /boot/initramfs-6.18.38-1mamba-x86_64.img | grep -iE 'ahci|nvme|scsi|virtio_blk'

3) Confrontarlo con quello che sicuramente c’è nella 33:
lsinitrd -m /boot/initramfs-6.18.33-2mamba-x86_64.img | grep -iE 'ahci|nvme|scsi|virtio_blk'

Se il modulo manca nella 38, il problema è a monte: o il pacchetto kernel-modules per 6.18.38 non lo include, o dracut in hostonly non lo rileva (es. disco su USB/dock, o driver caricato solo da initrd precedente). In tal caso puoi provare a rigenerare forzando l’inclusione esplicita:
dracut -H -f --add-drivers "" /boot/initramfs-6.18.38-1mamba-x86_64.img 6.18.38-1mamba-x86_64

• Questa risposta è stata modificata 1 day, 1 hour fa da Silvan.
• Questa risposta è stata modificata 1 day, 1 hour fa da Silvan.