Aggiornare Ubuntu 24.04 a 26.04 su un VPS

Quando è possibile aggiornare Ubuntu 24.04 a 26.04?

È possibile aggiornare Ubuntu 24.04 a 26.04 su un VPS quando sarà disponibile la point release 26.04.1, prevista per il 27 agosto 2026. Fino ad allora, un server 24.04 non rileverà la nuova release, come previsto. Ubuntu 26.04 LTS (Resolute Raccoon) è stata rilasciata il 23 aprile 2026, ma Canonical abilita il percorso di aggiornamento da una LTS all'altra soltanto con la prima point release, perché questa include le correzioni per i problemi di installazione e aggiornamento rilevati nei primi mesi.

Esegui il controllo su un server 24.04 all'inizio di agosto 2026. Il risultato sarà il seguente:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Questo non indica un problema del server. /etc/update-manager/release-upgrades contiene Prompt=lts in Ubuntu Server. Di conseguenza, lo strumento propone soltanto la release con supporto a lungo termine successiva, e soltanto quando è disponibile la relativa point release .1. Impostando Prompt=normal, invece, verresti guidato attraverso 24.10, 25.04 e 25.10, una dopo l'altra. Queste release intermedie hanno già raggiunto la fine del ciclo di vita. Lascia lts e attendi. Le date del calendario di Canonical possono cambiare. Se la data passa senza novità, esegui nuovamente il controllo.

Ogni comando riportato di seguito deve essere eseguito manualmente sul tuo server, nell'ordine indicato. Non è possibile simulare un aggiornamento di release sul computer che stai aggiornando. L'aggiornamento sostituisce il kernel e la libreria C e richiede un riavvio per completare l'operazione.

Conviene davvero eseguire l'aggiornamento?

Ubuntu 24.04 riceve aggiornamenti di sicurezza standard fino al 2029, quindi un server di produzione funzionante non ha una scadenza imminente. Eseguite l'aggiornamento se vi serve qualcosa incluso in 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 o il kernel 7.0. Il semplice fatto che "il numero sia aumentato" non giustifica interventi su una macchina che serve i clienti.

Non eseguite l'aggiornamento sul posto se si verifica una di queste condizioni:

• Non avete mai aperto la console del provider (VNC o seriale) né effettuato l'accesso tramite questa. La console è l'unico modo per recuperare l'accesso al server se SSH smette di funzionare; scoprire che non funziona quando siete già bloccati fuori è troppo tardi.
• Non potete permettervi un'ora di downtime e non disponete di un rollback.
• Il vostro stack dipende da un repository di terze parti che non ha ancora pubblicato pacchetti per resolute.
• Il server è stato configurato manualmente più di due anni fa e nessuno sa cosa sia installato.

Spesso è preferibile l'alternativa: create un nuovo VPS 26.04, installate lo stack e ripristinate i dati, quindi cambiate il DNS quando il nuovo server risponde correttamente. Potete mantenere in esecuzione il vecchio server finché il nuovo non ha dimostrato di funzionare; in questo modo il rollback consiste in una modifica DNS anziché in un ripristino. Se scegliete questa strada, iniziate da i primi dieci minuti su un nuovo VPS e configurate correttamente il nuovo server.

Passaggio 1: crea un backup da cui puoi eseguire un ripristino

Usa due livelli, perché possono non funzionare per motivi diversi. Lo snapshot del provider copre l'intero disco e consente un ripristino in pochi minuti, ma viene creato mentre i database stanno scrivendo. Di conseguenza, è coerente dopo un crash, non coerente a livello applicativo. Un backup a livello di file con restic, archiviato fuori dal server consente di recuperare singoli file e offre una copia che resta disponibile anche se il tuo account viene bloccato.

Esegui prima manualmente il dump dei database. Un dump è l'unico backup di un database di cui puoi fidarti senza arrestarlo.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction crea un dump coerente solo per le tabelle InnoDB. Per le tabelle MyISAM è necessario arrestare il database. Il tarball /etc è quello che userai effettivamente, perché contiene ogni file di configurazione su cui l'aggiornamento sta per richiedere conferma.

Un backup da cui non hai mai eseguito un ripristino è solo un'ipotesi. Recupera ora un file dal backup, prima di averne bisogno in una situazione critica.

Passaggio 2: applicare prima tutte le patch a 24.04

do-release-upgrade rifiuta di essere eseguito su un sistema con uno stato dei pacchetti non valido, e un'installazione di 24.04 aggiornata solo parzialmente rende più difficile interpretare ogni errore successivo.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Se dpkg --audit non stampa nulla, nessun pacchetto è configurato solo parzialmente. Se apt-mark showhold non stampa nulla, nessun pacchetto è bloccato su una versione che impedirebbe l'aggiornamento. Rimuovi il blocco per ogni pacchetto elencato usando sudo apt-mark unhold seguito dal nome del pacchetto, oppure considera che il blocco sia stato impostato per un motivo e interrompi qui la procedura.

Riavvia se il kernel è cambiato, in modo da eseguire l'aggiornamento su una macchina che sta eseguendo il codice che ritiene di eseguire.

[ -f /var/run/reboot-required ] && sudo reboot

Controlla quindi lo spazio su disco. Il programma di aggiornamento scarica l'intero insieme di nuovi pacchetti prima di installare qualsiasi elemento e si interrompe mostrando un messaggio che identifica il filesystem se lo spazio disponibile non è sufficiente.

df -h / /boot

Il problema si verifica in genere quando su / rimangono meno di circa 5 GB liberi. Un /boot con meno di 300 MB liberi causa un errore successivo durante l'installazione del kernel, con No space left on device. La causa è generalmente la presenza di kernel obsoleti; sudo apt --purge autoremove li rimuove.

Prima di iniziare, interrompi anche un'altra attività: se gli aggiornamenti automatici di sicurezza vengono eseguiti durante la procedura, acquisiscono il lock di dpkg e il programma di aggiornamento della release si interrompe con Could not get lock /var/lib/dpkg/lock-frontend. Esegui prima sudo systemctl stop unattended-upgrades e riavvia la procedura al termine.

Passaggio 3: controllare i repository di terze parti e i pacchetti bloccati

do-release-upgrade disabilita ogni sorgente apt che non proviene da Ubuntu, perché un pacchetto compilato per noble può compromettere un sistema resolute. In seguito riabilita le sorgenti che riconosce e lascia commentate tutte le altre. Verifica cosa stai mantenendo prima che lo strumento decida al posto tuo.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 usa due formati in quella directory: i file .list nel vecchio formato a una riga e i file .sources in formato deb822, con i campi Types: e Suites:. L'aggiornamento li disabilita entrambi. ubuntu-security-status --thirdparty elenca i pacchetti installati che nessun archivio Ubuntu fornisce: è il conteggio effettivo di ciò che hai aggiunto al sistema. Tutto ciò che compare in /etc/apt/preferences.d/ è un pin, e un pin scritto per noble continuerà a selezionare un pacchetto obsoleto nella nuova release.

Per ogni repository di terze parti, verifica che il fornitore abbia pubblicato una versione per il nuovo codename prima di iniziare. Le suite di Docker sono elencate in https://download.docker.com/linux/ubuntu/dists/ e gli altri fornitori espongono la stessa directory. Una sorgente configurata per una suite inesistente produce questo risultato al primo apt update dopo l'aggiornamento:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Lascia disabilitata la sorgente finché il fornitore non pubblica la nuova versione. Modificare il codename impostandolo su uno per cui il fornitore ha effettivamente creato i pacchetti installa pacchetti collegati alle librerie di sistema errate.

Passaggio 4: esegui l’aggiornamento in tmux, non in una shell SSH semplice

Se la connessione cade mentre do-release-upgrade è in esecuzione in una shell di login semplice, il processo riceve SIGHUP e si interrompe durante la decompressione dei pacchetti. Questo lascia dpkg configurato solo parzialmente e può lasciare il server senza uno stack di rete funzionante, impedendo una nuova connessione. Eseguilo invece all’interno di un multiplexer di terminale, così il processo rimane attivo sul server anche quando il client si disconnette.

sudo apt install -y tmux
tmux new -s upgrade

All’interno di questa sessione:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Prima di modificare qualsiasi elemento, l’upgrader avvia un secondo demone SSH sulla porta 1022 e lo comunica:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Non apre il firewall per questa porta, perché modificare il firewall senza chiedere conferma sarebbe un comportamento imprevisto. Apri manualmente la porta 1022 prima di iniziare e chiudila al termine di sudo ufw delete allow 1022/tcp. Considera che il provider potrebbe gestire un secondo firewall nel proprio pannello di controllo, esterno al server.

Se la connessione cade comunque, accedi di nuovo ed esegui tmux attach -t upgrade. L’aggiornamento è rimasto in esecuzione mentre eri disconnesso.

Passaggio 5: rispondere con attenzione alle richieste relative ai file di configurazione

dpkg richiede una scelta solo per i file modificati da te o da uno script. Ogni richiesta riguarda quindi un file che hai modificato intenzionalmente. Premere Invio per farla scomparire è il modo in cui un server hardenizzato torna silenziosamente alla configurazione predefinita.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Premi prima D, ogni volta. Leggi le modifiche, quindi mantieni la tua versione con N. L'impostazione predefinita è già N ed è la scelta sicura, perché il tuo file funziona oggi, mentre quello fornito dal pacchetto non è mai stato eseguito su questa macchina.

Mantenere il tuo file ha un costo: non ricevi le nuove impostazioni predefinite. Confronta le versioni in un secondo momento, dopo che il server è tornato operativo e non sei sotto pressione.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Ogni file elencato è la versione del maintainer, salvata accanto alla tua. Confrontali uno alla volta e trasferisci le impostazioni importanti. Due file richiedono particolare attenzione: /etc/ssh/sshd_config, perché una scelta errata termina la sessione, e la configurazione del web server, perché una scelta errata rende non disponibili i siti.

L'aggiornamento chiede inoltre quali servizi riavviare, tramite needrestart. Accetta l'elenco completo. Un daemon che continua a usare un file di libreria condivisa eliminato dal disco può terminare in seguito, durante una richiesta che non stai monitorando.

Passaggio 6: riavvia il sistema, quindi controlla la macchina

sudo reboot

Al termine del riavvio:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a dovrebbe restituire Release: 26.04 e Codename: resolute. uname -r dovrebbe mostrare un kernel 7.0. systemctl --failed dovrebbe elencare zero unità; qualsiasi unità presente nell'elenco richiede un controllo successivo. L'ultimo apt update installa gli aggiornamenti pubblicati dopo la creazione delle immagini di rilascio.

PostgreSQL da 16 a 18: il cluster che resta indietro senza segnalarlo

Ubuntu 24.04 include PostgreSQL 16, mentre 26.04 include PostgreSQL 18. L'aggiornamento installa PostgreSQL 18 accanto a PostgreSQL 16, ma non sposta i dati. Il livello postgresql-common di Debian crea un nuovo cluster vuoto per la nuova versione principale sulla prima porta libera. PostgreSQL 16 mantiene la porta 5432 con tutti i dati, mentre PostgreSQL 18 resta vuoto sulla porta 5433. L'applicazione continua a connettersi alla porta 5432 e non sembra esserci alcun problema. Per questo il problema viene spesso scoperto dopo mesi.

pg_lsclusters

La presenza di due cluster indica che la migrazione non è stata eseguita. Eseguila quando puoi arrestare l'applicazione:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Elimina prima il cluster vuoto di PostgreSQL 18, perché pg_upgradecluster non scrive in un cluster di destinazione già esistente. Il metodo predefinito esegue il dump di PostgreSQL 16 e lo ricarica in PostgreSQL 18. Serve quindi spazio libero su disco pari all'incirca alle dimensioni del database. -m upgrade usa invece pg_upgrade ed è molto più veloce con i database di grandi dimensioni. Al termine, leggi la colonna Port: il nuovo cluster prende il controllo della porta 5432, mentre quello precedente resta arrestato. Esegui manualmente la procedura analyze, perché un cluster appena caricato non contiene statistiche e le prime query saranno lente.

Verifica l'applicazione sul nuovo cluster per alcuni giorni. Solo dopo rimuovi quello precedente:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

La directory dei dati del vecchio cluster è il rollback più rapido disponibile. Non eliminarla il giorno dell'aggiornamento.

MySQL da 8.0 a 8.4: l'opzione rimossa che impedisce l'avvio del server

26.04 aggiorna MySQL dalla versione 8.0 alla 8.4 LTS e introduce due modifiche che possono bloccare i server.

Per prima cosa, mysqld non si avvia se la configurazione contiene un'opzione rimossa nella nuova versione. default_authentication_plugin è il caso più comune, perché molte guide meno recenti indicano di impostarla. Il servizio non si avvia e journalctl -u mysql -n 50 indica direttamente la variabile sconosciuta. Elimina quella riga dal file in /etc/mysql/mysql.conf.d/, quindi sudo systemctl start mysql.

In secondo luogo, il plugin mysql_native_password non è più abilitato per impostazione predefinita nella versione 8.4. Di conseguenza, un account che lo utilizza ancora non può effettuare il login. Esegui questo controllo quando utilizzi ancora la versione 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Prima dell'aggiornamento, trasferisci ogni account che mostra mysql_native_password, quindi aggiorna la password nella configurazione dell'applicazione:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Se una libreria client è troppo obsoleta per supportare caching_sha2_password, nella versione 8.4 puoi riabilitare il vecchio plugin aggiungendo mysql_native_password=ON sotto [mysqld]. Usalo solo come soluzione temporanea con una scadenza definita, perché il plugin verrà rimosso completamente.

PHP da 8.3 a 8.5: i tuoi vhost puntano a un socket che non esiste più

24.04 distribuisce PHP 8.3, mentre 26.04 distribuisce PHP 8.5. I pacchetti vengono installati in percorsi versionati e nessun componente riscrive la configurazione del web server. Un vhost nginx che contiene fastcgi_pass unix:/run/php/php8.3-fpm.sock; ora punta a un socket che nessun processo crea, quindi ogni richiesta PHP restituisce 502 e il log degli errori di nginx riporta:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Indica il nuovo socket, verifica la configurazione e ricaricala:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Con Apache e mod_php il sintomo è diverso: Apache non si avvia affatto e sudo apache2ctl -t segnala di non poter caricare libphp8.3.so perché il file non esiste. Il modulo abilitato è un link simbolico a un pacchetto che non è più presente.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Se hai installato il sistema seguendo uno stack LAMP su Ubuntu 24.04, vale la pena verificare entrambi i percorsi, perché la guida lascia un nome di modulo versionato e un socket versionato.

Anche la configurazione di php.ini non viene mantenuta. memory_limit, upload_max_filesize e tutte le altre impostazioni definite si trovano in /etc/php/8.3/, mentre il nuovo albero parte dai valori predefiniti. Confronta i due file e copia manualmente i valori necessari. Copiare l'intero vecchio file sopra quello nuovo trasferisce i valori predefiniti di 8.3 in un'installazione 8.5. Esegui quindi php -m e confronta i risultati: un'estensione installata come php8.3-redis richiede il pacchetto php8.5- e, se proveniva da un PPA, l'aggiornamento ha disabilitato quella sorgente e l'estensione non è più disponibile.

I certificati richiedono una verifica dedicata. Esegui sudo certbot renew --dry-run dopo l'aggiornamento. Il comando verifica l'intero percorso di rinnovo, incluso l'hook che ricarica il web server, senza modificare il certificato attivo. Se un hook richiama un nome di servizio o un binario che è cambiato, l'errore viene rilevato subito invece di verificarsi in modo silenzioso tra 60 giorni. Certbot con Let's Encrypt su nginx descrive come devono essere configurati questi hook.

SSH: l'errore che chiude la sessione in uso

Il prompt sshd_config è il punto in cui si rischia di perdere l'accesso al server. Rispondendo Y si installa il file del maintainer, che scarta PermitRootLogin, PasswordAuthentication, AllowUsers, Port e ogni altra riga aggiunta. Se il firewall consente soltanto una porta personalizzata e la configurazione fornita dal pacchetto è in ascolto sulla porta 22, la connessione successiva viene rifiutata e la sessione attiva è l'ultima disponibile.

Prevenire il problema prima dell'upgrade. Su 24.04, /etc/ssh/sshd_config inizia con Include /etc/ssh/sshd_config.d/*.conf e OpenSSH mantiene il primo valore letto per ogni impostazione. Di conseguenza, un file drop-in incluso all'inizio prevale su tutto ciò che segue. Spostare le impostazioni in un file non gestito da dpkg:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Quando in /etc/ssh/sshd_config non rimane più nulla di propria gestione, quel prompt smette di essere rilevante: entrambe le risposte mantengono le impostazioni, perché queste risiedono in un file diverso.

Una porta personalizzata richiede un controllo aggiuntivo, perché potrebbe non trovarsi dove previsto:

systemctl is-enabled ssh.socket

Se stampa enabled, systemd gestisce la porta in ascolto e la riga Port in sshd_config viene ignorata. Ubuntu utilizza l'attivazione tramite socket per sshd dalla versione 22.10 e questo spiega perché una modifica a Port 2222 sembra non produrre effetti. Impostare il valore direttamente sull'unità socket con sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Il valore vuoto ListenStream= è obbligatorio. Cancella il valore ereditato; senza questa impostazione, il socket resta in ascolto sia sulla porta 22 sia sulla porta 2222. Applicarla con sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Dopo l'upgrade, prima di chiudere la sessione attiva:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Quindi aprire un secondo terminale sul proprio computer e accedere di nuovo. Una shell funzionante nel secondo terminale è l'unica verifica valida. Lasciare aperta la prima sessione finché il nuovo accesso non è riuscito. Messa in sicurezza di SSH su un VPS illustra le impostazioni che conviene mantenere nel file drop-in.

Se è già troppo tardi, la console web del provider consente di accedere senza usare SSH. Accedere alla console, correggere la configurazione, eseguire sudo sshd -t e riavviare il servizio. La console serve proprio a questo: verificare l'accesso prima dell'upgrade, non durante l'upgrade.

FAQ

Perché do-release-upgrade restituisce "No new release found" su Ubuntu 24.04?

Perché /etc/update-manager/release-upgrades contiene Prompt=lts su Ubuntu Server, e questa impostazione offre la release successiva con supporto a lungo termine solo dopo la disponibilità della sua prima point release. Ubuntu 26.04 LTS è stata rilasciata il 23 aprile 2026 e la disponibilità di 26.04.1 è prevista per il 27 agosto 2026. Fino a quella data, un server 24.04 non rileva alcuna nuova release. Lascia invariata l'impostazione invece di passare a Prompt=normal, che instraderebbe l'aggiornamento attraverso le release intermedie.

Devo riavviare il server per completare l'aggiornamento?

Sì. L'aggiornamento installa un nuovo kernel, una nuova libreria C e un nuovo sistema init. Il sistema in esecuzione continua a usare quelli precedenti fino al riavvio. do-release-upgrade chiede di riavviare al termine, e una macchina lasciata in esecuzione "più tardi" usa una combinazione di componenti appartenenti a 2 release. Quando il sistema torna operativo, controlla uname -r per verificare il nuovo kernel e systemctl --failed per individuare i servizi che non sono ripartiti.

Devo aggiornare il server in place o crearne uno nuovo con 26.04?

Quando possibile, crea un server nuovo. Un nuovo VPS consente di installare lo stack, ripristinare i dati e verificare il funzionamento mentre il server precedente continua a gestire il traffico. In questo modo il rollback consiste in una modifica DNS, invece che in un ripristino da backup. Aggiorna in place quando il server contiene dati di stato difficili da spostare, quando il provider addebita i costi per macchina oppure quando disponi di uno snapshot e di un accesso alla console già verificato. La procedura in place è consolidata, ma durante l'ora necessaria per eseguirla non consente un ritorno semplice alla situazione precedente.

Cosa succede se la connessione SSH cade durante l'aggiornamento?

In una normale login shell, il processo riceve SIGHUP e termina a metà procedura, lasciando dpkg configurato solo parzialmente. Avvia la procedura all'interno di tmux o screen: il processo continua a essere eseguito, quindi puoi riconnetterti ed eseguire tmux attach -t upgrade per riprenderla. L'upgrader avvia anche un demone SSH aggiuntivo sulla porta 1022 come secondo metodo di accesso, ma non apre il firewall per quella porta. Perciò consenti prima il traffico sulla porta 1022 e disabilitalo al termine.

Il mio sito PHP restituisce 502 dopo l'aggiornamento. Cosa si è rotto?

Il percorso del socket PHP FPM è cambiato con la versione. Ubuntu 24.04 usa PHP 8.3, mentre 26.04 usa PHP 8.5. Di conseguenza, /run/php/php8.3-fpm.sock non esiste più, mentre il tuo vhost nginx continua a indicarlo. Il log degli errori di nginx mostra connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Aggiorna fastcgi_pass indicando il socket della versione 8.5, esegui sudo nginx -t e quindi ricarica nginx. Con Apache e mod_php, la correzione equivalente consiste nell'eseguire sudo a2dismod php8.3, seguito da sudo a2enmod php8.5 e da un riavvio.