1 19/05/2026 10 min

Ubuntu 20.04 LTS nasce con un kernel della serie 5.4, stabile e conservativo. Installare il kernel Linux 5.8 ha senso solo se serve una funzionalità specifica: supporto hardware più recente, fix mirati, test di compatibilità o validazione su un ambiente controllato. Non è un aggiornamento da fare “perché più nuovo”: su una LTS la regola è cambiare kernel solo con un motivo chiaro e con un piano di ritorno già pronto.

Qui il punto non è solo come installarlo, ma come farlo senza perdere controllo. Il kernel tocca boot, driver, moduli, storage, rete e, nei casi peggiori, la possibilità stessa di avviare il sistema. Per questo la procedura corretta parte da un controllo dell’hardware e finisce con la verifica del bootloader e del rollback.

Quando ha senso passare al kernel 5.8

Il kernel 5.8 può essere utile se stai inseguendo una compatibilità specifica: schede Wi-Fi o NIC recenti, controller NVMe, GPU, filesystem o driver che nella 5.4 non sono presenti o sono troppo vecchi. In ambienti server, però, spesso il problema vero non è il kernel “vecchio”, ma il modulo mancante o il driver del vendor non allineato. Prima di cambiare kernel, conviene capire se il bisogno è reale.

Se il nodo è in produzione, considera il blast radius: un kernel nuovo può cambiare il comportamento di rete, storage e virtualizzazione. Se il sistema fa da host KVM, storage server, nodo Docker o macchina con driver proprietari, testalo prima in una copia del profilo reale. Il rollback deve restare semplice: avvio del kernel precedente dal menu GRUB, senza toccare dati o configurazioni applicative.

Prima di toccare il boot: controlli minimi

Fai questi controlli prima di installare qualsiasi pacchetto kernel non standard. Servono a evitare di confondere un problema di pacchetti con un problema di repository o di firma.

  • Verifica la release: lsb_release -a o cat /etc/os-release.
  • Verifica il kernel attuale: uname -r.
  • Controlla spazio su disco: df -h /boot /.
  • Controlla l’architettura: dpkg --print-architecture.
  • Se hai Secure Boot attivo, metti in conto il tema della firma dei moduli.

Se /boot è quasi pieno, fermati prima. Un’installazione kernel fallita per spazio insufficiente lascia il sistema in uno stato scomodo: pacchetti parziali, initramfs incompleto, GRUB non aggiornato. In pratica, prima liberi spazio o rimuovi kernel vecchi in modo controllato, poi procedi.

Metodo più pulito: usare i pacchetti .deb del kernel 5.8

Su Ubuntu 20.04 il metodo più semplice è installare i pacchetti del kernel tramite file .deb. Questa strada è preferibile al compilare da sorgenti, perché mantiene la gestione standard dei pacchetti, il registro in dpkg e il normale flusso di aggiornamento/rollback.

Per il kernel 5.8 devi procurarti i pacchetti adatti alla tua architettura, di solito amd64. Servono almeno il kernel image, i moduli e gli header. In molti casi si installano anche i pacchetti “all” per gli header generici. Il set tipico è questo:

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8/amd64/linux-headers-5.8.0-xxxx_all.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8/amd64/linux-headers-5.8.0-xxxx_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8/amd64/linux-modules-5.8.0-xxxx_amd64.deb
wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.8/amd64/linux-image-unsigned-5.8.0-xxxx_amd64.deb

Il suffisso xxxx cambia in base al build esatto. Non inventarlo: apri il repository della serie 5.8 e prendi il numero di build corretto per la tua architettura. Se il pacchetto non esiste o l’URL è sbagliato, la verifica è immediata: wget restituisce errore 404 e non devi andare oltre.

Una volta scaricati i file, installali con dpkg. Qui il punto non è “forzare” ma lasciare a dpkg il controllo delle dipendenze mancanti, che poi puoi risolvere in modo pulito con apt.

sudo dpkg -i linux-headers-5.8.0-xxxx_all.deb \
            linux-headers-5.8.0-xxxx_amd64.deb \
            linux-modules-5.8.0-xxxx_amd64.deb \
            linux-image-unsigned-5.8.0-xxxx_amd64.deb

Se dpkg segnala dipendenze mancanti, chiudile con:

sudo apt -f install

Questo passaggio è normale, ma va fatto con attenzione: prima controlla quali pacchetti vuole aggiungere o rimuovere. Se il resolver propone di disinstallare componenti critici, fermati e rivedi il pacchetto scaricato o il mix di repository usato.

Verifica che il kernel sia davvero installato

Dopo l’installazione, non dare per scontato che il sistema stia già usando il kernel nuovo. Devi verificare tre cose: presenza dei pacchetti, entry del bootloader e boot effettivo nel nuovo kernel.

dpkg -l | grep 5.8
ls -l /boot | grep 5.8
uname -r

Il primo comando ti dice se i pacchetti sono installati. Il secondo conferma che i file in /boot ci siano davvero, inclusi vmlinuz, initrd.img e i file di configurazione. Il terzo è il controllo finale, ma va eseguito solo dopo il reboot.

Per vedere se GRUB ha ricevuto la nuova voce, puoi controllare la configurazione generata:

grep -n "5.8" /boot/grub/grub.cfg

Se la voce non appare, il problema non è il kernel ma la generazione del menu. In quel caso verifica /etc/default/grub e gli script in /etc/grub.d/, poi rigenera con sudo update-grub.

Impostare il boot sul kernel 5.8

Su Ubuntu, dopo l’installazione, il sistema può continuare ad avviarsi sul kernel precedente se il boot order di GRUB non cambia o se la voce nuova non è quella predefinita. Se vuoi testare il 5.8 in modo controllato, puoi fare un avvio una tantum oppure impostarlo come default.

Per il test una tantum, riavvia e scegli la voce del kernel 5.8 nel menu GRUB. Se il server è remoto, questa è la scelta più prudente: ti lascia il boot precedente disponibile senza modificare il default permanente.

Se invece vuoi renderlo predefinito, prima individua il nome esatto della voce di menu. Poi usa grub-set-default o, più spesso, imposta la stringa in /etc/default/grub con GRUB_DEFAULT=saved e selezione esplicita della voce. Dopo la modifica, rigenera la configurazione:

sudo update-grub

Non cambiare il default alla cieca. Se sbagli il nome della voce, GRUB può tornare al comportamento standard o, peggio, non fare ciò che ti aspetti. Il controllo pratico è semplice: riavvii, poi verifichi uname -r. Se non corrisponde al 5.8, il boot non è andato sulla voce giusta.

Problemi tipici dopo il riavvio

Il caso più comune è l’avvio corretto ma con uno o più driver non caricati. Può succedere con moduli DKMS, driver di terze parti, storage RAID, VPN, agent di sicurezza o componenti per GPU. Il sintomo pratico varia: rete assente, dischi non montati, servizi che non partono, schermo nero su desktop, o rallentamenti anomali in fase di boot.

Per capire se il kernel sta caricando errori di modulo, guarda il journal del boot corrente:

journalctl -b -p err
journalctl -b | grep -iE "module|dkms|firmware|taint|fail"

Se trovi messaggi su firmware mancante, il kernel non è il problema principale: manca il pacchetto firmware o il driver si aspetta file non presenti. Se invece vedi errori DKMS, devi ricompilare i moduli per il nuovo kernel. In molti casi la correzione è semplice, ma va fatta con cognizione: prima identifichi il modulo, poi verifichi che il pacchetto DKMS sia compatibile con il 5.8.

Un controllo utile per la rete è questo:

ip a
ip r
systemctl --failed

Se l’interfaccia non compare, il problema può essere nel driver della NIC o nella naming policy. Se l’interfaccia c’è ma manca la route, il kernel non è il solo sospetto: guarda la configurazione di NetworkManager, systemd-networkd o il layer cloud-init, se presente.

Secure Boot, moduli unsigned e impatto operativo

Su molti sistemi Ubuntu il tema più sottovalutato è Secure Boot. I pacchetti mainline del kernel spesso includono l’immagine unsigned. Questo non è un dettaglio estetico: se Secure Boot è attivo e non hai una catena di firma compatibile, il boot può fallire o i moduli possono non essere caricati.

La verifica minima è vedere se Secure Boot è attivo dal firmware o da mokutil:

mokutil --sb-state

Se il risultato indica che Secure Boot è abilitato, devi decidere se firmare i moduli, usare una procedura compatibile con MOK oppure disabilitare temporaneamente Secure Boot sul singolo host. La scelta dipende dalla policy del sistema. Su server gestiti, la via corretta è seguire la procedura di firma prevista e non aggirarla in modo permanente.

Dal punto di vista della sicurezza, cambiare kernel aumenta anche la superficie di verifica: devi controllare che i driver di rete, storage e sicurezza siano ancora quelli attesi. Dopo il reboot, un audit minimo è confrontare la versione del kernel con i moduli caricati:

uname -r
lsmod | head
modinfo nome_modulo

Rollback: come tornare indietro senza fare danni

Il rollback migliore è quello che non richiede interventi d’emergenza: scegli il kernel precedente dal menu GRUB, verifichi che il sistema salga, poi decidi se lasciare o rimuovere il 5.8. Questo è il vero motivo per cui conviene non cancellare subito il kernel precedente.

Se devi rimuovere il kernel 5.8 perché ha introdotto problemi, fallo solo dopo aver confermato che il kernel precedente è avviabile. Il flusso corretto è:

  1. Riavvia e seleziona il kernel precedente in GRUB.
  2. Controlla uname -r e assicurati che il sistema sia stabile.
  3. Rimuovi i pacchetti 5.8 con apt remove o dpkg -r, senza toccare i kernel in uso.
  4. Rigenera GRUB con sudo update-grub.
  5. Verifica che in /boot non restino riferimenti incoerenti.

Se il problema è più grave e il sistema non sale sul kernel nuovo, non insistere con tentativi casuali. Usa il kernel precedente dal menu, poi raccogli i log del boot fallito. I file utili sono /var/log/boot.log, journalctl -b -1 e gli errori mostrati durante l’avvio. Quella è la base per capire se il guasto è nel driver, nel filesystem, nel firmware o nel bootloader.

Compilare il kernel 5.8 da sorgenti: quando evitarlo

Compilare da sorgenti ha senso solo se ti serve un set di opzioni specifico o una patch non disponibile nei pacchetti precompilati. Per una macchina Ubuntu 20.04 normale, è quasi sempre un costo inutile. Aumenti il rischio di errore, allunghi i tempi e complichi il rollback. Inoltre, perdi parte della semplicità operativa dei pacchetti Debian.

Se però devi farlo, il flusso minimo è sempre lo stesso: installi toolchain e dipendenze, prepari la configurazione, compili, installi i moduli, aggiorni initramfs e GRUB, poi avvii con una finestra di manutenzione. Anche qui il punto non è la procedura in sé, ma il fatto che ogni passaggio deve essere verificabile. Se salti il controllo finale, stai solo spostando il rischio al primo reboot.

Checklist operativa rapida

Se vuoi una sequenza sintetica, questa è quella che userei su un host da trattare con prudenza:

  1. Controlla versione Ubuntu, kernel attuale e spazio su /boot.
  2. Scarica i pacchetti corretti del kernel 5.8 per la tua architettura.
  3. Installa con dpkg -i e chiudi eventuali dipendenze con apt -f install.
  4. Verifica che le entry compaiano in /boot/grub/grub.cfg.
  5. Riavvia e seleziona il kernel 5.8 dal menu GRUB.
  6. Controlla uname -r, log del boot e stato dei servizi critici.
  7. Se qualcosa non torna, rientra nel kernel precedente e conserva i log.

Questa procedura non promette magia: promette controllo. Su una LTS il kernel nuovo non deve solo avviarsi, deve convivere bene con il resto della macchina. Se il 5.8 risolve il problema per cui lo stai installando, bene. Se introduce regressioni, il fatto di avere un rollback già pronto vale più della tentazione di “insistere ancora un po’”.

Assunzione: la macchina è Ubuntu 20.04 LTS su architettura amd64, con accesso amministrativo, e il kernel 5.8 viene installato da pacchetti .deb precompilati invece che da sorgenti.