Aggiornare Ubuntu 22.04 a 24.04 LTS: guida completa

Aggiornare Ubuntu 22.04 a 24.04 LTS senza improvvisare

Il salto da Ubuntu 22.04 LTS a 24.04 LTS non è un semplice cambio di release: tocca kernel, userland, repository, eventuali PPA, servizi systemd e, spesso, componenti applicativi che si appoggiano a PHP, MariaDB, Nginx o Apache. La regola pratica è semplice: prima si fotografa lo stato, poi si riducono le variabili, infine si esegue l’upgrade con una via di ritorno chiara.

Se il server ospita un sito, una VM applicativa o un nodo che espone servizi critici, considera l’operazione un change controllato. L’obiettivo non è “fare presto”, ma arrivare al primo boot post-upgrade con rete, shell, SSH e servizi essenziali in piedi, e con un rollback possibile se qualcosa rompe la catena di avvio.

Prima di toccare il sistema: fotografia dello stato

La parte che evita più problemi è noiosa ma decisiva: verificare versione, spazio disco, stato dei servizi, sorgente dei pacchetti e presenza di configurazioni locali fuori standard. Se questa fase mostra anomalie, si fermano prima i lavori e si sistemano gli elementi di base.

Controlli minimi da eseguire:

1. Verifica release, kernel e spazio libero

Serve sapere se la macchina è davvero su 22.04, quale kernel sta usando e se c’è margine sufficiente su /, /boot e, se separato, /var. Un upgrade interrotto per disco pieno è uno dei modi più banali per crearsi un incidente.

lsb_release -a
uname -r
df -hT
findmnt /boot /var

Atteso: Ubuntu 22.04.x LTS, spazio libero ragionevole e nessuna partizione al 100%. Se /boot è quasi pieno, va pulito prima, perché nuovi pacchetti kernel e initramfs devono entrare senza forzature.

2. Controllo dei servizi e dei log con errori già presenti

Se un servizio è già in errore prima dell’upgrade, non aspettarti che la release nuova lo sistemi da sola. L’upgrade amplifica i problemi esistenti, non li cura.

systemctl --failed
journalctl -p 3 -xb --no-pager | tail -n 100
ss -tulpn

Atteso: nessun servizio failed e nessun errore sistemico ripetuto nel journal. Se compaiono problemi su SSH, rete, storage o database, vanno chiariti prima di proseguire.

3. Repository e PPA: meno roba esterna, meno sorprese

Gli upgrade LTS falliscono spesso non per Ubuntu in sé, ma per repository terzi rimasti agganciati a release precedenti o per pacchetti che sostituiscono componenti di base. Qui la regola è semplice: ridurre i PPA al minimo necessario e annotare cosa viene disattivato.

grep -R --line-number "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/
apt-cache policy | sed -n '1,120p'

Se trovi PPA per PHP, database, kernel, tool di monitoraggio o stack web, verifica se esiste già il pacchetto nella nuova LTS o se il repository è compatibile con 24.04. In caso di dubbio, meglio sospenderlo e riattivarlo dopo, una volta verificato l’impatto.

Backup e rollback: cosa salvare davvero

Il rollback di un upgrade di release non è quasi mai “un comando magico”. Di solito si torna indietro con snapshot, backup bare-metal o ripristino VM. Se non hai uno di questi tre, stai facendo un cambio senza paracadute.

Prima dell’upgrade salva almeno:

• snapshot VM o backup completo del volume di sistema;
• /etc, soprattutto file custom in /etc/ssh/, /etc/nginx/, /etc/apache2/, /etc/php/, /etc/mysql/ o /etc/mariadb/;
• elenco pacchetti installati e versioni applicative critiche.

Un set minimo utile è questo:

mkdir -p /root/backup-ubuntu2204-before-upgrade
cp -a /etc /root/backup-ubuntu2204-before-upgrade/
dpkg --get-selections > /root/backup-ubuntu2204-before-upgrade/dpkg-selections.txt
apt-mark showmanual > /root/backup-ubuntu2204-before-upgrade/apt-manual.txt

Se il sistema è in produzione, aggiungi anche export dei database o almeno un dump coerente, perché l’OS backup da solo non protegge i dati applicativi.

Preparare 22.04 per il salto a 24.04

La preparazione vera consiste nel portare 22.04 allo stato più pulito possibile: aggiornamento completo, rimozione di pacchetti obsoleti, reboot se richiesto e disattivazione temporanea di elementi che possono interferire con do-release-upgrade.

Sequenza consigliata:

1. Aggiorna l’indice pacchetti e installa gli update disponibili.
2. Rimuovi o annota pacchetti orfani e kernel vecchi se necessario.
3. Riavvia se il kernel o librerie base lo richiedono.
4. Verifica che il sistema torni su senza errori.

apt update
apt full-upgrade -y
apt autoremove --purge -y
reboot

Dopo il reboot, ricontrolla che il sistema sia stabile:

systemctl --failed
uptime
journalctl -p 3 -xb --no-pager | tail -n 50

Se compaiono errori di rete, storage o boot, fermati qui. Fare upgrade sopra una base instabile è solo un modo elegante per complicarsi il debug.

Avviare l’upgrade con do-release-upgrade

Su Ubuntu server la via standard è do-release-upgrade. È preferibile farlo da console locale, IPMI, console del provider o sessione screen/tmux, non da una SSH fragile su link instabile. Se perdi la sessione nel mezzo, non vuoi perdere anche il controllo del nodo.

Prima di partire, verifica che il gestore upgrade sia presente:

apt update
apt install -y update-manager-core

Controlla il file di configurazione dell’upgrade:

grep -n '^Prompt=' /etc/update-manager/release-upgrades

Atteso: Prompt=lts. Se non lo è, sistemalo prima, altrimenti il sistema potrebbe non proporti il salto corretto.

Lancia l’upgrade:

do-release-upgrade

Durante la procedura, leggi con attenzione le richieste sui file di configurazione. La scelta automatica non è sempre quella giusta: se hai personalizzazioni locali, in genere devi conservare la versione installata e poi mergiare a mano i cambi utili, invece di accettare in blocco il file del pacchetto.

Gestire i conflitti sui file di configurazione

Qui si rompe spesso la tranquillità dell’operazione. Nei file sotto /etc possono comparire differenze tra versione del maintainer e versione locale. Non esiste una scelta universale: dipende dal servizio e da quanto hai personalizzato il nodo.

Regola pratica:

• se il file è standard e non lo tocchi mai, puoi accettare la nuova versione;
• se il file contiene tuning, virtual host, override o hardening, conserva il locale e confronta dopo;
• se non sai cosa fa il file, fermati e documentalo prima di decidere.

Per fare un confronto pulito, tieni a portata il diff:

diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist || true
diff -u /etc/apt/sources.list /etc/apt/sources.list.dpkg-dist || true

In genere il punto più delicato è SSH: un errore in sshd_config può tagliare fuori l’accesso remoto. Prima di riavviare il servizio, valida la sintassi:

sshd -t

Atteso: nessun output. Se esce un errore, non riavviare sshd finché non è corretto.

Dopo il reboot: validare il layer base prima dell’applicazione

Quando l’upgrade termina, il vero lavoro inizia al primo boot. Prima si controlla che il sistema sia sano, poi che la rete sia su, quindi che SSH accetti connessioni e solo dopo si passa ai servizi applicativi.

Verifiche minime:

1. Versione nuova attiva con lsb_release -a.
2. Kernel aggiornato con uname -r.
3. Nessun servizio failed con systemctl --failed.
4. SSH operativo con una nuova sessione esterna.
5. Risoluzione DNS e connettività in uscita con ping o curl verso un endpoint noto.

lsb_release -a
uname -r
systemctl --failed
curl -I https://example.com

Se il server ospita un sito, controlla anche il codice HTTP e i log del web server:

curl -I http://127.0.0.1
journalctl -u nginx -b --no-pager | tail -n 100
journalctl -u apache2 -b --no-pager | tail -n 100

Una risposta 200 o un 301/302 atteso è il minimo sindacale. Errori 5xx vanno trattati subito, non rimandati al “più tardi”.

Stack applicativi: PHP, database e web server

Molti upgrade tra LTS cambiano versioni di PHP e librerie correlate. Se il sito usa moduli specifici, estensioni PECL o software non aggiornato, il rischio non è il sistema operativo in sé ma la compatibilità applicativa.

Controlli utili dopo il reboot:

php -v
php -m | sort
systemctl status php8.3-fpm --no-pager
systemctl status mariadb --no-pager

Se usi Nginx con PHP-FPM, verifica che il socket configurato sia quello corretto e che il pool sia partito. Se usi Apache con mod_php o proxy verso FPM, ricontrolla i moduli caricati e i VirtualHost attivi.

Un controllo rapido del database evita di attribuire all’OS un problema che è solo un servizio fermo:

systemctl status mysql --no-pager
systemctl status mariadb --no-pager
mysqladmin ping

Se il database non risponde, prima guarda il journal del servizio e lo spazio disco, poi i permessi dei socket e infine i parametri di configurazione. Non partire dal tuning.

Pacchetti rimossi, servizi disabilitati e differenze da 24.04

Un upgrade LTS può introdurre rimozioni o sostituzioni di pacchetti. Alcuni demoni legacy, vecchie librerie o componenti non più supportati spariscono o cambiano nome. Qui serve leggere l’output finale dell’upgrade, non solo far scorrere il terminale.

Subito dopo il primo boot, controlla cosa è stato rimosso o lasciato in stato anomalo:

dpkg -l | awk '$1 ~ /^rc$/ {print $2}'
apt list --upgradable 2>/dev/null | sed -n '1,120p'
journalctl -p 4 -b --no-pager | tail -n 100

Se trovi servizi disabilitati o mascherati, verifica se è una scelta del pacchetto nuovo o un residuo della release precedente. In caso di dubbio, confronta lo stato con il file unit e con systemctl cat.

systemctl cat nome-servizio
systemctl is-enabled nome-servizio
systemctl status nome-servizio --no-pager

Quando fermarsi e ripristinare

Il rollback va deciso con criteri semplici, non emotivi. Se dopo l’upgrade non hai SSH stabile, il boot è degradato, il filesystem è incoerente o i servizi critici non si rialzano in tempi ragionevoli, conviene tornare allo snapshot o al backup invece di inseguire patch al buio.

Segnali che giustificano il rollback:

• il sistema non completa il boot o entra in emergency mode;
• SSH è instabile o non accessibile da fuori;
• il web server parte ma l’applicazione mostra errori sistematici;
• il database non recupera e i log indicano corruzione o mismatch importanti;
• mancano i pacchetti necessari e il servizio non è ripristinabile rapidamente.

Se hai snapshot VM, il rollback è la strada più pulita. Se hai solo backup file-based, ripristina il sistema secondo la tua procedura di disaster recovery, non improvvisare un “downgrade” del sistema operativo come se fosse un pacchetto singolo.

Post-upgrade: pulizia e stabilizzazione

Quando 24.04 è stabile, non chiudere il ticket subito. Conviene fare una breve pulizia: rivedere repository terzi, ricompilare eventuali moduli custom, verificare i cron, controllare i backup e aggiornare la documentazione del nodo con la nuova baseline.

Una mini-lista utile:

1. riattiva solo i repository necessari e compatibili;
2. controlla i job pianificati in crontab e in /etc/cron.*;
3. verifica che i backup girino e che i log ruotino correttamente;
4. aggiorna inventario, note operative e procedure di recovery.

Se il server ospita servizi esposti, è un buon momento anche per un audit rapido della superficie d’attacco: porte aperte con ss -tulpn, versioni software, permessi dei file sensibili e stato degli aggiornamenti di sicurezza.

ss -tulpn
unattended-upgrades --dry-run --debug 2>/dev/null | tail -n 50
grep -R --line-number -E 'password|secret|token' /etc 2>/dev/null | head

Le credenziali non vanno mai salvate in chiaro nei file di configurazione se esistono alternative più sicure: variabili protette, file con permessi stretti o secret manager. Se durante l’upgrade emergono vecchi file con segreti, è il momento giusto per ruotarli e ripulire.

Checklist finale operativa

Se vuoi ridurre gli errori, usa questa sequenza come controllo finale prima di considerare chiuso l’intervento:

1. backup o snapshot verificato;
2. release 22.04 confermata prima del change;
3. update completo e reboot pulito su 22.04;
4. do-release-upgrade eseguito da console affidabile;
5. conflitti config risolti con criterio;
6. reboot su 24.04 e verifica di SSH, rete, servizi e app;
7. controllo log, errori e stato dei pacchetti;
8. pulizia finale e documentazione aggiornata.

Assunzione operativa: il server è Linux recente con systemd, accesso root o sudo disponibile e un metodo di rollback già definito prima del change.