Come aggiornare Ubuntu 20.04 a 22.04 LTS con comando o GUI

Prima di toccare il release upgrade: cosa cambia davvero tra 20.04 e 22.04

Aggiornare da Ubuntu 20.04 LTS a 22.04 LTS non è un semplice cambio di numero versione. Stai spostando il sistema su un nuovo kernel, nuove librerie di base, una release di systemd, una nuova pila grafica lato desktop e, nei casi server, nuovi default per servizi e pacchetti che possono cambiare comportamento in modo sottile. Se il nodo ospita web, database, mail o servizi esposti, va trattato come un change controllato: prima osservi, poi prepari il rollback, poi aggiorni.

La regola pratica è questa: se il server è di produzione, non partire mai dall’upgrade “per vedere cosa succede”. Verifica che il sistema sia aggiornato, che ci sia spazio disco sufficiente, che il canale SSH sia stabile e che tu abbia un accesso alternativo in caso di disallineamento di rete o boot. Su desktop la procedura è più lineare, ma il rischio operativo resta: se la macchina non riparte o il display manager non sale, devi sapere come entrare da console o da recovery.

Controlli preliminari: stato atteso vs osservato

Stato atteso: Ubuntu 20.04 LTS aggiornato, con repository coerenti, spazio libero sufficiente e nessun pacchetto bloccato. Stato osservato da evitare: sistema con update incompleti, repository di terze parti non compatibili, partizione root quasi piena o servizi critici già instabili.

Prima di avviare il salto di release, raccogli un minimo di evidenza. Ti serve per capire se il problema è nell’upgrade o era già presente prima.

1. Verifica versione e stato della release corrente: lsb_release -a oppure cat /etc/os-release. Atteso: 20.04 e codename focal.
2. Controlla aggiornamenti pendenti: apt update seguito da apt list --upgradable. Atteso: nessun errore di repository e, idealmente, sistema già portato all’ultimo punto disponibile per 20.04.
3. Controlla lo spazio: df -h. Atteso: almeno qualche GB liberi su / e spazio adeguato su /boot se presente una partizione separata.
4. Verifica servizi critici: systemctl --failed e, se è un server applicativo, uno o due check mirati sui servizi che contano davvero. Atteso: zero unità fallite prima del cambio.
5. Se usi repository esterni, elencali: grep -Rhv '^#' /etc/apt/sources.list /etc/apt/sources.list.d/*.list. Atteso: sapere quali sorgenti potrebbero non supportare 22.04.

Il punto più trascurato è la compatibilità dei repository esterni. Driver, agent di monitoraggio, stack PHP, database vendor, software di backup, proxy e firewall userland possono dipendere da pacchetti compilati o firmati per la release precedente. Se non sai già che sono compatibili con 22.04, trattali come sospetti fino a prova contraria.

Backup e rollback: non teorici, ma eseguibili

Il rollback di un dist-upgrade completo non è mai elegante. Per questo va preparato prima, non dopo. Il rollback realistico è quasi sempre uno di questi: snapshot VM, backup dell’immagine disco, snapshot del volume, oppure ripristino del servizio su nodo sostitutivo. Se hai solo una macchina fisica senza snapshot, il backup deve essere testato e recuperabile, non solo “presente”.

1. Se sei su VM, crea uno snapshot o un checkpoint coerente prima dell’avvio. Verifica che il rollback sia possibile dal pannello dell’hypervisor.
2. Se sei su cloud, usa snapshot del volume root e annota ID, data e tempo di retention. Conserva anche la configurazione di boot se il provider la separa dal volume.
3. Se sei su bare metal, salva almeno configurazioni e inventario: /etc, virtual host, unit systemd custom, cron, export DB, chiavi di deploy e regole firewall. Non salvare segreti in chiaro in documenti condivisi; se devi esportarli, redigi o ruota dopo il test.
4. Su server web o mail, registra anche le dipendenze applicative: versione PHP, moduli Apache/Nginx, plugin, servizi locali, eventuali socket e path custom.

Se il nodo è critico e non ha ridondanza, considera il cambio come una finestra di manutenzione vera, con notifica e piano di rientro. Il rollback pratico non è “disinstallo il pacchetto nuovo”: è tornare allo stato precedente senza improvvisare sotto pressione.

Metodo consigliato da terminale: do-release-upgrade

Per un upgrade standard, il comando giusto è do-release-upgrade. Su server è la via più pulita perché gestisce il cambio di release, le sostituzioni dei pacchetti e le domande interattive. Prima però porta il sistema a uno stato coerente.

1. Aggiorna completamente la 20.04 corrente:

sudo apt update
sudo apt full-upgrade
sudo apt autoremove --purge

Atteso: nessun errore di dipendenze, nessun pacchetto trattenuto senza motivo, nessun servizio in stato failed. Se full-upgrade propone rimozioni inattese, fermati e controlla quali pacchetti verrebbero toccati.

1. Verifica che il tool di upgrade sia presente e che il canale LTS sia attivo:

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

Nel file, il parametro importante è Prompt=lts. Se è impostato diversamente, correggilo. Questo evita che il sistema cerchi release non LTS se il tuo obiettivo è restare su supporto lungo.

1. Avvia l’upgrade:

sudo do-release-upgrade

Durante l’esecuzione, il tool può disabilitare temporaneamente repository di terze parti, chiedere conferma per file di configurazione modificati localmente e interrompersi se rileva problemi bloccanti. Qui non bisogna andare “a intuito”: ogni prompt va letto. Se compare una richiesta su un file di configurazione già personalizzato, in generale conserva la tua versione solo se sai esattamente perché è diversa; altrimenti confronta il diff e decidi caso per caso.

Il comportamento da aspettarsi è questo: scarico dei pacchetti, sostituzione delle dipendenze, aggiornamento della release, eventuale riavvio di servizi, poi richiesta di riavvio finale del sistema. Se il processo si blocca, il log utile è spesso in /var/log/dist-upgrade/ oltre ai log di apt e al journal di sistema.

Se il sistema è gestito da GUI: upgrade da Software & Updates

Sui desktop o sulle workstation con ambiente grafico, l’upgrade può essere avviato anche dalla GUI. Il percorso varia leggermente tra GNOME, Ubuntu Desktop e derivati, ma il punto di ingresso tipico è Software & Updates o il gestore aggiornamenti. La logica resta identica: sistema aggiornato, canale LTS, poi verifica disponibilità nuova release.

1. Apri Software & Updates e verifica che i repository principali siano abilitati correttamente.
2. Controlla la scheda degli aggiornamenti e imposta la notifica per nuove versioni LTS, non per release normali, se il tuo obiettivo è restare su LTS.
3. Avvia il gestore aggiornamenti e accetta il passaggio alla nuova release quando viene proposto.
4. Se compare un avviso sui software di terze parti, disabilitali temporaneamente e riabilitali solo dopo aver verificato la compatibilità con 22.04.

La GUI è comoda su desktop, ma non ti solleva dal controllo dei dettagli. Se il sistema ha driver proprietari, VPN client, strumenti di cifratura o software di virtualizzazione, controlla dopo il reboot che siano caricati correttamente. La GUI tende a semplificare il flusso, non a risolvere i problemi di compatibilità.

Repository terze parti, PPA e pacchetti fuori standard

Molti upgrade falliscono non per Ubuntu in sé, ma per il contorno. PPA vecchi, repository vendor non aggiornati, pacchetti installati manualmente da .deb o software compilato fuori dai repo ufficiali sono i primi candidati a rompere la transizione. Il modo corretto di gestirli è ridurre la superficie prima dell’upgrade.

1. Disabilita temporaneamente i PPA non indispensabili, soprattutto quelli che forniscono versioni più recenti di PHP, Python, kernel, driver o strumenti di sistema.
2. Rimuovi o congela i pacchetti che non hai bisogno di portare subito sulla nuova release.
3. Se un repository non ha supporto per 22.04, cerca la release compatibile o sostituiscilo con il pacchetto ufficiale, almeno per la finestra di upgrade.

Un trucco utile è fare una fotografia dei pacchetti installati prima del cambio: dpkg -l > /root/pkglist-20.04.txt. Dopo l’upgrade puoi confrontare la lista per capire cosa è cambiato davvero e cosa è stato rimosso o sostituito. Questo non è solo inventario: è il modo più rapido per isolare regressioni applicative.

Durante l’upgrade: cosa osservare, non solo cosa cliccare

Se il nodo serve traffico reale, durante l’upgrade devi osservare almeno tre cose: stato del processo, stato dei servizi e sintomi lato client. Non basta vedere il prompt che avanza. L’upgrade può terminare correttamente e lasciare comunque un servizio web non avviato, una coda mail bloccata o un demone database che non riparte per un cambio di configurazione.

1. Apri un secondo terminale o una console separata e monitora il journal: journalctl -f.
2. Controlla i servizi critici: systemctl status nginx apache2 php8.1-fpm mysql postgresql o quelli realmente presenti nel tuo stack.
3. Se il server è remoto, mantieni una sessione di emergenza alternativa, come console del provider o accesso out-of-band.

Per i servizi web, una verifica semplice ma efficace è fare un curl locale e uno esterno, se possibile. Se il server risponde in locale ma non da fuori, il problema non è l’applicazione: è più probabilmente rete, firewall, bind address o reverse proxy.

curl -I http://127.0.0.1
curl -I https://tuodominio.example

Atteso: codice HTTP coerente con l’applicazione e tempi di risposta ragionevoli. Se vedi timeout, 5xx o redirect anomali, annota subito il punto di rottura prima di procedere oltre.

Primo boot su 22.04: verifiche che evitano falsi successi

Il reboot non chiude il lavoro, lo sposta. Il controllo post-upgrade deve concentrarsi su kernel, rete, storage, servizi e log. Qui emergono i problemi più fastidiosi: interfacce di rete con nomi diversi, moduli kernel non caricati, servizi che aspettano configurazioni deprecate, o permessi che cambiano comportamento con nuove versioni di pacchetti.

1. Conferma la nuova release: lsb_release -a. Atteso: 22.04 e codename jammy.
2. Controlla il kernel in uso: uname -r. Atteso: kernel della serie installata da 22.04 o comunque coerente con la nuova base.
3. Verifica errori di boot: journalctl -b -p err. Atteso: nessun errore critico persistente.
4. Controlla i servizi: systemctl --failed. Atteso: zero unità fallite.
5. Se usi storage non banale, verifica mount e spazio: df -h e lsblk. Atteso: nessun filesystem in sola lettura o con errori evidenti.

Se il desktop entra ma l’interfaccia grafica non appare, il problema spesso è nel display manager, nei driver video o in una sessione corrotta. In quel caso passa a una TTY e controlla i log del servizio grafico invece di reinstallare componenti a caso.

systemctl status gdm3
journalctl -u gdm3 -b --no-pager

Su server, la verifica deve includere anche i servizi applicativi. Per esempio, un host LAMP/LEMP può sembrare sano perché SSH funziona, ma PHP-FPM o il reverse proxy potrebbero essere rimasti giù. Il test corretto è quello che tocca il percorso utente reale, non solo il login di sistema.

Problemi tipici e come riconoscerli in fretta

Ci sono alcuni pattern che ricorrono quasi sempre dopo il salto di release. Riconoscerli velocemente evita di perdere tempo in ipotesi sbagliate.

• Repository rotti: apt update restituisce 404 o firme mancanti. Soluzione: rimuovere o aggiornare i repo non compatibili con 22.04.
• Servizi non avviati: systemctl --failed mostra unità bloccate. Soluzione: leggere il log della singola unità e verificare eventuali cambi di path o opzioni.
• Configurazioni obsolete: il demone parte con warning o fallisce per direttive deprecate. Soluzione: confrontare i file in /etc con i default del pacchetto nuovo.
• Dipendenze applicative: moduli PHP, driver DB o plugin non sono più compatibili. Soluzione: aggiornare il componente, non forzare versioni vecchie senza motivo.
• Rete o DNS: il sistema è su ma l’esterno non lo vede. Soluzione: controllare binding, firewall, regole cloud e record DNS, non solo il servizio locale.

Il punto chiave è distinguere tra problema di sistema e problema di applicazione. Se il nodo risponde localmente ma non dall’esterno, non è un fallimento dell’upgrade: è un difetto di esposizione. Se il servizio parte ma l’applicazione mostra pagina bianca, la base è probabilmente sana e va cercata la regressione nello stack applicativo.

Quando conviene non aggiornare subito

Non tutte le macchine vanno aggiornate appena la nuova LTS è disponibile. Se il server ospita applicazioni con vincoli di certificazione, software vendor che supporta solo una specifica major release, ambienti con kernel o driver speciali, oppure macchine con manutenzione minima e senza snapshot, ha senso aspettare una finestra più comoda e preparare prima la compatibilità.

In pratica, rimanda l’upgrade se non hai almeno uno di questi elementi: backup verificato, snapshot o clone, accesso di emergenza, finestra di manutenzione e lista dei componenti da validare. Aggiornare “quando capita” è un modo rapido per trasformare un cambio ordinario in un incidente evitabile.

Ordine operativo consigliato, senza scorciatoie

1. Raccogli stato e inventario del sistema.
2. Fai backup o snapshot e verifica che il rollback sia possibile.
3. Porta la 20.04 all’ultimo aggiornamento disponibile.
4. Disabilita repository esterni non essenziali.
5. Lancia do-release-upgrade da terminale, oppure il flusso GUI su desktop.
6. Riavvia e controlla kernel, servizi, log e connettività.
7. Riabilita gradualmente i repository e i componenti di terze parti, verificando uno alla volta.

Questa sequenza è noiosa, ma è quella che riduce i falsi positivi e rende leggibile il post-mortem se qualcosa si rompe. L’upgrade di release non deve essere eroico; deve essere ripetibile e documentabile.

Checklist finale da usare come barriera di uscita

• lsb_release -a mostra 22.04.
• systemctl --failed non mostra unità attive in errore.
• journalctl -b -p err non contiene errori critici non spiegati.
• apt update funziona senza repository rotti.
• I servizi applicativi rispondono con il comportamento atteso, non solo con SSH acceso.
• Hai annotato cosa è stato cambiato, così il rollback o la verifica futura non dipendono dalla memoria.

Se vuoi un criterio semplice: l’upgrade è chiuso solo quando il sistema è su 22.04, i servizi essenziali sono tornati online, i log non mostrano regressioni evidenti e hai un punto di rientro valido se nei giorni successivi emerge un problema latente. Assunzione: macchina Ubuntu 20.04 LTS standard, con accesso amministrativo e possibilità di snapshot o backup verificabile.