Perché l’upgrade a 21.04 va pianificato con attenzione
Passare da Ubuntu 20.04 a 21.04 non è un semplice cambio di versione: stai spostando il sistema verso una release intermedia, con ciclo di vita breve e finestre di supporto più strette rispetto a una LTS. Questo significa che l’aggiornamento ha senso solo se ti serve davvero una versione più recente di kernel, pacchetti o stack applicativi, e se sei pronto a gestire un eventuale rientro o una successiva migrazione verso una release supportata a lungo termine.
In pratica, prima di toccare la macchina devi chiarire tre cose: lo stato attuale del sistema, il metodo di upgrade che vuoi usare e il piano di ritorno in caso di problemi. Su server remoti, soprattutto se ospitano servizi esposti, conviene trattare l’operazione come un change controllato, non come una manutenzione di routine.
Verifiche preliminari prima di partire
Prima di avviare l’upgrade, controlla che il sistema sia effettivamente Ubuntu 20.04 e che i repository siano coerenti. Un sistema con sorgenti miste, PPA vecchi o pacchetti mantenuti a mano può fallire durante la risoluzione delle dipendenze.
Esegui questi controlli minimi:
lsb_release -a
cat /etc/os-release
apt policy | head -n 40
Il primo comando conferma la release in uso, il secondo mostra i dati base del sistema e il terzo ti aiuta a capire se i repository puntano a sorgenti standard o se ci sono pinning e priorità insolite. Se trovi repository di terze parti non indispensabili, disabilitali prima dell’upgrade: riduci il rischio di conflitti e semplifichi il rollback.
Controlla anche spazio disco e stato dei servizi fondamentali. Un upgrade interrotto per mancanza di spazio lascia spesso il sistema in uno stato misto, difficile da recuperare senza interventi manuali.
df -h
systemctl --failed
free -h
Se il nodo ospita servizi critici, annota anche le versioni attuali di database, web server, PHP, Python o runtime applicativi. Non serve avere un inventario perfetto, ma devi sapere cosa stai per aggiornare e cosa potrebbe cambiare come comportamento.
Backup e rollback: quello che serve davvero
Il rollback più affidabile non è “reinstallo tutto a mano”, ma un backup consistente prima di iniziare. Su una macchina virtuale, uno snapshot è spesso la soluzione più rapida. Su server fisici o ambienti senza snapshot, serve almeno un backup dei file di configurazione e dei dati applicativi critici.
Minimo sindacale:
- Snapshot della VM o immagine disco, se disponibile.
- Backup di
/etce delle configurazioni applicative personalizzate. - Dump dei database e copia dei documenti o dei volumi dati più importanti.
Un esempio rapido per salvare la configurazione di sistema prima dell’upgrade:
sudo tar -czf /root/etc-backup-$(date +%F).tar.gz /etc
Se hai database MySQL o MariaDB, non affidarti solo ai file di dati a caldo: fai un dump logico o un backup coerente con il motore e il carico in corso. In ambienti PostgreSQL vale lo stesso principio: scegli un metodo compatibile con il livello di consistenza che ti serve.
Aggiornare Ubuntu 20.04 a 21.04 da terminale
Il percorso da terminale è quello più controllabile e quello che consiglio quasi sempre su server e workstation amministrate con criterio. Prima aggiorna la release corrente, poi verifica che il gestore degli upgrade sia installato e configurato per passare alla release successiva.
- Sincronizza l’indice dei pacchetti e installa gli aggiornamenti disponibili.
- Rimuovi eventuali pacchetti non più necessari.
- Avvia il processo di upgrade della distribuzione.
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt autoremove --purge
sudo do-release-upgrade
Il comando do-release-upgrade è quello che gestisce il salto di versione. Se il sistema non propone ancora la nuova release, può dipendere dal canale configurato per gli aggiornamenti oppure dal fatto che il controllo sia stato eseguito troppo presto rispetto alla disponibilità nei mirror. In quel caso, non forzare a caso: verifica la configurazione di /etc/update-manager/release-upgrades.
cat /etc/update-manager/release-upgrades
Il parametro Prompt deve essere impostato in modo coerente con il tipo di upgrade che vuoi eseguire. Con normal il sistema può proporre anche release intermedie; con lts resti su migrazioni verso versioni LTS. Se stai puntando a 21.04, il comportamento atteso è che il sistema consenta l’upgrade verso la release intermedia disponibile.
Durante la procedura, il gestore può chiederti come trattare file di configurazione modificati localmente. Qui non esiste una risposta unica: se hai personalizzazioni importanti, conserva la versione locale e confronta poi le differenze; se il file è standard e non contiene modifiche utili, puoi accettare la versione del maintainer. Su host di produzione, però, ogni scelta va fatta con cognizione, perché un file di configurazione sovrascritto può interrompere un servizio al reboot successivo.
Gestire i repository di terze parti prima del salto
I repository esterni sono uno dei motivi più comuni di upgrade fallito. Un PPA che non ha pacchetti per la nuova release può bloccare la risoluzione delle dipendenze o introdurre versioni incoerenti con la base del sistema. Per questo conviene disabilitare temporaneamente le sorgenti non essenziali.
Puoi farlo da terminale commentando le righe corrispondenti nei file sotto /etc/apt/sources.list.d/ oppure usando gli strumenti grafici se lavori su desktop. Prima di modificare, fai una copia dei file interessati.
sudo cp -a /etc/apt/sources.list.d /root/sources.list.d.backup
ls /etc/apt/sources.list.d/
Dopo l’upgrade, riattiva solo i repository davvero necessari e verifica che siano compatibili con 21.04. Questo passaggio è più importante di quanto sembri: molti problemi “misteriosi” dopo un upgrade derivano in realtà da pacchetti esterni rimasti agganciati a versioni vecchie.
Usare l’interfaccia grafica su Ubuntu Desktop
Su Ubuntu Desktop puoi eseguire l’upgrade anche dall’interfaccia grafica, tramite l’applicazione di aggiornamento software. Il flusso è più semplice per chi lavora su postazioni utente, ma resta meno trasparente rispetto al terminale, soprattutto quando devi capire dove si è bloccato il processo.
- Apri il gestore aggiornamenti.
- Installa tutti gli update disponibili per la release corrente.
- Riavvia se richiesto.
- Riapri il gestore e attendi la notifica dell’upgrade alla nuova versione.
- Segui la procedura guidata fino al completamento.
In ambiente desktop, il vantaggio della GUI è ridurre gli errori operativi. Lo svantaggio è che hai meno controllo sul dettaglio dei pacchetti e meno visibilità sui conflitti. Se qualcosa va storto, torna comunque al terminale per leggere i log e capire il punto esatto dell’interruzione.
Per verificare lo stato dell’upgrade su sistemi desktop puoi controllare la presenza di processi legati al gestore aggiornamenti e, dopo il riavvio, confermare la versione con lo stesso comando usato da terminale:
lsb_release -a
Cosa fare se l’upgrade si blocca
Se il processo si ferma, non rilanciare subito il comando alla cieca. Prima identifica il punto di arresto: dipendenze, pacchetti trattenuti, repository non raggiungibili, spazio disco insufficiente o conflitto di configurazione. La lettura dei log ti fa risparmiare tempo rispetto a tentativi ripetuti.
I log più utili sono quelli del gestore pacchetti e dell’upgrade della distribuzione. I path possono variare in base al contesto, ma in genere vale la pena guardare:
/var/log/apt/term.log
/var/log/dist-upgrade/main.log
/var/log/dist-upgrade/apt.log
Se trovi errori su pacchetti trattenuti, prova a risolvere la coda degli aggiornamenti prima di riprendere. Se compare una dipendenza irrisolvibile, il problema è quasi sempre una sorgente esterna o un pacchetto non compatibile con la nuova release. In questi casi la soluzione minima e reversibile è rimuovere o disabilitare la sorgente problematica, aggiornare l’indice e riprovare.
sudo apt update
sudo apt -f install
sudo dpkg --configure -a
Se invece il sistema è rimasto a metà upgrade e non parte più con normalità, evita di improvvisare. Verifica prima se i servizi di base sono in errore, se il filesystem è pieno o se ci sono pacchetti lasciati in stato incoerente. Solo dopo valuta un intervento più profondo o il ripristino da snapshot.
Verifiche dopo il riavvio
Una volta completato l’upgrade e riavviato il sistema, non limitarti a controllare la versione. Devi verificare che il nodo sia effettivamente sano e che i servizi principali siano tornati operativi.
- Conferma la nuova release con
lsb_release -a. - Controlla i servizi falliti con
systemctl --failed. - Verifica rete, DNS e connettività verso i servizi interni.
- Apri i log delle applicazioni principali.
- Controlla la presenza di eventuali pacchetti rimasti in stato incompleto.
systemctl --failed
journalctl -p err -b --no-pager | head -n 50
apt-mark showhold
Se il server ospita web stack, mail server o database, fai anche un controllo funzionale: una richiesta HTTP, un accesso al database, l’invio di una mail di test o il check dell’endpoint applicativo. Il punto non è solo sapere che il sistema è “su”, ma che i servizi si comportano come prima o meglio di prima.
Nota pratica su Ubuntu 21.04 come destinazione
Qui va detta una cosa importante: Ubuntu 21.04 è una release intermedia con supporto limitato nel tempo. Se stai leggendo questa guida per un sistema da mantenere nel medio periodo, la scelta più sensata oggi è usare una LTS supportata, non fermarti a 21.04. Il salto verso 21.04 può avere senso solo per esigenze specifiche di test, compatibilità o laboratorio.
Questa informazione non cambia la procedura tecnica dell’upgrade, ma cambia la strategia. Se il tuo obiettivo è stabilità, l’upgrade dovrebbe essere un passaggio verso una versione con supporto esteso. Se invece stai validando un software su una release precisa, allora il lavoro va fatto in un ambiente controllato, con snapshot e con un piano di rientro già definito.
Checklist sintetica da usare prima di premere Invio
Se vuoi ridurre gli errori, usa questa sequenza mentale prima di avviare l’upgrade:
- Ho un backup o uno snapshot recente.
- Ho verificato spazio disco e stato dei servizi.
- Ho disabilitato i repository esterni non necessari.
- Ho aggiornato completamente la release corrente.
- So come controllare i log se qualcosa si rompe.
Se uno di questi punti manca, fermati e chiudilo prima di procedere. Un upgrade fatto bene non è quello più veloce, ma quello che puoi spiegare e, se serve, recuperare senza improvvisazioni.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.