Come installare l’ultimo kernel Linux su Ubuntu 20.04 via PPA

Perché toccare il kernel su Ubuntu 20.04 e quando non farlo

Su Ubuntu 20.04 il kernel fornito dal canale LTS è scelto per stabilità, non per inseguire l’ultima release disponibile. In ambiente server questo è un vantaggio, non un limite: riduce il rischio di regressioni su storage, rete, moduli DKMS e driver out-of-tree. Il motivo per installare un kernel più recente via PPA deve quindi essere concreto: supporto hardware mancante, bug già corretti a monte, miglioramenti su filesystem o networking, oppure necessità di una versione minima richiesta da un componente specifico.

Se il sistema è in produzione, il punto non è “avere il kernel più nuovo”, ma misurare il beneficio e limitare il blast radius. Un cambio kernel tocca il boot, i moduli, il comportamento del driver grafico o NIC, i pacchetti DKMS e la catena di avvio. Per questo l’approccio corretto è: identificare la versione target, verificare che il repository sia affidabile, installare in modo reversibile e lasciare sempre un kernel precedente avviabile dal menu GRUB.

Quale PPA usare e perché il nome conta

Per Ubuntu 20.04 la strada più comune è il PPA dei kernel mainline/Ubuntu Kernel Team pubblicato da Launchpad, spesso usato per test o per esigenze specifiche. Non va confuso con i kernel custom di terze parti: qui l’obiettivo è restare il più possibile vicino al ramo Ubuntu, evitando build artigianali che complicano supporto e rollback.

Il rischio principale non è solo installare un kernel nuovo, ma installare un kernel nuovo senza il corrispondente set di moduli o senza verificare la compatibilità con Secure Boot e DKMS. Se usi moduli proprietari, ZFS, VirtualBox, VMware, driver GPU o agent di sicurezza che si appoggiano a moduli kernel, la verifica va fatta prima di riavviare. Se mancano dati su quali moduli siano in uso, quello è il gap da chiudere con lsmod, dkms status e un controllo dei log di boot.

Verifiche minime prima del cambio

Prima di installare, raccogliere lo stato attuale evita diagnosi alla cieca se qualcosa non parte dopo il reboot. In pratica servono tre cose: kernel attivo, moduli critici e possibilità di tornare indietro. Su una macchina con accesso SSH, non dare per scontato che un kernel nuovo sia “solo un pacchetto in più”: se il server è remoto e unico, devi avere console out-of-band, snapshot o almeno accesso al provider per scegliere un kernel precedente in boot.

Esegui questi controlli:

uname -r
lsb_release -a
apt policy linux-image-generic linux-generic
lsmod | head
sudo dkms status

Il risultato atteso è semplice: conosci la versione in esecuzione, vedi quale meta-pacchetto kernel è installato e sai se ci sono moduli DKMS da ricompilare. Se dkms status mostra errori o moduli non compilati, fermati qui e risolvi prima quello: un kernel nuovo può evidenziare un problema già presente, ma non lo crea “per magia”.

Aggiungere il PPA del kernel senza sporcare il sistema

L’operazione va fatta con il minimo indispensabile. Aggiungi il repository, aggiorna gli indici e verifica che il pacchetto che ti interessa sia davvero disponibile. Non installare “a sentimento” un pacchetto visto in una guida vecchia: i nomi cambiano, alcuni kernel sono build specifiche per hardware enablement, altri sono mainline, altri ancora sono meta-pacchetti che trascinano dipendenze diverse.

sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update
apt search linux-image | grep -E '6\.|5\.'

Se il PPA non è quello previsto dal tuo contesto, non forzare. Il punto è usare un archivio che esponga chiaramente i pacchetti del kernel desiderato e che sia coerente con Ubuntu 20.04. Quando il repository è aggiunto, controlla la provenienza con apt policy prima di installare: ti dice da quale origine arriveranno i pacchetti e se stai davvero usando il PPA o il ramo ufficiale.

apt policy linux-image-unsigned-6.5.0-xx-generic
apt policy linux-headers-6.5.0-xx-generic

Se il nome esatto della versione non è noto, il gap va chiuso leggendo l’elenco disponibile nel browser del PPA o con apt-cache madison. In ambienti controllati, la versione target si sceglie prima del change, non durante.

Installazione del kernel: pacchetti da prendere e ordine corretto

Su Ubuntu, il kernel non è un singolo pacchetto isolato. In genere servono immagine, headers e, in alcuni casi, moduli extra. Se usi DKMS, gli headers sono obbligatori. Se stai aggiornando una macchina server, evita di rimuovere il kernel precedente finché non hai verificato il boot del nuovo.

L’ordine sensato è questo: installi il nuovo kernel, lasci il vecchio intatto, aggiorni GRUB se necessario e solo dopo pianifichi il riavvio. Esempio, assumendo una versione specifica già individuata nel repository:

sudo apt install linux-headers-6.5.0-xx linux-headers-6.5.0-xx-generic linux-image-unsigned-6.5.0-xx-generic linux-modules-6.5.0-xx-generic

Su alcuni repository il pacchetto può essere firmato o unsigned in modo diverso. Qui non si improvvisa: leggi il nome esatto esposto dal PPA e installa i pacchetti corrispondenti. Se il sistema usa Secure Boot, un kernel unsigned può non avviarsi. In quel caso o disabiliti temporaneamente Secure Boot dal firmware, o usi un kernel firmato e coerente con la policy dell’ambiente. Non c’è una scorciatoia pulita: la firma conta davvero al boot.

Secure Boot, moduli DKMS e driver fuori albero

È qui che molte installazioni “andate lisce” in realtà si rompono al riavvio. Il kernel parte, ma uno o più moduli non si caricano. Oppure il kernel non parte affatto perché la catena di trust non lo accetta. Se il server usa moduli DKMS, ricompilali e controlla l’esito prima del reboot finale.

sudo dkms autoinstall
sudo journalctl -k -b --no-pager | tail -n 100

Se dkms autoinstall fallisce, il log dice quale modulo ha rotto. Le cause tipiche sono headers mancanti, incompatibilità con l’API del nuovo kernel o toolchain non allineata. In questi casi non insistere con reboot ripetuti: risolvi il modulo, poi ripeti la compilazione. Se usi driver NVIDIA, ZFS o virtualizzazione, controlla anche i log specifici del pacchetto e non solo il journal generico.

Per un controllo rapido dei moduli caricati dopo il boot, il comando utile è:

lsmod | sort | less

Non è un comando “magico”, ma aiuta a confrontare il set di moduli prima e dopo. Se ti manca un modulo atteso, il problema è da cercare nel pacchetto, nel firmware o nella policy di Secure Boot, non nel solo servizio applicativo che dopo smette di vedere la rete o il filesystem.

Riavvio controllato e verifica del kernel attivo

Il reboot è il momento in cui il change diventa reale. Se sei in remoto, tieni aperta una sessione secondaria, una console del provider o un canale di accesso alternativo. Dopo il riavvio, la prima verifica è banale ma decisiva: il kernel in esecuzione deve essere quello installato. Non fermarti al fatto che il server “sia tornato su”.

uname -r
cat /proc/version
systemd-analyze time

uname -r conferma la versione effettiva. cat /proc/version dà un ulteriore riscontro sul build string. systemd-analyze time aiuta a vedere se il boot è peggiorato in modo anomalo, utile quando il nuovo kernel introduce attese su storage o driver. Se il boot è diventato sensibilmente più lento, non ignorarlo: spesso è il primo segnale di un modulo che va in timeout o di un device che cambia enumerazione.

Come tornare indietro senza improvvisare

Il rollback non si improvvisa dopo un boot fallito. Va preparato prima. Il kernel precedente deve restare installato e selezionabile da GRUB. Se il nuovo kernel crea problemi, riavvia sul precedente, non cancellare nulla e poi fai analisi. La rimozione dei pacchetti del kernel nuovo si fa solo dopo aver confermato che il sistema è stabile con il vecchio o dopo aver deciso che il nuovo non è adatto.

sudo apt remove linux-image-6.5.0-xx-generic linux-headers-6.5.0-xx linux-headers-6.5.0-xx-generic linux-modules-6.5.0-xx-generic
sudo update-grub

La rimozione è il punto in cui il blast radius si restringe, ma resta una modifica di sistema. Prima di eseguire il purge, verifica con dpkg -l | grep 6.5.0-xx che stai togliendo solo i pacchetti del kernel indesiderato e non meta-pacchetti utili. Se il sistema usa un bootloader gestito dal provider o un ambiente cloud con kernel selezionabile dal pannello, il rollback può essere più rapido dal lato console che via SSH: in quel caso preferisci la via che riduce il rischio operativo.

Gestione pulita dei kernel vecchi

Una volta validato il kernel nuovo, puoi decidere quanto storico tenere. In server con spazio disco limitato ha senso evitare accumuli inutili, ma non partire con la pulizia automatica finché non hai almeno un kernel di fallback affidabile. Il pacchetto unattended-upgrades o la manutenzione periodica possono rimuovere vecchie versioni, ma su macchine critiche è meglio farlo con controllo esplicito.

Controlla i kernel installati con:

dpkg -l | grep -E 'linux-image|linux-headers|linux-modules' | awk '{print $2, $3}'

Se trovi molti kernel inutilizzati, pianifica una finestra di manutenzione e rimuovili in modo esplicito, lasciando almeno un kernel noto funzionante. Questo riduce il rischio di riempire /boot, che altrimenti può bloccare futuri aggiornamenti. Un /boot pieno non è un dettaglio: può impedire l’installazione di un kernel di sicurezza proprio quando serve.

Errori tipici e come leggerli senza perdere tempo

Se dopo l’installazione il sistema non si avvia, i casi più comuni sono pochi: Secure Boot che rifiuta il kernel, modulo DKMS non compilato, headers sbagliati, spazio insufficiente in /boot, oppure incompatibilità con un driver esterno. Il log da guardare subito è il kernel ring buffer del boot precedente o corrente.

journalctl -k -b -1 --no-pager | tail -n 200
journalctl -b --no-pager | grep -iE 'dkms|secure|module|firmware|fail'

Se il boot precedente mostra errori legati a firmware mancanti o device non inizializzati, il problema potrebbe non essere il kernel in sé ma il modo in cui quel kernel gestisce l’hardware. Se invece il log punta a moduli non caricati, la strada è la ricompilazione o l’adeguamento del pacchetto esterno. Se il problema è lo spazio, libera /boot solo dopo aver verificato quali versioni puoi davvero eliminare.

Procedura pratica consigliata in ambiente server

In un server Ubuntu 20.04 che deve restare online, la sequenza più pulita è questa: controlli lo stato attuale, identifichi la versione target, installi i pacchetti del kernel e degli headers, ricompili i moduli esterni, riavvii, verifichi il boot e solo alla fine decidi se rimuovere il vecchio kernel. È una sequenza noiosa, ma è proprio la noia che riduce gli incidenti.

1. Verifica kernel attivo e moduli esterni con uname -r e dkms status.
2. Aggiungi il repository del kernel e aggiorna gli indici con apt update.
3. Installa immagine, headers e moduli della versione scelta.
4. Ricompila i moduli DKMS con dkms autoinstall.
5. Riavvia e controlla uname -r e i log del boot.
6. Solo dopo la validazione, valuta la rimozione dei kernel obsoleti.

Se devi documentare il change in modo operativo, conserva la versione prima/dopo, l’output di uname -r, l’elenco dei moduli DKMS e il riferimento al repository usato. Sono i quattro elementi che servono davvero quando, due giorni dopo, qualcuno chiede perché il nodo è stato aggiornato e come si torna indietro.

Checklist finale prima di chiudere il change

Un cambio kernel ben fatto non si misura solo dal fatto che il sistema riparte. Va chiuso con verifiche di servizio: rete su, filesystem montati, agent di monitoraggio attivi, moduli esterni caricati, log senza errori ripetuti. Se il server ospita database, storage distribuito o hypervisor, aggiungi un controllo applicativo specifico perché il kernel può cambiare tempi di I/O, latenza e comportamento dei driver.

• Kernel attivo: uname -r corrisponde alla versione attesa.
• Moduli critici: lsmod e dkms status non mostrano errori.
• Boot sano: journalctl -b --no-pager non contiene failure ripetuti legati a firmware, storage o driver.
• Rollback pronto: il kernel precedente è ancora installato e selezionabile da GRUB o dal pannello del provider.

Assunzione operativa: il sistema è un Ubuntu 20.04 server con accesso amministrativo, repository affidabili già approvati e necessità reale di un kernel più recente; se c’è Secure Boot o moduli DKMS, la verifica va fatta prima del reboot.