1 16/05/2026 10 min

Kernel 5.19 su Ubuntu 22.04 e 20.04: quando ha senso e quando no

Installare un kernel Linux 5.19 su Ubuntu 22.04 o 20.04 non è un’operazione da fare “perché sì”. Ha senso se ti serve un supporto hardware più recente, un fix specifico già presente in quella serie o una prova rapida su un bug che non vuoi inseguire con backport e patch locali. In tutti gli altri casi, il kernel fornito da Ubuntu resta la scelta più prudente: è integrato con i pacchetti della distribuzione, riceve aggiornamenti di sicurezza coerenti e riduce il rischio di sorprese su driver, moduli DKMS, virtualizzazione e boot chain.

Qui l’obiettivo non è “sostituire” il kernel della distro in modo permanente senza controllo, ma installare la 5.19 come opzione avviabile, verificare che il sistema parta, e mantenere un rollback semplice al kernel precedente. Questo approccio vale sia per Ubuntu 22.04 sia per 20.04, con una differenza pratica: su 20.04 è più facile incontrare moduli terzi o stack più vecchi che richiedono attenzione extra.

Prima di toccare il boot: cosa verificare

Il punto critico non è l’installazione dei pacchetti in sé, ma la compatibilità del kernel con il tuo ambiente. Se il sistema usa ZFS, driver NVIDIA proprietari, moduli DKMS, cifratura full disk con initramfs personalizzato, o è una VM con strumenti di guest specifici, conviene fermarsi un attimo e raccogliere evidenza. Il rischio non è teorico: il kernel può installarsi correttamente e comunque non avviarsi con il tuo stack applicativo o non caricare un modulo essenziale al boot.

Prima di procedere, annota il kernel in uso e la presenza di moduli esterni. Questi comandi ti danno un quadro minimo:

uname -r
lsmod | head
apt list --installed | grep -E 'nvidia|dkms|zfs|virtualbox|vmware'

Se `uname -r` restituisce un kernel già recente e stabile, la domanda vera è se 5.19 aggiunge qualcosa di misurabile. Se invece stai inseguendo un problema hardware, prepara anche un riferimento al comportamento atteso: device non visto, throughput basso, crash del driver, sospensione rotta, o un bug già riprodotto su una macchina di test.

Metodo consigliato: pacchetti .deb del kernel Ubuntu Mainline

La strada più lineare è installare i pacchetti precompilati della serie mainline 5.19. Ubuntu pubblica i binari del kernel mainline in formato `.deb`, separati per architettura e per componente. Non è il kernel supportato dalla distribuzione, quindi va considerato un change controllato: utile per test, troubleshooting e casi mirati, non come sostituto automatico del kernel LTS di Ubuntu.

Per prima cosa identifica architettura e versione disponibile. Su una macchina x86_64 standard userai quasi certamente `amd64`:

dpkg --print-architecture
lsb_release -a

Il percorso operativo è questo: scarichi i pacchetti corretti, li installi con `dpkg`, risolvi eventuali dipendenze con `apt`, aggiorni l’initramfs se necessario, poi riavvii scegliendo il nuovo kernel dal menu di GRUB. Se qualcosa non torna, torni al kernel precedente senza toccare il resto del sistema.

Installazione kernel 5.19 su Ubuntu 22.04

Su Ubuntu 22.04 la procedura è identica, ma conviene essere ancora più rigorosi sul rollback perché la base di sistema è più recente e spesso più integrata con driver e firmware di terze parti. Prima scarica i pacchetti della serie 5.19 da una sorgente affidabile e coerente con la tua architettura. I nomi dei file cambiano in base alla release patch della serie, ma la struttura resta simile: header, immagine, moduli e moduli extra.

Un esempio operativo, da adattare al numero esatto di build disponibile, è questo:

mkdir -p /tmp/kernel-5.19
cd /tmp/kernel-5.19
wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.19/amd64/linux-headers-5.19.0-051900_5.19.0-051900.202207031731_all.deb
wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.19/amd64/linux-headers-5.19.0-051900-generic_5.19.0-051900.202207031731_amd64.deb
wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.19/amd64/linux-image-unsigned-5.19.0-051900-generic_5.19.0-051900.202207031731_amd64.deb
wget -c https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.19/amd64/linux-modules-5.19.0-051900-generic_5.19.0-051900.202207031731_amd64.deb
sudo dpkg -i *.deb
sudo apt -f install

Il dettaglio importante è `linux-image-unsigned`: i kernel mainline non sono firmati nello stesso modo dei kernel Ubuntu supportati. Se usi Secure Boot, qui c’è il primo punto di attenzione serio. Su molte macchine l’installazione va a buon fine ma il boot fallisce perché il firmware UEFI rifiuta il kernel non firmato. In quel caso hai due opzioni: disabilitare Secure Boot per il test oppure firmare il kernel e i moduli con una tua chiave MOK, se il tuo processo lo prevede già.

Dopo l’installazione verifica che il pacchetto sia presente e che GRUB lo veda:

dpkg -l | grep 5.19.0-051900
grep -n '5.19.0-051900' /boot/grub/grub.cfg

Se il kernel compare in GRUB ma il sistema non parte, il problema non è più “installazione fallita”: è boot, firma, initramfs o modulo esterno. A quel punto il controllo va fatto sul layer successivo, non rifacendo la stessa installazione alla cieca.

Installazione kernel 5.19 su Ubuntu 20.04

Su Ubuntu 20.04 la procedura è uguale, ma l’attenzione ai moduli terzi è ancora più utile. Molti ambienti 20.04 hanno una combinazione di kernel LTS, DKMS e driver vendor maturata nel tempo; portare dentro una mainline nuova senza test può rompere la catena di caricamento di moduli che oggi dai per scontati. Se la macchina fa da host per servizi critici, meglio fare il primo avvio in finestra di manutenzione e con accesso console, non solo SSH.

Anche qui il flusso è: scarico, installazione, verifica, reboot. La differenza pratica non è nei comandi, ma nella disciplina operativa. Se usi driver NVIDIA o moduli come VirtualBox, VMware, ZFS o WireGuard compilato localmente, controlla subito che DKMS abbia ricostruito tutto per il nuovo kernel:

dkms status
journalctl -k -b | grep -iE 'dkms|nvidia|zfs|virtualbox|vmware'

Se `dkms status` mostra errori di build, non forzare il riavvio “finché si sistema”. Prima leggi il log del modulo che fallisce, perché spesso il problema è banalmente un header non allineato, una API kernel cambiata o una dipendenza mancante. In quel caso il kernel può anche essere corretto, ma il sistema resta inutilizzabile per l’assenza di un modulo indispensabile.

Gestione di Secure Boot, GRUB e fallback

Il punto più sottovalutato è il fallback. Un kernel sperimentale va sempre installato in modo che il vecchio kernel resti avviabile e selezionabile. Su Ubuntu questo succede di default, ma devi comunque controllare che GRUB non sia stato alterato in modo da nascondere il menu o avviare automaticamente l’ultimo kernel disponibile senza scelta manuale.

Per avere un menu utile durante il test, puoi temporaneamente aumentare la visibilità del boot menu. Prima fai un backup della configurazione:

sudo cp /etc/default/grub /etc/default/grub.bak.$(date +%F)

Poi verifica i parametri legati a GRUB, senza inventare valori a caso. I campi interessanti sono `GRUB_TIMEOUT_STYLE` e `GRUB_TIMEOUT`. Se vuoi far comparire il menu per scegliere il kernel, la modifica va fatta con criterio e poi rigenerata la configurazione:

sudoedit /etc/default/grub
sudo update-grub

Se il sistema usa Secure Boot, non dare per scontato che il kernel mainline parta. Il controllo più rapido è osservare il comportamento all’avvio e, se serve, leggere i log del boot precedente da un kernel funzionante:

journalctl -b -1 -k | tail -n 100

Se non c’è traccia del kernel nuovo e il sistema torna sempre al vecchio, spesso il firmware ha rifiutato il boot. In quel caso il rollback è immediato: selezioni il kernel precedente da GRUB e rimani su quello finché non hai risolto la firma o non hai disabilitato Secure Boot per il test.

Verifica dopo il riavvio: non basta che il sistema “salga”

Un boot riuscito non basta. Devi verificare che il nuovo kernel sia davvero in uso e che i servizi importanti siano sani. Il controllo base è `uname -r`, ma va affiancato al comportamento dell’hardware e dei servizi. Il kernel giusto può convivere con un sottosistema rotto, e il sintomo arriva più tardi sotto forma di rete instabile, storage degradato o crash di un demone DKMS.

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

Se il tuo obiettivo era risolvere un problema hardware, prova subito la funzione che ti interessava: scheda Wi‑Fi, controller NVMe, GPU, passthrough, suspend/resume, virtualizzazione. Un kernel nuovo che non cambia il comportamento osservabile non ti ha dato ancora una prova utile; un kernel nuovo che introduce errori nei log merita rollback immediato.

Per una verifica più mirata puoi osservare i messaggi del kernel in tempo reale mentre attivi il componente critico:

sudo dmesg -wH

Questo è particolarmente utile per driver che falliscono in silenzio o per moduli che si caricano ma registrano warning solo al primo uso. Il criterio non deve essere “non vedo errori gravi”, ma “vedo il comportamento atteso e non vedo regressioni nuove”.

Rollback pulito al kernel precedente

Il rollback è il motivo per cui questa procedura è accettabile in produzione solo se pianificata. Se il kernel 5.19 non soddisfa i requisiti, torni al kernel precedente dal menu GRUB o imposti temporaneamente il kernel stabile come default. Prima di rimuovere nulla, verifica che il vecchio kernel sia ancora installato e avviabile.

dpkg -l | grep '^ii  linux-image'
awk -F"'" '/menuentry / {print $2}' /boot/grub/grub.cfg | grep -E 'Ubuntu|Advanced options'

Se vuoi impostare un kernel specifico come default, devi sapere esattamente il nome della voce in GRUB. Non è il momento di fare tentativi distruttivi. In alternativa, puoi semplicemente riavviare e scegliere manualmente il kernel precedente nel sottomenu “Advanced options for Ubuntu”.

Solo dopo aver confermato che il sistema gira stabilmente sul kernel vecchio ha senso rimuovere i pacchetti 5.19. Anche qui il rischio va dichiarato: la rimozione libera spazio e pulisce il sistema, ma se sbagli versione puoi eliminare componenti ancora utili. Per questo conviene usare il nome esatto del pacchetto e controllare prima cosa stai per togliere:

dpkg -l | grep 5.19.0-051900
sudo apt remove linux-image-unsigned-5.19.0-051900-generic linux-modules-5.19.0-051900-generic linux-headers-5.19.0-051900-generic linux-headers-5.19.0-051900

Assunzione operativa: il kernel 5.19 viene installato come test o come workaround temporaneo, con accesso console e con il kernel precedente ancora disponibile per il boot.

Errori tipici e come leggerli senza perdere tempo

Se `dpkg -i` segnala dipendenze mancanti, non è necessariamente un problema del kernel: spesso basta `apt -f install` per chiudere il ciclo. Se invece `apt` non trova un pacchetto, di solito hai scaricato un file non coerente con la release o con l’architettura. Se il boot fallisce subito dopo GRUB, il sospetto va su Secure Boot, initramfs o moduli esterni. Se il boot arriva ma mancano periferiche, il problema è quasi sempre nel sottosistema driver o nel firmware.

Un controllo utile, spesso trascurato, è l’initramfs del kernel installato. Se il pacchetto è presente ma l’immagine di avvio non è stata generata correttamente, il sistema può fermarsi prima di montare il root filesystem. In quel caso il log del boot e la presenza dei file in `/boot` sono più informativi di mille tentativi di reinstallazione:

ls -lh /boot | grep 5.19.0-051900
lsinitramfs /boot/initrd.img-5.19.0-051900-generic | head

Se `lsinitramfs` fallisce o il file non esiste, hai una pista concreta. Se il file esiste ma il kernel non parte, il problema è più a valle. Questo è il punto in cui conviene tornare ai log del boot precedente e al comportamento del firmware, invece di cambiare tre variabili insieme.

Scelta pratica: tenere 5.19, aggiornare o restare su LTS

Una volta fatto il test, la decisione dovrebbe essere semplice. Se 5.19 risolve un problema reale e non introduce regressioni, puoi tenerlo come kernel operativo finché ti serve, ma con la consapevolezza che non è la linea supportata standard della tua release Ubuntu. Se non cambia nulla, torna al kernel LTS della distro e chiudi il test. Se migliora un solo aspetto ma rompe un altro sottosistema, il costo del compromesso è probabilmente troppo alto per l’uso quotidiano.

La regola pratica è questa: un kernel nuovo ha senso quando puoi misurare il beneficio e puoi tornare indietro in pochi minuti. Se non hai entrambe le cose, non è un upgrade, è un esperimento lasciato in produzione.