Come installare il kernel Linux 5.10 su Ubuntu 20.04 LTS

Kernel 5.10 su Ubuntu 20.04 LTS: quando ha senso intervenire

Su Ubuntu 20.04 LTS il kernel predefinito resta una scelta prudente per stabilità e supporto, ma ci sono casi in cui passare a una serie 5.10 è utile: compatibilità hardware più recente, fix su driver specifici, supporto migliore per alcune piattaforme virtuali e comportamento diverso su storage o rete. Il punto non è “aggiornare perché più nuovo”, ma capire se il problema che vuoi risolvere dipende davvero dal kernel e se il rischio di cambiare base di sistema è accettabile.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Qui il contesto è un change controllato, non un intervento da fare alla cieca. Prima di toccare il bootloader conviene sapere quale kernel stai usando, quali pacchetti sono installati, se ci sono moduli DKMS, e soprattutto come tornare indietro se il sistema non sale o perde funzionalità di rete, storage o grafica.

Verifica dello stato attuale e scelta della sorgente del kernel

Su Ubuntu 20.04 hai due strade pratiche: usare i kernel HWE forniti dal repository Ubuntu oppure installare un kernel mainline o specifico, ad esempio 5.10, da pacchetti .deb. La prima opzione è più coerente con il modello LTS, perché resta dentro il ciclo di packaging della distro. La seconda è più flessibile, ma aumenta il carico operativo: devi gestire aggiornamenti, compatibilità e rollback con più attenzione.

Prima verifica il kernel attivo e i pacchetti installati:

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

Atteso: un output che mostri il kernel in uso, per esempio 5.4.x o un HWE più recente, e l’elenco dei pacchetti già presenti. Se il sistema usa già una serie 5.10 tramite HWE o pacchetti equivalenti, non ha senso installare duplicati.

Controlla anche il bootloader e la presenza di più voci nel menu di GRUB, perché il rollback dipende da questo:

grep -n '^GRUB_DEFAULT\|^GRUB_TIMEOUT\|^GRUB_TIMEOUT_STYLE' /etc/default/grub
sudo grep -n "menuentry 'Ubuntu" /boot/grub/grub.cfg | head

Se il timeout è troppo basso o il menu non è visibile, il recupero dopo un boot fallito diventa più scomodo. In un change serio vale la pena lasciare un timeout sufficiente per scegliere il kernel precedente al riavvio.

Metodo consigliato: pacchetti Ubuntu invece di build manuale

Se l’obiettivo è avere kernel 5.10 su Ubuntu 20.04 LTS con il minimo attrito, la via più pulita è usare i pacchetti ufficiali della serie HWE o comunque del repository Ubuntu, non compilare un kernel a mano. Il motivo è semplice: il pacchetto si integra con initramfs, GRUB, moduli extra e aggiornamenti di sicurezza. Una build manuale può funzionare, ma ti lascia con una manutenzione più fragile e un rollback meno lineare.

Su 20.04 la serie HWE si è evoluta nel tempo; a seconda del punto di rilascio e del livello di aggiornamento del sistema, potresti già avere un kernel diverso da 5.4. Verifica quali meta-pacchetti sono disponibili prima di installare tutto a occhi chiusi:

apt-cache search linux-generic-hwe-20.04
apt-cache policy linux-generic-hwe-20.04

Se il repository propone un meta-pacchetto compatibile con 5.10, è la scelta preferibile. In alternativa, se vuoi proprio quel ramo e non un meta-pacchetto che può evolvere, devi verificare la disponibilità dei pacchetti specifici per image, headers e modules.

Installazione del kernel 5.10 con pacchetti .deb

Se hai deciso di procedere con pacchetti specifici, il flusso corretto è: installare immagine, headers e moduli, rigenerare initramfs, aggiornare GRUB e riavviare. Non saltare i controlli; il rischio tipico è installare il kernel senza i moduli necessari o senza un initramfs coerente.

Un esempio di installazione, assumendo che i pacchetti 5.10 siano disponibili nei repository configurati:

sudo apt update
sudo apt install linux-image-5.10.0-*-generic linux-headers-5.10.0-*-generic linux-modules-5.10.0-*-generic

Se usi un pattern con wildcard, verifica con attenzione che il resolver non scelga una variante inattesa. In pratica, dopo l’installazione controlla subito i pacchetti effettivamente installati:

dpkg -l | grep -E '5\.10\.0.*generic' | awk '{print $2, $3}'

Atteso: almeno un pacchetto linux-image, uno linux-headers e, se previsto dalla serie, un pacchetto linux-modules coerente con lo stesso numero di versione. Se uno dei tre manca, fermati e risolvi prima del reboot.

Rigenerazione di initramfs e aggiornamento di GRUB

Su Ubuntu l’installazione dei pacchetti fa molto del lavoro, ma non dare per scontato che tutto sia già pronto. Se hai moduli storage, RAID, LVM, encryption o driver fuori dall’insieme base, conviene forzare un refresh coerente dell’immagine di avvio e della configurazione del bootloader.

Controlla che l’immagine initramfs sia stata generata per il nuovo kernel:

ls -lh /boot/initrd.img-5.10.0-*-generic /boot/vmlinuz-5.10.0-*-generic

Se i file non esistono o hanno dimensioni anomale, rigenera l’initramfs per quella versione e poi aggiorna GRUB:

sudo update-initramfs -c -k 5.10.0-*-generic
sudo update-grub

Il comando update-grub deve mostrare la rilevazione del nuovo kernel e delle relative voci di menu. Se non compare, il problema è prima nel pacchetto installato o nella directory /boot, non nel bootloader in sé.

Se vuoi rendere più facile il rollback, lascia il kernel precedente installato e non cambiare il default di GRUB finché non hai verificato il nuovo boot. In ambienti remoti questo dettaglio fa la differenza tra una correzione rapida e un accesso fisico al server.

Riavvio controllato e verifica post-boot

Il riavvio è il punto in cui il change diventa reale. Prima di farlo, assicurati di avere accesso console o out-of-band se il sistema è remoto, e di sapere come tornare al kernel precedente dal menu di GRUB. In un nodo di produzione senza accesso console, il rischio operativo sale parecchio.

Dopo il reboot, verifica subito il kernel attivo e lo stato dei servizi critici:

uname -r
systemctl --failed
journalctl -b -p err --no-pager | tail -n 50

Atteso: il kernel 5.10 selezionato, nessun servizio in failed e nessun errore ricorrente nel journal del boot corrente. Se compaiono errori su rete, filesystem o moduli, è il momento di decidere se il nuovo kernel è compatibile con l’hardware e con i driver presenti.

Per controllare eventuali problemi legati a driver esterni o moduli DKMS:

dkms status
journalctl -k -b --no-pager | grep -iE 'dkms|failed|taint|module'

Se usi VirtualBox, NVIDIA, ZFS, VMware tools o moduli custom, questo è il punto critico. Un kernel nuovo può avviarsi correttamente ma lasciare qualche componente fuori posto. In quel caso il problema non è il kernel “in generale”, ma il set di moduli esterni che deve essere ricompilato o riallineato.

Rollback: tornare al kernel precedente senza improvvisare

Il rollback deve essere già deciso prima del reboot, non dopo un boot fallito. Se il sistema parte ma il nuovo kernel rompe qualcosa, puoi selezionare il kernel precedente dal menu GRUB e rientrare senza toccare i pacchetti. Se invece il sistema non sale, il percorso dipende dalla console disponibile.

Per vedere quali kernel sono presenti:

dpkg -l | grep -E 'linux-image|linux-headers' | grep 5.10
ls /boot/vmlinuz-* /boot/initrd.img-*

Se vuoi rimuovere il kernel 5.10 dopo aver confermato che non serve, fallo solo quando sei certo che il kernel precedente sia ancora installato e funzionante. In caso contrario stai eliminando la tua uscita di sicurezza.

Rimozione controllata dei pacchetti, con attenzione a non disinstallare un kernel di cui hai ancora bisogno:

sudo apt remove linux-image-5.10.0-*-generic linux-headers-5.10.0-*-generic linux-modules-5.10.0-*-generic
sudo update-grub

Prima di farlo, verifica quale kernel è il default corrente e quale è ancora disponibile nel menu. Se il server è remoto, conserva almeno un kernel precedente fino a quando non hai validato completamente rete, storage, servizi e carico applicativo.

Casistiche che rompono più spesso l’installazione

La prima causa di problemi è lo spazio su /boot. Su sistemi aggiornati a lungo, la partizione può saturarsi con vecchi kernel, e l’installazione del nuovo fallisce a metà. Prima di partire controlla lo spazio disponibile:

df -h /boot
sudo du -sh /boot/*

Se /boot è quasi piena, rimuovi kernel obsoleti ma solo dopo aver identificato con precisione quale versione stai usando e quale vuoi mantenere come fallback. Non fare pulizia aggressiva su un server senza sapere quale immagine è l’ultima valida.

La seconda causa è la mancata compatibilità con moduli esterni. Un driver DKMS che compila su un kernel può fallire su un altro per differenze di API o patch set. In quel caso la soluzione non è “forzare il boot” ma aggiornare il pacchetto del modulo o scegliere una versione di kernel supportata dal vendor.

La terza causa è un GRUB mal configurato, soprattutto su macchine con più dischi, UEFI, catene di boot particolari o configurazioni modificate a mano. Se il sistema non mostra il menu o parte sempre con il kernel sbagliato, verifica la configurazione di default e la presenza delle voci nella partizione EFI o nella configurazione generata.

Approccio pratico per ambienti remoti

Su un server remoto la regola operativa è semplice: prima osservi, poi modifichi, poi validi. Se il nodo ospita servizi critici, pianifica una finestra in cui puoi perdere temporaneamente il servizio e avere comunque un canale di rientro. Non affidarti al solo SSH se non hai un accesso alternativo al console server, all’hypervisor o alla gestione OOB.

Un flusso sensato è questo: verifichi il kernel corrente, controlli spazio e moduli, installi il kernel 5.10, rigeneri initramfs, aggiorni GRUB, lasci intatto il kernel precedente, riavvii, controlli boot e log, poi solo alla fine decidi se rendere permanente il nuovo ramo. Se qualcosa non torna, torni al kernel precedente senza fare ulteriori cambiamenti nel mezzo.

In un ambiente con compliance o baseline rigide, documenta anche la motivazione del change: hardware nuovo, bugfix specifico, requisito software o correzione di un problema osservato. Questo evita installazioni “di manutenzione” che poi diventano difficile da giustificare quando qualcosa cambia nel comportamento del sistema.

Quando fermarsi e non andare oltre

Se il server ha storage critico, moduli proprietari non testati o un ruolo che non consente downtime, non trattare l’installazione del kernel come una routine. In quei casi serve almeno un test su macchina gemella, snapshot o staging prima del passaggio in produzione. Il kernel non è un pacchetto come gli altri: impatta il boot, i driver, la rete e la visibilità del filesystem.

Se invece il problema è un hardware recente che il kernel attuale non riconosce bene, passare a 5.10 può essere un fix ragionevole, ma va validato con metriche concrete: errori nel journal, stabilità della rete, latenza I/O, assenza di OOM e corretto caricamento dei moduli. Senza queste verifiche stai solo spostando il rischio da un punto all’altro.

Assunzione operativa: il sistema è Ubuntu 20.04 LTS con accesso amministrativo, repository Ubuntu configurati correttamente e possibilità di tornare al kernel precedente tramite GRUB o console di emergenza.