Aggiornare Ubuntu da 20.04 a 22.04 in modo sicuro

Aggiornare Ubuntu 20.04 a 22.04 senza improvvisare

Il salto da Ubuntu 20.04 LTS a 22.04 LTS è un change controllato, non un click “avanti e basta”. Se il server ospita servizi esposti, il punto non è solo arrivare alla nuova release: è farlo con una finestra di rischio limitata, una verifica chiara prima e dopo, e un piano di ritorno se qualcosa si rompe.

La regola pratica è semplice: prima osservi lo stato reale della macchina, poi sistemi i prerequisiti, infine fai l’upgrade. Saltare i controlli preliminari è il modo più veloce per scoprire a metà procedura che mancano spazio su disco, repository di terze parti incompatibili, pacchetti trattenuti o servizi che non ripartono più con il nuovo kernel.

Quando ha senso farlo adesso

Ha senso se il sistema è stabile, con manutenzione recente, e non stai già inseguendo un incidente. Se il nodo è sotto carico, se hai plugin o repository esterni non allineati, oppure se non hai accesso console o out-of-band, rimanda. Un upgrade LTS non è il posto giusto per scoprire che il backup non si ripristina.

Lo stato atteso è questo: macchina raggiungibile, spazio libero sufficiente, pacchetti aggiornati, nessun blocco da apt, repository standard o chiaramente documentati, e una finestra in cui puoi riavviare senza impatto incontrollato. Lo stato osservato va verificato con dati, non con supposizioni.

Prima di toccare il sistema: verifica quello che conta

Fai questi controlli nell’ordine. Sono rapidi e ti dicono subito se stai entrando in un upgrade pulito o in una trappola.

1. Verifica la release attuale e il kernel:

   lsb_release -a
   uname -r

   Atteso: Ubuntu 20.04.x e un kernel coerente con la macchina. Se il comando lsb_release non è presente, usa cat /etc/os-release.

2. Controlla spazio libero su root e su /boot:

   df -h /
   df -h /boot

   Atteso: margine reale, non pochi centinaia di MB. Se /boot è quasi pieno, prima pulisci kernel vecchi o pacchetti inutili, altrimenti l’upgrade può fermarsi a metà.

3. Verifica lo stato dei pacchetti:

   sudo apt update
   apt list --upgradable

   Atteso: repository raggiungibili e pochi pacchetti pendenti. Se apt update fallisce, non andare oltre prima di capire se il problema è DNS, proxy, repo disabilitato o chiave scaduta.

4. Controlla pacchetti bloccati o installazioni interrotte:

   apt-mark showhold
   dpkg --audit

   Atteso: nessun hold critico e nessun pacchetto in stato incoerente. Se trovi hold su componenti base, documenta il motivo prima di sbloccarli.

5. Verifica il supporto dell’upgrade tool:

   which do-release-upgrade
   sudo do-release-upgrade --version

   Atteso: il tool esiste e risponde. Se manca, il pacchetto update-manager-core può non essere installato.

Backup e rollback: quello che serve davvero

Il rollback su una major release non è “disinstallo e torno indietro”. In pratica devi poter ripristinare la macchina o almeno i dati e la configurazione in modo coerente. Se hai snapshot del volume o VM, usali. Se hai solo backup file-level, devi sapere già come ripristinare almeno configurazioni e dati applicativi.

Minimo sindacale prima di procedere:

• snapshot della VM o del volume, se disponibile;
• backup di /etc e delle configurazioni applicative;
• dump dei database, se la macchina ospita servizi stateful;
• registro dei repository terzi e delle configurazioni custom.

Per esempio, su un server web puoi salvare i file di configurazione e i virtual host prima del cambio:

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

Non è un backup completo del sistema, ma è un punto di ritorno utile per ricostruire la configurazione. Se usi database locali, il dump va fatto con lo strumento corretto del motore in uso, non copiando file a caso mentre il servizio è attivo.

Pulizia dei repository e dei pacchetti prima dell’upgrade

Molti upgrade falliscono non per Ubuntu in sé, ma per le estensioni che ci hai appoggiato sopra negli anni. Repository di terze parti, PPA, agent obsoleti, driver proprietari e pacchetti trattenuti sono la prima causa di stop o conflitto.

Fai una ricognizione dei file in /etc/apt/sources.list e in /etc/apt/sources.list.d/. Se c’è roba non necessaria al momento dell’upgrade, disabilitala temporaneamente commentando le righe o rinominando i file, ma tieni traccia di cosa hai disattivato. Questo è un cambio reversibile, non una rimozione definitiva.

grep -Rhv '^#' /etc/apt/sources.list /etc/apt/sources.list.d/

Se trovi PPA o repo vendor che non dichiarano supporto per 22.04, il rischio è alto. In quel caso la scelta pulita è: rimuovere o disabilitare prima, aggiornare il sistema base, poi reinstallare la versione compatibile del componente. Tenere attivi repo incompatibili durante l’upgrade è un invito ai pacchetti “mezzo aggiornati”.

Impostare il canale giusto per l’upgrade

Su Ubuntu LTS, il comportamento standard è passare alla release successiva supportata. Controlla che il sistema sia configurato per proporre l’upgrade corretto. Il file da guardare è /etc/update-manager/release-upgrades.

sudo cat /etc/update-manager/release-upgrades

Di solito vuoi che il parametro Prompt sia impostato su lts o comunque coerente con il percorso che intendi seguire. Se la macchina è già su 20.04 LTS e vuoi arrivare a 22.04 LTS, il canale LTS è quello corretto.

Se devi modificare il file, fallo con un editor e conserva il backup del precedente contenuto. Esempio:

sudo cp /etc/update-manager/release-upgrades /etc/update-manager/release-upgrades.bak
sudo nano /etc/update-manager/release-upgrades

Il rischio qui è basso, ma è comunque una modifica di configurazione: backup prima, modifica dopo.

Esecuzione dell’upgrade: sequenza operativa

La via standard è usare do-release-upgrade. Se lavori su un server remoto, il problema non è solo l’upgrade in sé: è non perdere la sessione. Usa sempre tmux o screen se hai accesso shell interattiva, così non resti bloccato per una disconnessione SSH proprio durante la fase critica.

1. Avvia una sessione persistente:

   tmux new -s upgrade

2. Lancia l’upgrade:

   sudo do-release-upgrade

   Atteso: il tool rileva la nuova release e mostra i passaggi. Se dice che non ci sono nuove release, verifica che il sistema sia aggiornato e che il canale sia corretto.

3. Durante la procedura, leggi con attenzione le richieste sui file di configurazione. Se il sistema ti chiede se mantenere la versione locale o installare quella del maintainer, non cliccare a caso: valuta il file coinvolto. Per servizi esposti, spesso conviene mantenere la configurazione locale se contiene tuning o virtual host personalizzati; per file standard di sistema, in molti casi conviene accettare la versione del maintainer solo se hai confrontato le differenze.

4. Se il tool propone rimozione di pacchetti obsoleti, controlla la lista. Non accettare alla cieca se dentro ci sono componenti che usi davvero. La scelta giusta è verificare prima con una breve ricerca del pacchetto e del servizio associato.

Se l’upgrade si interrompe per un conflitto di pacchetti, non forzare subito con operazioni invasive. Prima identifica il pacchetto bloccante con i log di apt e con dpkg --audit. In molti casi il problema è un repo esterno che va disattivato o un pacchetto trattenuto che impedisce la risoluzione delle dipendenze.

Cosa guardare nei log mentre procede

Durante e subito dopo l’upgrade, i log ti dicono più della barra di avanzamento. I punti utili sono quelli dove il sistema registra errori di configurazione, servizi non avviati o pacchetti lasciati in stato parziale.

sudo tail -n 200 /var/log/dist-upgrade/main.log
sudo tail -n 200 /var/log/dist-upgrade/apt.log
sudo journalctl -p err -b

Atteso: nessun errore persistente su repository, pacchetti o servizi critici. Se vedi errori ripetuti su un servizio specifico, non archiviarli come rumore: quel servizio va verificato subito dopo il reboot.

Per chi gestisce stack LAMP o LEMP, è normale controllare anche i log di web server e PHP-FPM dopo l’upgrade. Se una pagina risponde con 502, pagina bianca o timeout, spesso il problema non è il sistema base ma un servizio applicativo che non è ripartito con la nuova versione di librerie o con una configurazione non più valida.

Riavvio e verifica post-upgrade

Quando il tool termina, pianifica il reboot. Il cambio di release non è completo finché non hai avviato il nuovo kernel e verificato i servizi. Se hai servizi esposti, questo è il punto in cui misuri il vero esito dell’intervento.

1. Riavvia la macchina:

   sudo reboot

2. Dopo il reboot, verifica la release:

   lsb_release -a
   uname -r

   Atteso: Ubuntu 22.04.x e kernel aggiornato.

3. Controlla i servizi principali:

   systemctl --failed
   systemctl status ssh apache2 nginx php8.1-fpm mysql postgresql

   Atteso: nessun servizio failed e i demoni critici in stato active (running) o equivalente.

4. Verifica la rete e il DNS locale se il sistema usa resolver o servizi che dipendono dalla connettività:

   resolvectl status
   ip a
   ip r

   Atteso: interfacce corrette, route presenti, resolver coerente con la configurazione attesa.

5. Esegui un controllo applicativo minimo con una richiesta locale o remota:

   curl -I http://127.0.0.1/
   curl -I https://tuo-dominio.example

   Atteso: codice HTTP coerente, niente 5xx, niente handshake TLS rotto, niente redirect anomali.

Gli errori più comuni dopo il salto di versione

Il caso classico è il servizio che non parte perché ha ereditato una configurazione vecchia o perché dipende da una libreria cambiata. Su Ubuntu 22.04, alcuni componenti sono più recenti e le configurazioni non sempre si portano dietro senza attriti. Non dare per scontato che “se il pacchetto è installato allora è funzionante”.

Altro errore tipico: repository di terze parti riattivati troppo presto o lasciati attivi con versioni non compatibili. Il sintomo può essere un apt upgrade che continua a proporre correzioni o pacchetti tenuti indietro. In quel caso conviene consolidare il sistema base prima di reintrodurre il software esterno, uno alla volta.

Se il nodo ospita mail, reverse proxy o firewall applicativo, controlla anche i permessi dei file e gli eventuali moduli caricati. Un upgrade di release non dovrebbe cambiare la logica di accesso, ma può cambiare il packaging, i path o la disponibilità di un modulo specifico. Le sorprese arrivano lì, non nel banner della release.

Rollback realistico: quando e come tornare indietro

Il rollback migliore è quello preparato prima. Se hai snapshot, il ritorno alla situazione precedente è rapido e coerente. Se non hai snapshot, il rollback completo di una major release è spesso più costoso del problema che stai tentando di correggere. Per questo il backup iniziale non è una formalità.

Se qualcosa va storto subito dopo il reboot e la macchina è virtualizzata, la via più pulita è ripristinare lo snapshot pre-upgrade. Se invece hai solo backup file-level, puoi recuperare configurazioni e dati, ma il sistema operativo di base non torna “com’era” con un semplice restore di file. Questa distinzione va spiegata prima a chi approva il change.

In una macchina fisica senza snapshot, il rollback operativo è di fatto un rebuild o una reinstallazione con restore dei dati. È brutto da dire, ma è meglio dirlo prima che scoprire dopo che l’upgrade era irreversibile per la tua infrastruttura.

Checklist finale da usare sempre

1. Ho verificato release, spazio disco, pacchetti e hold con comandi reali, non a vista.

2. Ho un backup o snapshot precedente all’upgrade e so come ripristinarlo.

3. Ho disabilitato temporaneamente i repository esterni non allineati a 22.04.

4. Ho eseguito do-release-upgrade da una sessione persistente.

5. Ho controllato log, servizi failed e risposta HTTP dopo il reboot.

6. Ho un piano chiaro per rollback o rebuild se il nodo non torna operativo.

Assunzione operativa: la macchina è un server Linux recente con accesso root, upgrade da remoto via SSH e servizi standard o comunque documentati; se ci sono vincoli particolari di pannello, cluster, storage o appliance, il check preliminare va adattato prima dell’esecuzione.