Aggiornare Ubuntu 22.04 a 22.10: guida completa

Passare da Ubuntu 22.04 LTS a 22.10 non è un aggiornamento “di routine” come un point release: cambia il ramo di supporto, introduce versioni più recenti di kernel, librerie e servizi, e soprattutto porta con sé un ciclo di vita più corto. Se l’obiettivo è stabilità operativa, il salto va valutato con attenzione; se invece serve una release intermedia per testare hardware nuovo, stack recenti o compatibilità applicative, il percorso è lineare ma va eseguito con disciplina.

La regola pratica è semplice: prima si controlla lo stato del sistema, poi si prepara un punto di ritorno, infine si esegue l’upgrade con il tool ufficiale. Evita approcci “creativi” con repository misti o pacchetti pinning non documentati: sono il modo più rapido per ottenere dipendenze spezzate e un sistema difficile da recuperare.

Quando ha senso fare l’upgrade

Ubuntu 22.04 è una LTS: è pensata per restare in produzione a lungo, con aggiornamenti di sicurezza e una base abbastanza conservativa. Ubuntu 22.10, al contrario, è una release intermedia: introduce novità più fresche, ma il supporto è più breve. Questo significa che il salto ha senso solo se hai una ragione concreta, per esempio:

• hai bisogno di un kernel o di driver più recenti per hardware specifico;
• devi validare compatibilità con una nuova versione di toolchain, librerie o desktop stack;
• stai preparando un ambiente di test allineato a software più nuovo che non gira bene su 22.04;
• hai una policy interna che prevede il collaudo delle release intermedie prima di un successivo salto.

Se invece il sistema ospita servizi critici e non hai una necessità tecnica chiara, la scelta sensata è restare su 22.04 e pianificare un upgrade diretto verso una LTS successiva. È un dettaglio operativo, non ideologico: meno cambi di base fai, meno variabili introduci.

Verifiche prima di toccare il sistema

Prima di lanciare l’upgrade, verifica tre cose: spazio disco, stato dei pacchetti e configurazione dei repository. Se una di queste è fuori posto, l’upgrade può fermarsi a metà e lasciarti con un sistema incoerente.

Controlla il layout delle partizioni e lo spazio disponibile:

df -h
lsblk

In pratica devi avere margine su /, su /boot se separato, e soprattutto spazio sufficiente per scaricare e scompattare i pacchetti. Se il disco è quasi pieno, libera spazio prima di procedere. L’upgrade non ama le situazioni “al limite”.

Verifica che il sistema sia aggiornato e che non ci siano pacchetti bloccati:

sudo apt update
apt list --upgradable
apt-mark showhold

Se apt-mark showhold restituisce pacchetti in hold, annotali. Un hold su librerie di base o su componenti di sistema può impedire la transizione pulita. Non rimuoverlo “a caso”: va capito perché era stato impostato.

Controlla anche i repository di terze parti. Se hai PPA, repo vendor o sorgenti custom in /etc/apt/sources.list.d/, considera che l’upgrade può disabilitarli o renderli incompatibili. Il punto non è solo “avere il file”, ma sapere se quel repository ha pacchetti per 22.10. Se non li ha, l’upgrade può introdurre dipendenze rotte o downgrade impliciti.

Per una fotografia rapida della configurazione APT:

grep -R --line-number -E '^(deb|deb-src)' /etc/apt/sources.list /etc/apt/sources.list.d/

Se il sistema è remoto, apri una sessione persistente con tmux o screen. È un dettaglio banale, ma durante un upgrade non vuoi perdere la shell perché la rete si è interrotta o il client SSH si è chiuso.

Backup e piano di ritorno realistico

Un rollback completo di versione Ubuntu non è il piano da preferire. In pratica, il ritorno indietro “pulito” non è garantito come su una VM con snapshot. Se sei su macchina virtuale, la strategia migliore è uno snapshot prima dell’upgrade. Se sei su bare metal, fai backup dei dati e delle configurazioni, non solo dei file utente.

Minimo sindacale prima di procedere:

• backup di /etc;
• dump dei database se presenti;
• copia dei dati applicativi e delle directory web;
• elenco dei pacchetti installati manualmente;
• snapshot VM o immagine disco, se disponibile.

Per salvare l’elenco dei pacchetti manuali:

apt-mark showmanual > ~/apt-manual-packages.txt

Per archiviare la configurazione di sistema più sensibile, un tarball di /etc è spesso sufficiente per un ripristino rapido delle differenze:

sudo tar -czf /root/etc-backup-$(date +%F).tar.gz /etc

Se gestisci servizi web o database, salva anche i file di configurazione applicativi, i virtual host, gli override systemd e i file di ambiente. Il rollback utile non è “ripristino tutto”, ma “ripristino abbastanza da far ripartire il servizio”.

Impostare il gestore di rilascio corretto

Su Ubuntu, il tool ufficiale per l’upgrade di release è do-release-upgrade, fornito dal pacchetto update-manager-core. Prima verifica che sia installato e che il sistema sia configurato per accettare upgrade non-LTS se necessario.

sudo apt install update-manager-core
cat /etc/update-manager/release-upgrades

Nel file /etc/update-manager/release-upgrades il campo Prompt è quello da guardare. Se vuoi che il sistema proponga anche release intermedie, deve essere impostato in modo coerente con il tuo scenario operativo. In caso contrario, il tool potrebbe non offrire l’upgrade che ti aspetti.

Per un host che deve passare esplicitamente a 22.10, il comando di upgrade resta il punto centrale:

sudo do-release-upgrade

Se il tool non trova subito la nuova release, non forzare con repository manuali. Prima verifica che il sistema sia completamente aggiornato e che non ci siano pacchetti in stato incoerente. Il comportamento corretto è: aggiornamento corrente pulito, poi upgrade di versione.

Esecuzione dell’upgrade: cosa aspettarsi davvero

Durante l’upgrade, il sistema può disabilitare temporaneamente repository di terze parti, proporre la rimozione di pacchetti obsoleti e chiedere come trattare i file di configurazione. Qui conviene essere metodici: se hai modifiche locali importanti, non sovrascriverle senza leggere il diff. Se invece la configurazione era quella standard del pacchetto, spesso ha senso accettare la versione del maintainer.

Il tool mostrerà tipicamente passaggi del tipo download dei pacchetti, rimozione di componenti non più supportati, aggiornamento della base del sistema e possibile richiesta di riavvio. Non interrompere il processo a metà se non hai una ragione precisa e un piano di recupero. L’interruzione è una delle cause più noiose di sistemi parzialmente aggiornati.

Se sei in SSH, tieni aperta una seconda sessione di controllo o almeno un canale di emergenza. In caso di cambio del kernel o di restart di servizi di rete, vuoi poter verificare subito che il sistema sia ancora raggiungibile.

Un aspetto spesso sottovalutato riguarda i file di configurazione con modifiche locali. Quando APT chiede se mantenere la versione installata o installare quella del pacchetto, la risposta giusta dipende dal contesto. Un esempio pratico: se hai personalizzato /etc/ssh/sshd_config, accettare una sostituzione cieca può cambiare porte, algoritmi o opzioni di autenticazione. In quel caso conviene salvare il file corrente e confrontarlo con la nuova proposta.

Verifica post-upgrade

Dopo il riavvio, controlla subito la versione del sistema e lo stato dei servizi principali. Non dare per scontato che “se il login funziona allora è tutto a posto”. L’upgrade può lasciare indietro servizi secondari o moduli opzionali.

lsb_release -a
uname -r
systemctl --failed

systemctl --failed è il primo comando da guardare: se restituisce unità fallite, hai un elenco concreto da analizzare. Poi controlla i log del boot corrente:

journalctl -b -p err

Se il sistema ospita un web server, un database o altri servizi esposti, verifica anche che ascoltino sulle porte attese e che rispondano correttamente. Un controllo rapido può essere questo:

ss -tulpn
curl -I http://127.0.0.1

Per ambienti con interfaccia grafica, la verifica può includere il desktop, i driver video e i device audio o Wi-Fi. Su server headless, invece, il focus va su rete, storage, servizi e log. La logica non cambia: controlli prima le funzioni che impattano gli utenti, poi il resto.

Repository di terze parti e pacchetti rimasti indietro

Dopo un salto di release, il problema più comune non è il kernel: sono i repository esterni. Un PPA che non supporta 22.10 può bloccare aggiornamenti o proporre versioni incompatibili. In questi casi conviene disabilitare il repository, aggiornare il sistema e poi rivalutare se esiste una variante compatibile.

Per vedere quali pacchetti sono rimasti in stato non standard, puoi usare:

apt list --installed | grep -E '\[installed,local\]|\[installed,automatic\]'

Se noti dipendenze spezzate, il primo tentativo è sempre riparare con gli strumenti APT, non forzare rimozioni manuali:

sudo apt --fix-broken install
sudo dpkg --configure -a

Solo dopo, e con chiara comprensione dell’impatto, si valuta l’eliminazione di pacchetti obsoleti o incompatibili. La differenza tra “ripulire” e “rompere” è spesso una sola riga di comando eseguita senza leggere l’output.

Nota operativa su server remoti e finestre di manutenzione

Su un server remoto, l’upgrade va fatto in finestra di manutenzione. Non perché sia necessariamente lungo, ma perché può richiedere riavvii, riconfigurazioni e verifiche successive. Se il sistema è esposto pubblicamente, avvisa chi gestisce il servizio e definisci cosa consideri “OK” al termine: raggiungibilità SSH, risposta HTTP, login applicativo, o altro.

Se usi monitoraggio, sospendi temporaneamente gli alert che scatterebbero per il reboot, ma non spegnere la raccolta dati. Ti serve una traccia per capire se il problema post-upgrade è reale o solo una transizione prevista.

Se qualcosa va storto

Se l’upgrade si interrompe, la priorità è riportare il sistema in uno stato consistente, non “finire in fretta”. In pratica: verifica se il sistema boota, controlla journalctl, completa eventuali configurazioni rimaste a metà, e solo dopo valuta il ripristino da snapshot o backup. Se sei su VM e hai uno snapshot pre-upgrade, quello è il rollback più pulito.

Se invece il sistema parte ma un servizio non funziona, il problema è spesso nel delta tra vecchia e nuova configurazione. In quel caso confronta i file in /etc con i backup, controlla le unità systemd e verifica i log specifici del servizio. Non partire dall’idea che “Ubuntu ha rotto tutto”: nella maggior parte dei casi c’è una modifica locale o un pacchetto esterno che non ha seguito il cambio di release.

Scelta pratica: upgrade o permanenza su 22.04

La decisione più razionale, spesso, è non fare l’upgrade se non c’è una ragione tecnica forte. Ubuntu 22.04 resta una base più adatta alla produzione stabile. 22.10 ha senso come ponte, laboratorio o ambiente dove il beneficio delle novità è superiore al costo del cambio. Se il tuo obiettivo è affidabilità a lungo termine, la domanda giusta non è “posso aggiornare?”, ma “mi serve davvero questa release adesso?”.

Se la risposta è sì, il percorso corretto è: verifica, backup, upgrade con tool ufficiale, controllo dei servizi, pulizia dei repository non compatibili. Se la risposta è no, la scelta più professionale è rimandare e restare su una base supportata e prevedibile.