Aggiornare Ubuntu 20.04 LTS a 21.04 passo dopo passo

Se l’obiettivo è portare un server da Ubuntu 20.04 LTS a 21.04, la prima cosa da chiarire è che stai passando da una release LTS a una release intermedia con finestra di supporto breve. In pratica: non è il classico upgrade “tranquillo” da fare per consolidare una macchina di produzione. È un passaggio che ha senso solo se hai un motivo preciso, un ambiente controllato e un piano di ritorno.

La scelta più sensata, nella maggior parte dei casi, non è 21.04 ma 22.04 LTS o una versione LTS più recente, dopo verifica di compatibilità applicativa. Se però devi documentare o eseguire il salto a 21.04, conviene farlo con metodo: backup, controllo dei repository, verifica del supporto residuo, e soprattutto consapevolezza che 21.04 è una release non LTS e quindi con un ciclo di vita molto più corto.

Perché questo upgrade va trattato come un cambio controllato

Il punto non è solo il cambio di versione. Cambiano il kernel, la toolchain, i pacchetti di sistema, alcune dipendenze di libreria e, in molti casi, il comportamento di servizi che davano per scontato un certo stack. Su una workstation il problema può essere gestibile; su un server, ogni upgrade di release va letto come una modifica che può toccare rete, storage, servizi web, database e autenticazione.

Tradotto in termini operativi: prima di lanciare l’upgrade devi sapere cosa stai proteggendo, dove salverai lo stato attuale e come ripristini se qualcosa si rompe. Senza questo, il salto di release diventa un esercizio di fortuna, non un’operazione amministrativa.

Controlli preliminari che evitano guai inutili

Prima di tutto verifica la release attuale e la presenza di eventuali lock o configurazioni anomale. Su Ubuntu, il comando più rapido è questo:

lsb_release -a
uname -r
apt-mark showhold

Il primo comando conferma la versione installata; il secondo ti dice quale kernel stai effettivamente usando; il terzo mostra eventuali pacchetti bloccati che potrebbero interferire con l’upgrade. Se trovi hold su componenti di base, non ignorarli: vanno rimossi o motivati prima del passaggio di release.

Poi controlla lo stato dei repository e l’allineamento dei pacchetti:

sudo apt update
sudo apt list --upgradable

Se il sistema mostra errori di sorgenti non raggiungibili, repository di terze parti rotti o conflitti di firma, fermati lì. Un upgrade di release sopra una base già sporca amplifica i problemi invece di risolverli.

Backup minimo reversibile: cosa salvare davvero

Il backup utile non è “qualcosa da avere”, è una copia che puoi ripristinare in tempi ragionevoli. Al minimo devi proteggere configurazioni, dati applicativi e, se sei su VM, anche uno snapshot coerente del disco. Il punto non è fare un archivio enorme: è poter tornare indietro con un percorso chiaro.

Per una macchina con servizi standard, conviene salvare almeno questi elementi:

• `/etc/` per la configurazione di sistema e dei servizi.
• `/var/www/`, ` /srv/` o le directory dove risiedono i dati applicativi.
• Dump dei database, se presenti, con un metodo coerente con il motore usato.
• Elenco pacchetti installati per ricostruire lo stato software.

Per avere un riferimento rapido dello stato pacchetti, puoi esportare la lista:

dpkg --get-selections > packages-before-upgrade.txt

Se lavori su VM o cloud, lo snapshot del volume è spesso il rollback più pratico. Ma non confonderlo con il backup applicativo: uno snapshot non sostituisce un dump consistente del database.

Repository di terze parti: il punto che rompe più spesso l’upgrade

La maggior parte degli upgrade di Ubuntu fallisce per colpa di repository esterni non compatibili con la nuova release. PPA, repository vendor, tool di monitoraggio, agent di backup o stack software installati fuori dai repository ufficiali possono impedire il passaggio o lasciare il sistema in uno stato metà vecchio e metà nuovo.

Prima dell’upgrade, disabilita temporaneamente le sorgenti esterne e verifica che l’APT base sia pulito. I file da controllare sono tipicamente in ` /etc/apt/sources.list` e ` /etc/apt/sources.list.d/`.

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

Se vedi repository che non hanno una versione compatibile con 21.04, vanno rimossi o commentati prima di procedere. Non lasciarli lì “tanto poi vediamo”: l’upgrade release-to-release non perdona bene i pacchetti fuori standard.

Il percorso corretto con do-release-upgrade

Su Ubuntu il percorso ufficiale passa da `do-release-upgrade`. Prima di usarlo, assicurati che il sistema sia completamente aggiornato alla release corrente. Questo evita di portarti dietro una base incoerente.

sudo apt update
sudo apt full-upgrade
sudo reboot

Dopo il riavvio, verifica che il sistema sia tornato online e che i servizi critici siano attivi. Poi lancia l’upgrade:

sudo do-release-upgrade

Se il tool non propone la nuova release, il motivo più comune è che la macchina è configurata per ricevere solo release LTS oppure che la release target non è più disponibile nel canale standard. In quel caso il file da verificare è ` /etc/update-manager/release-upgrades`.

cat /etc/update-manager/release-upgrades

Il parametro `Prompt=` indica il tipo di rilascio cercato. Se il valore non è coerente con il percorso desiderato, il tool non mostrerà l’upgrade come atteso. Questo è un controllo banale, ma spesso è quello che fa perdere tempo.

Cosa aspettarsi durante l’upgrade

Il processo può chiedere conferme su file di configurazione, servizi da riavviare e pacchetti da rimuovere. Qui non esiste una risposta unica: devi confrontare ogni modifica con il comportamento attuale della macchina. Se hai personalizzazioni locali, non accettare in automatico la sostituzione dei file senza aver capito cosa cambia.

In particolare, presta attenzione a:

• configurazioni di rete, se usi interfacce statiche o bonding;
• servizi web come Apache, Nginx, PHP-FPM e relative pool;
• database e agent di replica;
• SSH, firewall e regole di accesso remoto;
• cron, timer systemd e job di manutenzione.

Se l’upgrade avviene via SSH, la prudenza è obbligatoria: usa `screen` o `tmux` per non perdere la sessione in caso di disconnessione. È un dettaglio operativo che evita interruzioni banali ma fastidiose.

Verifiche subito dopo il riavvio

Dopo il reboot, non limitarti a controllare che la shell risponda. Devi verificare che il sistema sia davvero sano e che i servizi critici siano tornati operativi. I controlli minimi sono questi:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager

`systemctl --failed` ti mostra eventuali unità rotte; `journalctl -p err -b` concentra gli errori del boot corrente. Se trovi servizi in failed, non partire subito con il tentativo di “riparazione a caso”: identifica il motivo preciso nel log del servizio interessato.

Per web stack e database, la verifica deve essere funzionale, non solo di processo. Un esempio pratico:

curl -I http://localhost
systemctl status apache2 nginx php-fpm mysql postgresql --no-pager

Adatta il comando ai servizi effettivamente presenti. Se il server espone solo backend o API, controlla endpoint applicativi e non solo il servizio di base.

Problemi tipici dopo un salto di release

Un upgrade riuscito a livello di pacchetti non significa che tutto funzioni. I problemi più comuni sono questi: servizi che non partono per configurazioni obsolete, moduli PHP non più allineati, repository di terze parti rimasti attivi, firewall che blocca traffico previsto, o servizi che dipendono da versioni di librerie cambiate.

Un caso frequente è il web server che risponde localmente ma non dall’esterno. In quel caso il problema non è l’upgrade in sé, ma una combinazione tra rete, binding, firewall e regole di sicurezza. Un altro caso tipico è il database che parte ma mostra errori di compatibilità su dump, plugin o motori storage. Anche lì, il sintomo va letto nel log, non intuito.

Per avere evidenza utile, lavora sempre sui log del servizio. I percorsi dipendono dal demone, ma il principio è lo stesso: osserva l’errore reale prima di cambiare altro. Per systemd:

journalctl -u NOME_SERVIZIO -b --no-pager

Sostituisci `NOME_SERVIZIO` con il nome corretto, per esempio `apache2`, `nginx`, `mysql` o `php8.x-fpm` a seconda dello stack. Il vantaggio è che riduci il rumore e guardi solo ciò che conta per il servizio rotto.

Quando non farlo: il caso reale da evitare

Su una macchina che ospita servizi esposti al pubblico, l’upgrade diretto a 21.04 è una scelta debole se non hai una ragione forte. Il rischio non è teorico: release non LTS significa meno tempo per stabilizzare, più probabilità di trovare pacchetti già fuori ciclo e meno margine per rimandare correzioni. Se il server è produttivo, la strada più pulita è restare su LTS e programmare il salto verso una LTS successiva.

Se invece stai lavorando su un laboratorio, una VM di test o una macchina temporanea, l’upgrade a 21.04 può avere senso come esercizio di validazione. In quel caso, il valore non è “avere la versione nuova”, ma capire quali componenti della tua infrastruttura non sono pronti per il salto.

Decisione pratica: upgrade, rebuild o migrazione

Per molti ambienti server la risposta migliore non è l’upgrade in-place ma la migrazione su una nuova macchina. Questo vale soprattutto quando il sistema ha anni di personalizzazioni, repository esterni, servizi legacy o dipendenze delicate. Un rebuild pulito riduce il debito tecnico e ti permette di testare il nuovo stack senza trascinarti dietro residui della vecchia installazione.

La regola pratica è semplice: se il server contiene un solo servizio stateless, l’upgrade può essere ragionevole; se invece ospita più componenti intrecciati, la migrazione su nuova istanza è spesso più sicura e più veloce da ripristinare in caso di problemi. Anche qui il criterio non è “tecnico puro”, ma costo del rischio rispetto al tempo disponibile.

Checklist finale da tenere a portata di mano

Prima di premere invio sul comando di upgrade, ripassa questa sequenza:

• verifica release, kernel e pacchetti bloccati;
• disattiva repository esterni non compatibili;
• salva configurazioni, dati e snapshot;
• aggiorna completamente la release corrente;
• esegui l’upgrade da sessione resiliente (`screen` o `tmux`);
• controlla log, servizi e funzionalità dopo il reboot.

Se uno di questi punti manca, il rischio di fermarti a metà cresce in modo netto. Non è un dettaglio teorico: è proprio lì che si perdono ore in recovery e debugging inutile.

In sintesi, aggiornare Ubuntu 20.04 LTS a 21.04 è tecnicamente possibile, ma operativamente è una scelta da fare con cautela. Su sistemi critici, il criterio giusto non è “posso farlo?”, ma “mi conviene davvero farlo rispetto a una LTS o a una migrazione pulita?”.