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 viene rilasciata la point release 26.04.1, prevista per il 27 agosto 2026. Fino ad allora, un server 24.04 non rileverà la nuova release, intenzionalmente. Ubuntu 26.04 LTS (Resolute Raccoon) è stata rilasciata il 23 aprile 2026, ma Canonical abilita il percorso di aggiornamento da LTS a LTS solo con la prima point release, perché questa include le correzioni ai problemi di installazione e aggiornamento individuati nei primi mesi. Se la numerazione non ti è familiare, 26.04.1 non è una versione di Ubuntu diversa, ma la stessa 26.04 con quattro mesi di correzioni integrate nel supporto di installazione, ed è proprio per questo la prima versione che Canonical proporrà a un server esistente.

Esegui il controllo su un server 24.04 all'inizio di agosto 2026 e ottieni questo risultato:

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 su Ubuntu Server, quindi lo strumento propone soltanto la prossima release con supporto a lungo termine, e solo quando è disponibile la relativa point release .1. Impostando Prompt=normal, invece, verrebbero proposte in successione 24.10, 25.04 e 25.10, release intermedie che hanno tutte raggiunto la fine del ciclo di vita. Mantieni lts e attendi. Le date del calendario di Canonical possono cambiare, quindi esegui nuovamente il controllo se la data passa senza che venga proposta alcuna release.

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

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 puoi eseguire un ripristino

Usa due livelli, perché possono fallire in modi diversi. Uno snapshot del provider copre l'intero disco e consente di completare il ripristino in pochi minuti, ma viene acquisito mentre i database stanno scrivendo. Di conseguenza, è coerente rispetto a un arresto anomalo, non coerente a livello applicativo. Un backup a livello di file con restic, archiviato fuori dal server ti consente di recuperare singoli file e mantiene una copia disponibile anche se il tuo account viene bloccato.

Prima esegui manualmente il dump dei database. Un dump è l'unico backup di un database che puoi considerare affidabile senza arrestare il database.

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 produce un dump coerente soltanto per le tabelle InnoDB. Per le tabelle MyISAM è necessario arrestare il database. L'archivio tar /etc è quello che userai effettivamente, perché contiene tutti i file di configurazione sui quali l'aggiornamento sta per richiedere conferma.

Un backup da cui non hai mai eseguito un ripristino è solo un'ipotesi. Recupera subito un file, prima di doverlo fare in una situazione critica.

Passaggio 2: completa prima l'applicazione delle patch a 24.04

do-release-upgrade rifiuta di essere eseguito su un sistema con uno stato dei pacchetti non integro, e un 24.04 aggiornato 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 a una versione che impedirebbe l'aggiornamento. Rimuovi il blocco per ogni pacchetto elencato con sudo apt-mark unhold e il nome del pacchetto, oppure considera che il blocco esista per un motivo e interrompi qui la procedura.

Riavvia se è cambiato il kernel, così esegui l'aggiornamento da una macchina che utilizza il codice che ritiene effettivamente in esecuzione.

[ -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 interrompe l'esecuzione con un messaggio che indica il filesystem se lo spazio disponibile non è sufficiente.

df -h / /boot

Con meno di circa 5 GB liberi su / si verificano problemi. Un /boot inferiore a 300 MB causa un errore successivo durante l'installazione del kernel, con No space left on device. Di solito la causa sono i 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, mantengono 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 tutte le sorgenti apt che non appartengono a Ubuntu, perché un pacchetto compilato per noble può causare il malfunzionamento di un sistema resolute. Riattiva successivamente quelle che riconosce e lascia commentate le altre. Prima di lasciare che lo strumento decida, verifica quali componenti stai mantenendo.

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 deb822 con i campi Types: e Suites:. L'upgrade disabilita entrambi. ubuntu-security-status --thirdparty elenca i pacchetti installati che nessun archivio Ubuntu fornisce. Questo è il conteggio effettivo dei componenti aggiunti manualmente. Tutto ciò che si trova in /etc/apt/preferences.d/ è un pin. 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/. Anche gli altri fornitori espongono la stessa directory. Una sorgente che punta a una suite inesistente produce questo messaggio al primo apt update dopo l'upgrade:

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 versione necessaria. Modificare il codename impostandolo su uno per il quale il fornitore ha effettivamente compilato i pacchetti porta a installare pacchetti collegati alle librerie di sistema errate.

Passo 4: eseguire 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 il server potrebbe non avere più uno stack di rete funzionante a cui riconnettersi. Eseguire invece il comando 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

L'aggiornamento avvia un secondo demone SSH sulla porta 1022 prima di modificare qualsiasi cosa e lo comunica esplicitamente:

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 la porta nel firewall, perché modificare il firewall senza chiedere conferma sarebbe un comportamento inatteso. Aprire manualmente la porta 1022 prima di iniziare e chiuderla al termine di sudo ufw delete allow 1022/tcp. Tenere presente che il provider potrebbe gestire un secondo firewall nel relativo 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 durante la tua assenza. In caso contrario, potresti ritrovarti con dpkg configurato solo parzialmente oppure con le sorgenti APT composte in parte da noble e in parte da resolute. La procedura per recuperare un aggiornamento di release non riuscito descrive come ripristinare lo stato dei pacchetti e capire quando interrompere le operazioni di riparazione e ripristinare invece lo snapshot.

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

dpkg richiede una risposta soltanto 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 protetto 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 conserva la tua versione con N. L'opzione predefinita è già N ed è la risposta sicura, perché il tuo file funziona oggi mentre quello fornito dal pacchetto non è mai stato eseguito su questa macchina.

Conservare il tuo file ha un costo: non ricevi le nuove impostazioni predefinite. Riconcilia le differenze in seguito, quando il sistema è operativo e non sei sotto pressione.

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

Ogni file indicato è la versione del manutentore, salvata accanto alla tua. Confrontali uno alla volta e trasferisci le impostazioni importanti. Presta particolare attenzione a due file: /etc/ssh/sshd_config, perché una risposta errata termina la sessione, e alla configurazione del web server, perché una risposta errata rende non disponibili i siti.

L'aggiornamento chiede inoltre quali servizi riavviare, tramite needrestart. Accetta l'elenco completo. Un demone ancora in esecuzione con una libreria condivisa che è stata eliminata dal disco può terminare in modo anomalo alla richiesta successiva, mentre non stai monitorando il sistema.

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 deve riportare Release: 26.04 e Codename: resolute. uname -r deve mostrare un kernel 7.0. systemctl --failed deve elencare zero unità; ogni unità visualizzata richiede un controllo successivo. L'ultimo apt update scarica gli aggiornamenti pubblicati dopo la creazione delle immagini di rilascio.

PostgreSQL da 16 a 18: il cluster che rimane indietro senza farsi notare

Ubuntu 24.04 include PostgreSQL 16, mentre Ubuntu 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 continua a usare la porta 5432 con tutti i dati, mentre PostgreSQL 18 resta vuoto sulla porta 5433. L'applicazione continua a collegarsi alla porta 5432 e tutto sembra funzionare normalmente. Per questo il problema viene spesso scoperto dopo mesi.

pg_lsclusters

Se nell'elenco compaiono due cluster, la migrazione non è stata eseguita. Eseguila quando puoi fermare 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, quindi serve 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 usa la porta 5432 e quello precedente viene lasciato arrestato. Esegui manualmente il passaggio di analisi, 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 8.0 a 8.4: l'opzione rimossa che impedisce l'avvio del server

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

Primo: mysqld rifiuta di avviarsi quando la configurazione contiene un'opzione rimossa nella nuova versione. default_authentication_plugin è il caso più comune, perché molte guide precedenti 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.

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

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

Prima dell'upgrade, aggiorna tutti gli account che mostrano mysql_native_password, quindi modifica 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 in [mysqld]. Considerala una soluzione temporanea con una data di dismissione, perché il plugin verrà rimosso completamente.

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

24.04 include PHP 8.3, mentre 26.04 include PHP 8.5. I pacchetti vengono installati in percorsi specifici per versione e nessun componente modifica automaticamente 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. 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)

Modificate il percorso 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 di non riuscire a caricare libphp8.3.so perché il file non esiste. Il modulo abilitato è un link simbolico a un pacchetto che non è più installato.

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

Se avete installato il sistema seguendo uno stack LAMP su Ubuntu 24.04, conviene verificare entrambi i percorsi, perché la procedura lascia un nome di modulo e un socket specifici per versione.

Anche la configurazione di ottimizzazione di php.ini non viene trasferita. memory_limit, upload_max_filesize e qualsiasi altra impostazione definita si trovano in /etc/php/8.3/, mentre il nuovo albero parte dai valori predefiniti. Confrontate i due file e trasferite manualmente i valori necessari. Copiare l'intero file precedente sopra quello nuovo trasferisce i valori predefiniti di 8.3 in un'installazione 8.5. Eseguite quindi php -m e confrontate i risultati: un'estensione installata come php8.3-redis richiede il pacchetto php8.5-; inoltre, se proveniva da una PPA, l'aggiornamento ha disabilitato quella sorgente e l'estensione non è semplicemente più disponibile.

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

SSH: l'errore che chiude la sessione in uso

Il prompt sshd_config è il punto in cui ci si ritrova senza accesso al server. Rispondendo Y viene installato il file del maintainer, che elimina PermitRootLogin, PasswordAuthentication, AllowUsers, Port e ogni altra riga aggiunta. Se il firewall consente soltanto una porta personalizzata e la configurazione del pacchetto è in ascolto sulla 22, la connessione successiva viene rifiutata e la sessione attualmente aperta è 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 OpenSSH mantiene il primo valore letto per ogni impostazione. Di conseguenza, un file drop-in incluso all'inizio ha la precedenza su tutto ciò che segue. Spostate 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 vostro, quel prompt non è più rilevante: entrambe le risposte mantengono le vostre impostazioni, 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 il comando restituisce enabled, la porta in ascolto è gestita da systemd e la riga Port in sshd_config viene ignorata. Ubuntu usa l'attivazione tramite socket per sshd dalla versione 22.10, ed è questo il motivo per cui una modifica a Port 2222 sembra non avere effetto. Impostate la porta direttamente sull'unità socket con 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 attualmente aperta:

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 ed eseguite di nuovo l'accesso. Una shell funzionante nel secondo terminale è l'unica verifica valida. Lasciate aperta la prima sessione finché non avete completato il test. Mettere in sicurezza SSH su un VPS descrive le impostazioni che conviene mantenere nel file drop-in.

Se è già troppo tardi, la console web del provider consente di accedere senza usare SSH. Eseguite l'accesso dalla console, correggete la configurazione, eseguite sudo sshd -t e riavviate il servizio. Proprio per questo la console va verificata 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 successiva release long term support solo dopo la disponibilità della prima point release. Ubuntu 26.04 LTS è stata rilasciata il 23 aprile 2026 e 26.04.1 è prevista per il 27 agosto 2026. Fino a quella data, un server 24.04 non rileva alcuna nuova release. Lascia questa impostazione invariata 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, ma il sistema in esecuzione continua a utilizzare quelli precedenti fino al riavvio. do-release-upgrade chiede di riavviare il sistema al termine dell'operazione. Un computer lasciato in esecuzione fino a "più tardi" utilizza una combinazione di componenti appartenenti a due release. Dopo il riavvio, controlla uname -r per verificare il nuovo kernel e systemctl --failed per individuare i servizi che non sono stati riavviati correttamente.

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 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 applica un costo per macchina oppure quando disponi di uno snapshot e di un accesso alla console già verificato. La procedura in-place è consolidata, ma per l'ora necessaria all'operazione non consente un ritorno immediato alla situazione precedente.

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

In una normale shell di login, il processo riceve SIGHUP e termina a metà dell'operazione, lasciando dpkg configurato solo parzialmente. Avvialo all'interno di tmux o screen: il processo continuerà a essere eseguito, quindi potrai riconnetterti ed eseguire tmux attach -t upgrade per riprendere l'aggiornamento. Il programma di aggiornamento avvia inoltre un demone SSH aggiuntivo sulla porta 1022 come secondo metodo di accesso. Tuttavia, non apre la porta nel firewall. Devi quindi autorizzare prima la porta 1022 e chiuderla al termine.

Il mio sito PHP restituisce 502 dopo l'aggiornamento. Che 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ù, ma 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 e quindi ricarica nginx. Su Apache con mod_php, la correzione equivalente consiste nell'eseguire sudo a2dismod php8.3, seguito da sudo a2enmod php8.5 e da un riavvio.