Come aggiornare Ubuntu 24.04 a 26.04 su un VPS

Quando è possibile aggiornare Ubuntu 24.04 a 26.04?

Ora è possibile aggiornare Ubuntu 24.04 a 26.04 su un VPS. Dal 29 settembre 2026, quando Canonical ha abilitato gli aggiornamenti da 24.04 LTS, do-release-upgrade su un server 24.04 offre 26.04.1. Ubuntu 26.04 LTS (Resolute Raccoon) è stato rilasciato il 23 aprile 2026, ma Canonical apre il percorso di aggiornamento da LTS a LTS soltanto dopo la disponibilità della prima point release, perché questa release include le correzioni ai problemi di installazione e aggiornamento rilevati nei primi mesi. Questa volta l'attesa è proseguita oltre la point release: 26.04.1 è stata rilasciata il 27 agosto 2026 e Canonical ha rinviato l'aggiornamento di altre settimane per includere backport pianificati che correggevano regressioni in una versione recente di rust-coreutils. Se questa numerazione non ti è familiare, 26.04.1 non è una versione Ubuntu diversa, ma la stessa 26.04 con quattro mesi di correzioni integrate nei supporti di installazione, ed è proprio per questo la prima versione che Canonical renderà disponibile a un server esistente.

Fino al 29 settembre, eseguendo il controllo su un server 24.04, veniva mostrato questo:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Non si trattava di un problema del server. Se lo visualizzi ancora oggi, controlla l'impostazione da cui dipende. /etc/update-manager/release-upgrades contiene Prompt=lts su Ubuntu Server. Questo significa che lo strumento offre soltanto la successiva release con supporto a lungo termine, e solo dopo che Canonical ha aperto il relativo percorso di aggiornamento. Lascia comunque l'impostazione su lts, perché in una release successiva normal offrirebbe anche le versioni intermedie con supporto breve. Durante l'attesa, Canonical offriva do-release-upgrade -d a chi non voleva rimandare l'aggiornamento. Ora che il percorso è aperto, il comando semplice è quello indicato nell'annuncio per i server. Prima di iniziare, leggi che cosa è cambiato in 26.04.1 e quando è stato aperto il percorso di aggiornamento. Un server che usa ancora 22.04 non può eseguire direttamente questo passaggio, perché l'upgrader offre sempre e soltanto la LTS successiva. Per questo, aggiornare 22.04 a 26.04 passando per 24.04 descrive il primo passaggio e lo snapshot da creare prima del secondo.

Ogni comando riportato di seguito deve essere eseguito da te sul tuo server, nell'ordine indicato. Non è possibile provare un aggiornamento di release sulla macchina che stai aggiornando. L'aggiornamento sostituisce il kernel e la libreria C e richiede un riavvio per essere completato.

Conviene davvero eseguire l'aggiornamento?

Ubuntu 24.04 riceve aggiornamenti di sicurezza standard fino al 2029, quindi un server di produzione funzionante non è soggetto a scadenze imminenti. Esegui l'aggiornamento perché ti 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 modifiche a una macchina che gestisce servizi per i clienti.

Non eseguire un aggiornamento in-place se è vera una delle seguenti condizioni:

• Non hai mai aperto la console del provider (VNC o seriale) né effettuato l'accesso tramite quella console. È l'unico modo per recuperare l'accesso al server se SSH non funziona; scoprire che la console non funziona quando hai già perso l'accesso è troppo tardi.
• Non puoi permetterti un'ora di downtime e non disponi di un rollback.
• Il tuo stack dipende da un repository di terze parti che non ha ancora pubblicato pacchetti per resolute.
• Il server è stato configurato manualmente oltre due anni fa e nessuno sa cosa sia installato.

Spesso è preferibile l'alternativa: crea un nuovo VPS con 26.04, installa lo stack e ripristina i dati, quindi cambia il DNS quando il nuovo server risponde correttamente. Puoi mantenere in esecuzione il vecchio server finché il nuovo non ha dimostrato di essere affidabile, e il rollback consiste in una modifica DNS invece che in un ripristino. Se scegli questa strada, inizia da i primi dieci minuti su un nuovo VPS e configura correttamente il nuovo server.

Passaggio 1: crea un backup da cui sia possibile ripristinare

Usa due livelli, perché possono avere guasti diversi. Lo snapshot del provider copre l’intero disco e consente di ripristinare il sistema in pochi minuti, ma viene creato mentre i database eseguono scritture. Per questo garantisce la consistenza in caso di arresto anomalo, non la consistenza applicativa. Un backup a livello di file con restic, archiviato fuori dal server consente di recuperare singoli file e fornisce una copia che resta disponibile anche se l’account viene bloccato.

Esegui prima manualmente il dump dei database. Un dump è un metodo per eseguire il backup di un database in esecuzione.

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. Le tabelle MyISAM richiedono blocchi per ottenere un dump coerente. L’archivio tar /etc è quello che userai concretamente, perché contiene ogni file di configurazione su cui l’aggiornamento sta per richiedere conferma.

Un backup che non hai mai ripristinato è solo un’ipotesi. Recupera ora un file dal backup, prima di doverlo fare in condizioni di pressione.

Passaggio 2: completa prima la patch 24.04

do-release-upgrade rifiuta di essere eseguito su un sistema con uno stato dei pacchetti non integro, e una 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 è soggetto a un blocco dpkg. Non mostra i pin delle preferenze di APT, che sono un meccanismo separato e possono anch'essi impedire l'aggiornamento di un pacchetto; il passaggio 3 li controlla. Rimuovi ogni blocco elencato da showhold con sudo apt-mark unhold e il nome del pacchetto, oppure considera che il blocco esiste per un motivo e interrompi qui.

Riavvia se il kernel è cambiato, così esegui 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 nuovo set di pacchetti prima di installare qualsiasi elemento e si interrompe con un messaggio che indica il filesystem se lo spazio disponibile non è sufficiente.

df -h / /boot

La causa è generalmente la presenza di kernel obsoleti, che sudo apt --purge autoremove rimuove.

Prima di iniziare, arresta anche un altro processo: se gli aggiornamenti automatici di sicurezza vengono eseguiti durante l'operazione, mantengono bloccato 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 riavvialo al termine.

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

Per impostazione predefinita, do-release-upgrade commenta ogni sorgente APT che non proviene da Ubuntu, perché un pacchetto compilato per noble può danneggiare un sistema resolute. La relativa opzione --allow-third-party li mantiene invece abilitati, con esattamente questo rischio. Verificate cosa state mantenendo prima che sia lo strumento a decidere al posto vostro.

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 vecchi file .list a una riga e i file .sources deb822 con i campi Types: e Suites:. Un aggiornamento standard disabilita entrambi. ubuntu-security-status --thirdparty elenca i pacchetti installati che nessun archivio Ubuntu fornisce: è il conteggio effettivo di ciò che avete aggiunto manualmente. Un file in /etc/apt/preferences.d/ viene letto come configurazione di pinning solo se il nome non ha un'estensione o termina con .pref e contiene esclusivamente lettere, cifre, trattini, caratteri di sottolineatura e punti; APT ignora qualsiasi altro file, in genere mostrando un avviso. Un pin che specifica noble può mantenere un pacchetto a una versione precedente dopo l'aggiornamento, in base alle versioni ancora disponibili e alla priorità impostata dal pin. Leggete quindi ogni file e decidete se è ancora necessario.

Per ogni repository di terze parti, verificate 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/; anche gli altri fornitori espongono la stessa directory. Una sorgente che punta a 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.

Docker pubblica ora una suite resolute. Lasciate disabilitata qualsiasi sorgente la cui suite non esista, finché il fornitore non la pubblica. Modificare il codename impostandolo su uno per il quale il fornitore ha creato i pacchetti significa installare pacchetti collegati alle librerie di sistema sbagliate.

Passo 4: esegui l'aggiornamento in tmux, non in una semplice shell SSH

L'aggiornamento del server viene normalmente eseguito all'interno di GNU screen e supporta il ricollegamento dopo un'interruzione della connessione. La perdita della connessione SSH, quindi, non interrompe di per sé l'aggiornamento. Eseguilo anche all'interno di una tua sessione tmux, in modo da avere una sessione denominata a cui riconnetterti.

sudo apt install -y tmux
tmux new -s upgrade

All'interno di quella sessione:

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

Prima di modificare qualsiasi cosa, l'aggiornamento 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 quella porta, perché aprire una porta nel firewall senza chiedere conferma sarebbe un comportamento inatteso. Apri manualmente la porta 1022 prima di iniziare e chiudila quando hai terminato con sudo ufw delete allow 1022/tcp. Ricorda che il provider potrebbe gestire un secondo firewall nel pannello di controllo, esterno al server.

Se la connessione si interrompe comunque, accedi di nuovo ed esegui tmux attach -t upgrade. L'aggiornamento ha continuato a essere eseguito mentre eri assente. Se invece si è interrotto e trovi dpkg parzialmente configurato o sorgenti apt che sono in parte noble e in parte resolute, il ripristino dopo un aggiornamento di versione non riuscito descrive come correggere lo stato dei pacchetti e capire quando interrompere i tentativi di riparazione e ripristinare invece lo snapshot.

Passaggio 5: rispondere con attenzione alle richieste sui file di configurazione

dpkg richiede una risposta solo per i file modificati da te o da uno script. Ogni richiesta riguarda quindi un file modificato da te o da uno script. Premendo Invio mantieni per impostazione predefinita la versione attuale.

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 decidi se mantenere la tua versione con N o installare quella del manutentore. L'impostazione predefinita è già N, ma mantenere il vecchio file non è sicuro per ogni pacchetto: per consentire il corretto funzionamento del sistema aggiornato possono essere necessarie alcune modifiche alla configurazione.

Mantenere il tuo file ha un costo: non ricevi i nuovi valori predefiniti. Riconcilia le modifiche in seguito, quando il server è operativo e non sei sotto pressione.

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

Per ogni file che elenca, viene salvata la versione del manutentore accanto alla tua. Confrontali uno alla volta e copia le impostazioni importanti. Presta particolare attenzione a due file: /etc/ssh/sshd_config, perché una risposta errata chiude la sessione, e la configurazione del web server, perché una risposta errata rende inaccessibili i siti.

Da Ubuntu 24.04, needrestart riavvia automaticamente per impostazione predefinita i servizi interessati. Se hai ripristinato la modalità interattiva, accetta l'elenco completo. Un daemon che utilizza ancora una vecchia libreria condivisa rimane esposto ai bug corretti dall'aggiornamento finché non viene riavviato.

Passaggio 6: riavviare, quindi controllare la macchina

sudo reboot

Quando il sistema è nuovamente disponibile:

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 riportare Release: 26.04 e Codename: resolute. uname -r dovrebbe mostrare un kernel 7.0. systemctl --failed dovrebbe elencare zero unità; qualsiasi unità elencata costituisce la prossima attività da svolgere. L'ultimo apt update aggiorna gli indici dei pacchetti, mentre apt full-upgrade installa gli aggiornamenti pubblicati dopo che l'upgrade ha scaricato i relativi pacchetti.

Da PostgreSQL 16 a 18: il cluster che rimane silenziosamente indietro

Ubuntu 24.04 include PostgreSQL 16, mentre 26.04 include PostgreSQL 18. L'aggiornamento installa la versione 18 accanto alla 16, ma non trasferisce i dati. Il livello postgresql-common di Debian crea un cluster principale durante l'installazione del pacchetto server solo se non esistono ancora cluster. Di conseguenza, un cluster PostgreSQL 16 esistente non acquisisce automaticamente un cluster 18 vuoto sulla porta 5433. L'applicazione continua a usare la porta 5432 e non si nota alcun problema. Per questo il problema viene spesso scoperto dopo mesi.

pg_lsclusters

Una voce relativa alla versione 16 indica che il cluster usa ancora la versione 16. Se pg_lsclusters elenca anche un cluster 18 main, verifica che sia vuoto prima di rimuoverlo con sudo pg_dropcluster --stop 18 main, perché pg_upgradecluster non scrive in un cluster di destinazione già esistente. Esegui la migrazione quando puoi arrestare l'applicazione:

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

Il metodo predefinito esegue il dump della versione 16 e lo ricarica nella versione 18. Serve quindi spazio libero su disco pari, indicativamente, alle dimensioni del database. -m upgrade usa invece pg_upgrade ed è molto più veloce con database di grandi dimensioni. Al termine, controlla la colonna Port: il nuovo cluster occupa la porta 5432 e quello precedente rimane arrestato. L'hook di aggiornamento del pacchetto esegue automaticamente un passaggio di analisi. Il comando precedente lo ripete in modo esplicito.

Testa 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 cluster precedente è il rollback più rapido disponibile. Non eliminarla il giorno dell'aggiornamento.

MySQL 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 due modifiche 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 identifica 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 l'accesso. Esegui questo controllo mentre usi ancora la versione 8.0:

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

Prima dell'aggiornamento, modifica tutti gli account che mostrano 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 vecchia per utilizzare 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 data di dismissione, perché MySQL ha rimosso il plugin nella versione 9.0.

Da PHP 8.3 a 8.5: i virtual host puntano a un socket che non esiste più

24.04 include PHP 8.3 e 26.04 include PHP 8.5. I pacchetti vengono installati in percorsi specifici per versione e nessun componente riscrive la configurazione del server web. Un virtual host nginx che contiene fastcgi_pass unix:/run/php/php8.3-fpm.sock; ora punta a un socket che nessun processo crea. Di conseguenza, ogni richiesta PHP restituisce 502 e il log degli errori di nginx contiene:

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

Modificatelo in modo che punti al nuovo socket, verificate la configurazione e ricaricatela:

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 e sudo apache2ctl -t segnala che non riesce a caricare libphp8.3.so perché il file non esiste. Il modulo abilitato è un collegamento simbolico a un pacchetto che non è più installato.

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

Se avete configurato il server seguendo uno stack LAMP su Ubuntu 24.04, vale la pena controllare entrambi i percorsi, perché la guida lascia un nome di modulo specifico per versione e un socket specifico per versione.

Anche la configurazione di php.ini non viene trasferita automaticamente. 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. Confrontate i due file e copiate manualmente i valori. Copiare l'intero vecchio file sopra quello nuovo trasferisce i valori predefiniti di 8.3 in un'installazione 8.5. Eseguite quindi php -m e confrontate l'output: un'estensione installata come php8.3-redis richiede il pacchetto php8.5- e, se proveniva da un PPA, l'aggiornamento ha disabilitato quella sorgente, quindi l'estensione non è più disponibile.

I certificati richiedono una verifica specifica. Eseguite sudo certbot renew --dry-run --run-deploy-hooks dopo l'aggiornamento. Il comando verifica l'intero percorso di rinnovo, incluso l'hook per ricaricare il server web, 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 al rinnovo successivo. Certbot con Let's Encrypt su nginx descrive l'aspetto corretto di questi hook.

SSH: l'errore che chiude la sessione in uso

Il prompt sshd_config è il punto in cui ci si può escludere dal server. Rispondere Y installa il file del manutentore, che elimina PermitRootLogin, PasswordAuthentication, AllowUsers, Port e tutte le altre righe aggiunte. Se il firewall consente soltanto una porta personalizzata e la configurazione fornita dal pacchetto resta in ascolto sulla 22, la connessione successiva viene rifiutata e la sessione attiva è l'ultima disponibile.

Prevenite il problema prima dell'upgrade. Su Ubuntu 24.04, /etc/ssh/sshd_config inizia con Include /etc/ssh/sshd_config.d/*.conf e, per la maggior parte delle impostazioni, OpenSSH mantiene il primo valore letto. Un file drop-in incluso all'inizio ha quindi la precedenza sulla stessa impostazione più avanti. Alcune direttive fanno eccezione: Port e ListenAddress accettano più valori, quindi una riga Port in un file drop-in aggiunge una porta invece di sostituire quella impostata più avanti. Spostate le vostre impostazioni in un file che dpkg non gestisce:

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 resta più nulla di vostro, quel prompt non è più importante: qualunque risposta scegliate, le vostre impostazioni restano attive perché si trovano in un file diverso.

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

systemctl is-enabled ssh.socket

Se stampa enabled, è systemd ad aprire la porta in ascolto, non sshd. Ubuntu usa l'attivazione tramite socket per sshd dalla versione 22.10. Su 24.04, un generatore di systemd legge le impostazioni Port e ListenAddress dalla configurazione di sshd e le converte negli indirizzi di ascolto del socket, ma soltanto quando systemd ricarica le proprie unità. Per questo una modifica a Port 2222 sembra non avere effetto: diventa attiva dopo sudo systemctl daemon-reload && sudo systemctl restart ssh.socket e il file sshd_config fornito dal pacchetto ora contiene una nota che lo indica. Per impostare direttamente la porta sull'unità socket, usate invece sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Il valore vuoto ListenStream= è obbligatorio. Cancella il valore ereditato; senza di esso, il socket resta in ascolto sia sulla 22 sia sulla 2222. Applicate la modifica con sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Dopo l'upgrade, prima di chiudere la sessione in uso:

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

Aprite quindi un secondo terminale sul vostro computer e accedete di nuovo. Una shell funzionante nel secondo terminale è l'unica verifica valida. Lasciate aperta la prima sessione finché non avete completato il test. 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. Effettuate l'accesso, correggete la configurazione, eseguite sudo sshd -t e riavviate 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?

Dal 29 settembre 2026 non dovrebbe più accadere, perché in quella data Canonical ha abilitato gli aggiornamenti da 24.04 LTS a 26.04.1. Prima di allora il messaggio era previsto: Ubuntu 26.04 LTS è stato rilasciato il 23 aprile 2026, 26.04.1 è seguito il 27 agosto e il percorso è rimasto chiuso ancora per alcune settimane mentre Canonical integrava le correzioni per le regressioni di rust-coreutils. Se lo visualizzi ancora, verifica che /etc/update-manager/release-upgrades contenga Prompt=lts, l'impostazione predefinita di Ubuntu Server, che propone solo la release successiva con supporto a lungo termine. Mantienila su lts.

Devo riavviare il server per completare l'aggiornamento?

Sì. L'aggiornamento installa un nuovo kernel, una nuova libreria C e un nuovo sistema init, ma il sistema in esecuzione continua a usare quelli precedenti finché non viene riavviato. do-release-upgrade chiede di riavviare al termine dell'operazione e una macchina lasciata in esecuzione fino a "più tardi" utilizza componenti appartenenti a due release diverse. Al ritorno del sistema, 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 permette di installare lo stack, ripristinare i dati e verificare tutto mentre il server precedente continua a gestire il traffico. In questo modo il rollback consiste in una modifica DNS, non in un ripristino da backup. Esegui l'aggiornamento in place quando il server contiene dati di stato difficili da spostare, quando il provider fattura ogni macchina oppure quando disponi di uno snapshot e di un accesso alla console già verificato. Il percorso in place è collaudato, ma durante l'operazione è irreversibile per circa un'ora.

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

L'upgrader del server usa normalmente GNU screen, quindi la caduta della connessione SSH non interrompe di per sé l'aggiornamento. Se lo hai avviato nella sessione tmux denominata indicata sopra, riconnettiti ed esegui tmux attach -t upgrade per riprendere l'operazione. L'upgrader avvia anche un demone SSH aggiuntivo sulla porta 1022 come secondo metodo di accesso, ma non apre il firewall per quella porta. Devi quindi consentire prima la porta 1022 e chiuderla 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 esegue PHP 8.3, mentre 26.04 esegue PHP 8.5. Di conseguenza, /run/php/php8.3-fpm.sock non esiste più, mentre il virtual host 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 8.5, esegui sudo nginx -t, quindi ricarica nginx. Con Apache e mod_php, la correzione equivalente consiste nell'eseguire sudo a2dismod php8.3, poi sudo a2enmod php8.5 e infine riavviare il servizio.