do-release-upgrade: nessuna nuova release trovata

Perché do-release-upgrade indica che non è stata trovata alcuna nuova release

do-release-upgrade che termina con No new release found. non indica quasi mai un problema dello strumento. Il percorso richiesto è chiuso in quel momento e lo strumento lo segnala nel modo più sintetico possibile. Le cause sono cinque: l'impostazione Prompt in /etc/update-manager/release-upgrades, il requisito della point release per gli aggiornamenti LTS (long term support), i repository di terze parti, i pacchetti bloccati o configurati solo parzialmente e una release che ha superato il termine del supporto.

Verificale in questo ordine. Per ogni causa esiste un comando che dimostra se si applica al server. Non devi quindi dedurre quale delle cinque condizioni si è verificata.

Cosa segnala effettivamente l'opzione di sola verifica

sudo do-release-upgrade -c
echo $?

-c esegue solo una verifica. Legge i metadati della release di Canonical tramite HTTPS (hypertext transfer protocol secure) e stampa il risultato. Non scarica alcuno strumento di aggiornamento e non riscrive alcun file di configurazione delle sorgenti. Sono importanti due risultati:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Il codice di uscita restituisce lo stesso risultato agli script. È 0 quando è disponibile una release ed è 1 quando non ne è disponibile alcuna. Questo comportamento è inverso rispetto alla convenzione usuale della shell, quindi va interpretato con attenzione prima di basarvi un controllo.

Se il banner di accesso mostra ancora il risultato precedente, il dato è nella cache. Quella riga proviene da /etc/update-motd.d/91-release-upgrade, che stampa un risultato memorizzato invece di interrogare la rete. Aggiornalo con sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd oppure considera direttamente attendibile -c. Il banner ripete soltanto il risultato dell'ultima verifica eseguita.

La verifica deve inoltre raggiungere changelogs.ubuntu.com. Su un server protetto da un firewall in uscita rigido o da un proxy, lo strumento non può eseguire la richiesta e quindi non può rilevare alcuna release.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Una riga HTTP/2 200 indica che il server riesce a visualizzare i metadati. Una riga curl: (28) Connection timed out indica invece che la causa reale sono le regole di uscita. Nessuna modifica ai file di APT (advanced package tool) può cambiare questo risultato.

Se il comando non è presente, si trova in ubuntu-release-upgrader-core. Le immagini cloud minime a volte non includono quel pacchetto.

sudo apt install ubuntu-release-upgrader-core

Leggere /etc/update-manager/release-upgrades prima di modificare qualsiasi impostazione

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Il file contiene la relativa documentazione nei commenti. Sono validi tre valori:

• never: non verificare mai la disponibilità di un upgrade a una nuova release e non consentirlo mai.
• normal: proporre la release supportata immediatamente successiva a quella in esecuzione.
• lts: proporre la prima release LTS successiva a quella in esecuzione.

Prompt=never è il più semplice da diagnosticare, perché lo strumento indica nell'output sia il file sia l'impostazione:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

I provider di hosting e gli strumenti di gestione della configurazione impostano deliberatamente never per impedire che un parco di server passi da una release all'altra senza controllo. Se lo trovate, è stato scelto intenzionalmente. Impostatelo su lts per un server che deve seguire il canale di supporto a lungo termine e ripristinatelo dopo l'operazione se l'automazione si aspetta il valore precedente.

Un dettaglio nei commenti può creare confusione. Quando Prompt=lts è impostato e la release in esecuzione non è una release LTS, l'upgrader interpreta l'impostazione come normal. Su una macchina con 25.10 i due valori si comportano nello stesso modo. Su una macchina con 24.04 no. Questa differenza costituisce l'intera sezione successiva.

Perché un aggiornamento da una versione LTS a un’altra attende la prima point release

Prompt determina quale file di metadati legge l’aggiornamento. Gli indirizzi sono definiti in /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts legge meta-release-lts. Prompt=normal legge meta-release. Entrambi i file descrivono ogni release tramite un piccolo blocco di chiavi, e lo strumento di aggiornamento propone una release solo quando il relativo flag Supported: è impostato su 1. Puoi consultarli direttamente dallo stesso server:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

Verificati il 13 agosto 2026, i due file riportano informazioni diverse per Ubuntu 26.04. Il file LTS indica:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

Il file standard indica:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Quel valore Supported: 0 nel file LTS costituisce il blocco. Un server 24.04 che usa il valore predefinito Prompt=lts legge quel file, non trova alcuna release LTS più recente contrassegnata come disponibile e visualizza No new release found.. Il problema non riguarda il tuo sistema. Canonical non ha ancora aperto il percorso di aggiornamento.

Il flag passa a 1 quando viene pubblicato il primo point release. Ubuntu 26.04.1 è previsto per il 27 agosto 2026, ma le tempistiche di rilascio possono cambiare: controllate i metadati invece di basarvi sul calendario. Un point release non è una nuova versione di Ubuntu, ma la stessa release con tutti gli aggiornamenti pubblicati dal lancio integrati in nuovi supporti di installazione. Per un server in esecuzione conta quindi il requisito che il point release abilita, non il supporto in sé. Il ritardo è intenzionale: chi aggiorna per primo individua i blocchi e questi vengono corretti prima che proceda la popolazione molto più ampia dei server LTS. Se questa data è già trascorsa quando leggete questa guida, il contenuto di 26.04.1 al momento del rilascio e il suo significato per un server 24.04 prosegue l'analisi.

Restano due opzioni corrette. Attendere la point release, che è la scelta giusta per qualsiasi server che si preferisce non monitorare. In alternativa, impostare Prompt=normal, che indirizza lo stesso strumento verso meta-release, dove 26.04 è già contrassegnato come supportato. Questa seconda procedura aggiorna alla versione rilasciata 26.04, non a una build di sviluppo, quindi è una scelta sostenibile su una macchina che può essere ripristinata da uno snapshot. Al termine, ripristinare il valore lts. La procedura completa, descritta passo per passo, è disponibile in la guida completa all'aggiornamento del server da 24.04 a 26.04. Un server che esegue ancora 22.04 deve effettuare un passaggio aggiuntivo, perché Prompt=lts propone sempre e solo la release LTS successiva; per questo il percorso da 22.04 a 26.04 passa prima da 24.04.

Repository di terze parti e PPA che bloccano l'aggiornamento

Il programma di aggiornamento riscrive le sorgenti APT in modo che puntino alla nuova release. Può farlo solo per un repository che pubblica pacchetti per la nuova release; tutti gli altri vengono quindi commentati. I motivi vengono stampati su una riga per ogni voce e sono specifici: was disabled (unknown mirror), was disabled (unknown dist) e was disabled (no Release file).

Un PPA (archivio personale di pacchetti) compilato per noble non dispone sul server di una directory per resolute. Il programma di aggiornamento non può quindi scaricare un file Release per la nuova serie e disabilita la voce. Di solito si tratta di un avviso che si può accettare. Diventa un blocco quando un repository di terze parti fornisce un pacchetto incluso anche nella nuova release, perché il calcolo dell'aggiornamento si trova con due candidati e non può soddisfare entrambe le richieste.

Prendi questa decisione prima di iniziare, invece di lasciare che sia lo strumento a farlo durante un'esecuzione automatica prolungata.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy applicato a un nome di pacchetto mostra da quale repository proviene ogni versione installata. In questo modo puoi verificare esattamente quali pacchetti dipendono dalla sorgente che stai per disabilitare. La rimozione della sorgente non esegue alcun downgrade, quindi un pacchetto installato da un PPA rimane alla versione del PPA e può essere più recente di quella disponibile nella nuova release. Se questo è rilevante, rimuovi anche il pacchetto e reinstallalo dall'archivio dopo l'aggiornamento. Se prevedi di riattivare un repository, come quello di Tailscale, devi aggiornare il suo codename alla nuova release prima di poter installare nuovamente il pacchetto. È questa la causa di gran parte degli errori di installazione di Tailscale su Ubuntu.

Esiste un flag per scegliere l'opzione opposta. La pagina del manuale descrive --allow-third-party come "Prova l'aggiornamento con mirror e repository di terze parti abilitati invece di commentarli." Usalo solo dopo aver verificato che il repository pubblichi già pacchetti per la release di destinazione. In caso contrario, chiedi ad APT di risolvere un grafo delle dipendenze rispetto a una serie per la quale quel repository non ha mai compilato pacchetti.

Su Ubuntu 24.04 e versioni successive, la maggior parte delle sorgenti si trova in /etc/apt/sources.list.d/ubuntu.sources nel formato deb822. Lo stesso repository scritto sia nel formato precedente sia in quello nuovo genera un errore distinto, con un messaggio specifico, descritto in l'errore relativo alla voce di sorgente duplicata nel formato deb822.

I pacchetti bloccati e lasciati a metà interrompono il calcolo

Un aggiornamento di release deve spostare quasi tutti i pacchetti presenti nel sistema. Se un pacchetto non può essere aggiornato, il calcolo fallisce e l'upgrader preferisce arrestarsi subito invece di lasciare il sistema in uno stato intermedio. Due comandi permettono di individuare la causa.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold stampa i pacchetti bloccati, uno per riga, e non stampa nulla su un sistema integro. Un blocco è un'istruzione manuale che impedisce di modificare quel pacchetto. Qualcuno potrebbe aver bloccato una versione del kernel o del database e poi averlo dimenticato. Rimuovi i blocchi non più necessari con sudo apt-mark unhold seguito dal nome del pacchetto.

dpkg --audit elenca i pacchetti spacchettati ma mai configurati. Questo stato deriva da un'installazione interrotta, spesso a causa della chiusura della sessione. L'upgrader prova a correggere il problema e stampa dpkg interrupted, calling dpkg --configure -a, ma eseguire prima la correzione manualmente consente di leggere l'errore invece di lasciarlo scorrere sullo schermo. Se lo strumento non riesce a correggere un pacchetto, visualizza il messaggio Package in inconsistent state. In questo caso devi intervenire prima di riprovare.

Porta la release in esecuzione allo stato completamente aggiornato prima di eseguire l'upgrade.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

L'opzione per gli aggiornamenti distribuiti gradualmente è più importante di quanto sembri. Ubuntu distribuisce alcuni aggiornamenti a una percentuale di macchine alla volta, quindi un semplice apt upgrade può lasciare correttamente alcuni pacchetti non aggiornati e il server risulta meno aggiornato di quanto pensi. Questa opzione installa tutti gli aggiornamenti disponibili. Riavvia il sistema dopo l'installazione se tra gli aggiornamenti era incluso un kernel, così esegui l'upgrade usando il kernel effettivamente in esecuzione. Un server che si mantiene già aggiornato tramite aggiornamenti di sicurezza automatici ha meno attività da svolgere in questa fase, anche se, per progettazione, tale meccanismo non attraversa mai il confine tra release.

Quando la release supera la fine del supporto standard

Una release intermedia di Ubuntu è supportata per nove mesi. Al termine del supporto, il relativo flag Supported: passa a 0 e il percorso normale non offre alcun aggiornamento da quella release. Verificato il 13 agosto 2026, meta-release riporta quanto segue per la versione 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

Anche l'archivio viene spostato nello stesso momento. I pacchetti di una release non più supportata vengono rimossi da archive.ubuntu.com e conservati in old-releases.ubuntu.com. Di conseguenza apt update inizia a restituire 404 Not Found, il sistema non può più essere aggiornato e, poiché l'aggiornamento richiede un sistema aggiornato, la procedura non prosegue. Correggi prima le sorgenti.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Imposta sia archive.ubuntu.com sia security.ubuntu.com su old-releases.ubuntu.com e non modificare il codename. Cambia soltanto il nome dell'host.

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

Esegui invece lo stesso comando su /etc/apt/sources.list se il server conserva ancora le sorgenti in quel file unico. L'opzione -i.bak crea un backup accanto all'originale, così puoi ripristinarlo se la modifica è stata applicata al file sbagliato. Un apt update pulito indica che l'archivio è nuovamente raggiungibile e do-release-upgrade potrà comunicare con l'archivio.

Valuta con realismo il risultato ottenuto. Ubuntu supporta una sola release alla volta, quindi un server che si trova due o tre release non più supportate indietro deve eseguire ogni passaggio in sequenza. Ogni passaggio può inoltre non riuscire a causa di un repository di terze parti o di un pacchetto mantenuto separatamente. Su un VPS spesso è più rapido creare un nuovo server con la LTS corrente, trasferirvi il servizio e mantenere quello vecchio finché non hai verificato che tutto funzioni. In questo modo ottieni anche un rollback, che un aggiornamento in place non offre mai. Se devi scegliere quale percorso seguire in seguito, vale la pena leggere la differenza tra release LTS e intermedie su un server prima di decidere.

Che cosa fa realmente il flag per la release di sviluppo

-d o --devel-release fa leggere all'aggiornamento meta-release-development invece del file selezionato da Prompt. La pagina man lo descrive così: "Se si usa la release supportata più recente, esegue l'aggiornamento alla release di sviluppo."

Verificato il 13 agosto 2026, l'ultima voce in quel file non è 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Quindi -d non porta un server 24.04 alla 26.04 rilasciata. Punta alla 26.10, una release ancora in fase di sviluppo. Il vecchio consiglio di "aggiungere semplicemente -d" si riferiva al periodo precedente al rilascio di una LTS. Ripeterlo ora indirizza il server verso una release diversa da quella prevista. Con Prompt=lts ancora presente, il flag si interrompe e mostra un messaggio specifico:

There is no development version of an LTS available.

La documentazione Ubuntu per i server è chiara sul flag: "l'uso della release di sviluppo (o del flag -d) non è consigliato negli ambienti di produzione". Una release di sviluppo cambia ogni giorno e non offre alcuna garanzia di supporto per la sicurezza. Un pacchetto che funziona al mattino può quindi interrompere un servizio nel pomeriggio. Usatela su una macchina virtuale temporanea creata per testare la vostra configurazione. Non usatela su un server da cui dipende qualcuno. Se volete una 26.04 rilasciata prima dell'apertura del blocco LTS, Prompt=normal è la procedura corretta.

Esegui l'upgrade in modo che la disconnessione SSH non possa interromperlo

Un aggiornamento di release sostituisce gran parte del sistema, inclusi openssh-server e systemd. Se la sessione SSH (secure shell) si interrompe mentre dpkg è in esecuzione, il processo viene terminato con alcuni pacchetti estratti ma non configurati. È esattamente la condizione che impedisce il tentativo successivo. Se è già successo, il ripristino di un aggiornamento interrotto a metà è un’attività separata e deve essere completata prima di un secondo tentativo. Avvia sempre l’aggiornamento all’interno di un multiplexer di terminale.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Se la connessione si interrompe, accedi nuovamente ed esegui tmux attach -t upgrade. L'upgrade continua a essere eseguito perché è un processo figlio del server tmux, non della sessione SSH. screen -S upgrade e screen -r upgrade svolgono la stessa funzione se preferisci screen.

L'upgrader dispone di una protezione aggiuntiva per chi non usa un multiplexer. Quando rileva di essere in esecuzione tramite SSH, propone di avviare un secondo sshd sulla porta 1022, in modo che una disconnessione della sessione principale lasci comunque una via di accesso. Per decidere, analizza i propri processi padre alla ricerca di un processo chiamato sshd. All'interno di tmux o screen, l'analisi trova invece il server del multiplexer. Di conseguenza, la proposta non viene visualizzata e il file PID /var/run/release-upgrader-sshd.pid viene scritto solo quando il demone aggiuntivo viene effettivamente avviato. Se non visualizzi la richiesta, non c'è alcun problema. Hai già una protezione migliore.

Se accetti la proposta, la porta non viene aperta automaticamente. Lo strumento lo specifica chiaramente, perché l'apertura di una porta è una decisione di sicurezza che non può prendere al posto tuo. Aprila per la durata dell'upgrade, quindi chiudila nuovamente.

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

La maggior parte dei provider VPS gestisce un secondo firewall nel pannello di controllo, esterno al sistema operativo. Anche la porta 1022 deve essere aperta in quel firewall. In caso contrario, il listener di fallback è in esecuzione ma non raggiungibile: è la situazione peggiore.

Prima di digitare il comando, prepara questi quattro elementi:

• Crea uno snapshot o un backup completo. Un upgrade di release in-place non può essere annullato e questa è l'unica copia di sicurezza disponibile.
• Verifica di poter aprire la console del provider prima di averne bisogno. Se il server non torna operativo dopo il riavvio, SSH è esattamente ciò a cui non potrai accedere. Un kernel che non esegue il boot è un problema distinto, con procedure di ripristino proprie, descritte in un VPS che non esegue il boot dopo un aggiornamento del kernel.
• Controlla lo spazio libero con df -h / /boot. L'upgrade scarica un set completo di pacchetti e una partizione /boot che contiene diversi kernel precedenti è un punto comune in cui l'operazione può bloccarsi.
• Leggi le note di rilascio dei servizi che esegui. Con la release arriva anche un salto di versione principale di PostgreSQL o PHP, che tu lo abbia pianificato o meno.

FAQ

Perché do-release-upgrade segnala che non è stata trovata una nuova release su Ubuntu 24.04?

Il valore predefinito di Prompt=lts in /etc/update-manager/release-upgrades fa leggere allo strumento https://changelogs.ubuntu.com/meta-release-lts, e Ubuntu 26.04 mantiene Supported: 0 in quel file fino alla prima point release. L'upgrader non trova alcuna release LTS più recente contrassegnata come disponibile e si arresta. Controlla direttamente il file con curl -s https://changelogs.ubuntu.com/meta-release-lts e leggi l'ultimo blocco. Al controllo del 13 agosto 2026, il flag era ancora 0, mentre Ubuntu 26.04.1 era pianificata per il 27 agosto 2026.

È sicuro impostare Prompt=normal invece di attendere la point release?

L'aggiornamento porta alla versione rilasciata 26.04, non a una build di sviluppo, perché Prompt=normal legge meta-release, dove 26.04 riporta già Supported: 1. Il rischio riguarda la tempistica. L'aggiornamento viene eseguito prima che siano stati corretti i problemi rilevati dai primi utenti. Eseguilo su un server che puoi ripristinare da uno snapshot e al quale puoi accedere tramite la console del provider se il riavvio non va a buon fine. In seguito, reimposta il valore su lts.

Il flag -d aggiorna il sistema a 26.04?

No. -d legge meta-release-development, la cui voce più recente il 13 agosto 2026 era Ubuntu 26.10, una release ancora in sviluppo. Su una macchina LTS con Prompt=lts, il flag stampa There is no development version of an LTS available. e si arresta. La documentazione ufficiale di Ubuntu per i server sconsiglia la release di sviluppo negli ambienti di produzione; usa quindi Prompt=normal se vuoi installare in anticipo una versione 26.04 rilasciata.

apt update restituisce errori 404 su una release obsoleta. Come posso aggiornarla?

La release ha raggiunto la fine del ciclo di vita, quindi i relativi pacchetti sono stati spostati da archive.ubuntu.com a old-releases.ubuntu.com. Modifica solo i nomi host in /etc/apt/sources.list.d/ubuntu.sources oppure, nei layout meno recenti, in /etc/apt/sources.list, e mantieni invariato il codename. Esegui quindi sudo apt update e sudo apt full-upgrade. Quando il sistema è di nuovo aggiornato, do-release-upgrade può portarlo alla release successiva, una release alla volta.

Devo rimuovere i miei PPA prima di eseguire do-release-upgrade?

Non è necessario, perché l'upgrader commenta qualsiasi sorgente che non pubblichi pacchetti per la nuova release e stampa una riga come was disabled (no Release file) per ciascuna di esse. È comunque preferibile farlo manualmente prima dell'aggiornamento, perché puoi scegliere l'ordine e verificare il risultato. Esegui apt policy sui pacchetti interessati per individuare quelli provenienti da ciascun PPA, quindi reinstallali dall'archivio se la versione del PPA è più recente di quella disponibile nella nuova release.