do-release-upgrade: nessuna nuova release trovata

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

do-release-upgrade che termina con No new release found. indica quasi sempre che lo strumento funziona correttamente. Il percorso richiesto è chiuso in quel momento e lo strumento lo segnala nel modo più breve possibile. Le cause sono cinque: l'impostazione Prompt in /etc/update-manager/release-upgrades, il vincolo 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.

Verifica le cause in quest'ordine. Per ciascuna esiste un comando che dimostra se si applica al tuo server, quindi non devi mai indovinare quale delle cinque stai analizzando.

Cosa segnala realmente l'opzione di sola verifica

sudo do-release-upgrade -c
echo $?

-c esegue soltanto la verifica. Legge i metadati delle release di Canonical tramite HTTPS (hypertext transfer protocol secure) e stampa il risultato. Non scarica alcuno strumento di aggiornamento e non riscrive alcun file delle sorgenti. I due risultati rilevanti sono:

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. Vale 0 quando è disponibile una release e 1 quando non ne è disponibile nessuna. Questo comportamento è l'opposto della convenzione abituale della shell, quindi va interpretato con attenzione prima di basarci un controllo.

Se il banner di accesso mostra ancora il vecchio risultato, il dato è memorizzato nella cache. Quella riga proviene da /etc/update-motd.d/91-release-upgrade, che stampa un risultato salvato 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'ultimo controllo eseguito.

Il controllo deve inoltre raggiungere changelogs.ubuntu.com. Su un server protetto da un firewall in uscita restrittivo o da un proxy, lo strumento non può eseguire la richiesta e quindi non può rilevare nulla.

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

Una riga HTTP/2 200 indica che il server riesce a leggere i metadati. Un messaggio curl: (28) Connection timed out indica invece che la causa reale sono le regole del traffico in uscita. Nessuna modifica ai file di APT (advanced package tool) cambierà il risultato.

Se il comando non è presente, si trova in ubuntu-release-upgrader-core. Le immagini cloud minimali 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 controlla mai la disponibilità di una nuova release e non consente mai l'aggiornamento a una nuova release.
• normal: propone la release supportata immediatamente successiva a quella in esecuzione.
• lts: propone la prima release LTS successiva a quella in esecuzione.

Prompt=never è il caso 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 insieme di server passi involontariamente da una release all'altra. Se lo trovi, è stato scelto intenzionalmente. Impostalo su lts per un server che vuoi mantenere nel canale di supporto a lungo termine, quindi ripristinalo al termine se l'automazione si aspetta il valore precedente.

Un dettaglio nei commenti causa spesso errori. Quando Prompt=lts è impostato e la release in esecuzione non è una release LTS, lo strumento di aggiornamento tratta l'impostazione come normal. Su una macchina 25.10 i due valori si comportano allo stesso modo. Su una macchina 24.04 no, e 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'upgrader. 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. L'upgrader propone una release solo quando il relativo flag Supported: è impostato su 1. Puoi leggere direttamente i file 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 non concordano su Ubuntu 26.04. Il file LTS riporta:

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

Il file normale riporta:

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

Quel Supported: 0 nel file LTS è il requisito che abilita l'aggiornamento. Un server 24.04 che usa il valore predefinito Prompt=lts legge quel file, non trova una release LTS più recente contrassegnata come disponibile e visualizza No new release found. Il problema non dipende dal tuo sistema. Canonical non ha ancora aperto il percorso di aggiornamento.

Il flag passa a 1 quando viene rilasciata la prima point release. Ubuntu 26.04.1 è previsto per il 27 agosto 2026, ma le tempistiche di rilascio possono cambiare. Controlla quindi i metadati invece di affidarti al calendario. Il ritardo è intenzionale: chi aggiorna per primo individua i problemi bloccanti, che vengono risolti prima che segua la popolazione molto più ampia dei server LTS.

Restano due opzioni corrette. Puoi attendere la point release. È la scelta giusta per qualsiasi server che preferisci non dover monitorare durante l'aggiornamento. In alternativa, puoi impostare Prompt=normal, che indirizza lo stesso strumento verso meta-release, dove 26.04 è già contrassegnata come supportata. Il secondo percorso aggiorna alla versione rilasciata 26.04, non a una build di sviluppo. È quindi una scelta ragionevole su una macchina che puoi ripristinare da uno snapshot. Al termine, reimposta il valore su lts. La procedura completa, descritta passo per passo, è disponibile in la guida completa all'aggiornamento del server da 24.04 a 26.04.

Repository e PPA di terze parti che bloccano l'aggiornamento

Il programma di aggiornamento riscrive le sorgenti APT per puntare alla nuova release. Può farlo solo per un repository che pubblica pacchetti per la nuova release; tutte le altre sorgenti vengono quindi commentate. I motivi vengono stampati uno per riga e sono specifici: was disabled (unknown mirror), was disabled (unknown dist) e was disabled (no Release file).

Un PPA (personal package archive) creato per noble non dispone di una directory per resolute sul server. 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 versioni.

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

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

apt policy su un nome di pacchetto mostra da quale repository proviene ogni versione installata. In questo modo puoi vedere esattamente quali pacchetti dipendono dalla sorgente che stai per disabilitare. La rimozione della sorgente non esegue il downgrade di alcun pacchetto. Un pacchetto installato da un PPA mantiene quindi la versione del PPA e può essere più recente di quella inclusa 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 di nuovo il pacchetto. È questa l'origine di la maggior parte degli errori di installazione di Tailscale su Ubuntu.

Esiste un flag per la scelta 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 creato 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 produce un errore distinto, con un messaggio specifico. Il caso è descritto in errore relativo alla voce di sorgente duplicata nel formato deb822.

Pacchetti mantenuti e configurati solo parzialmente bloccano il calcolo

Un aggiornamento di versione deve sostituire quasi tutti i pacchetti presenti nel sistema. Se un pacchetto non può essere aggiornato, il calcolo fallisce e il programma di aggiornamento preferisce arrestarsi subito invece di lasciare il sistema in uno stato intermedio. Due comandi consentono di individuare la causa.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold stampa i pacchetti mantenuti, uno per riga, e non stampa nulla su un sistema integro. Un blocco è un'istruzione manuale che impedisce qualsiasi modifica a 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 che sono stati estratti ma non configurati. Questo stato deriva da un'installazione interrotta, nella maggior parte dei casi a causa della perdita della sessione. Il programma di aggiornamento 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, mostra 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'aggiornamento.

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. Di conseguenza, 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 poi il sistema se tra questi era presente un kernel, così eseguirai l'aggiornamento usando il kernel effettivamente in esecuzione. Un sistema che mantiene già i pacchetti aggiornati tramite aggiornamenti di sicurezza automatici richiede meno interventi in questa fase, anche se questo meccanismo, per progettazione, non supera mai i confini tra release.

Quando la release supera la fine del supporto standard

Una release interim 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 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'upgrader richiede un sistema aggiornato, la procedura non prosegue. Prima correggete le sorgenti.

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

Impostate sia archive.ubuntu.com sia security.ubuntu.com su old-releases.ubuntu.com e non modificate 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

Eseguite 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ì potete ripristinarlo se la modifica è stata applicata al file sbagliato. Un apt update completato senza errori significa che l'archivio è nuovamente raggiungibile e do-release-upgrade potrà comunicare con esso.

Valutate realisticamente fin dove può portarvi questa procedura. Ubuntu supporta un solo passaggio di release alla volta. Un server che è indietro di due o tre release non più supportate deve quindi eseguire ogni passaggio in sequenza. Ogni passaggio può fallire a causa di un repository di terze parti o di un pacchetto bloccato specifico. Su un VPS, spesso è più rapido creare un nuovo server con la LTS corrente, trasferirvi il servizio e mantenere quello vecchio finché non avete verificato che tutto funzioni. In questo modo ottenete anche un rollback, che un aggiornamento in place non offre mai. Se dovete scegliere quale ramo utilizzare in seguito, vale la pena leggere la differenza tra release LTS e interim su un server prima di decidere.

Cosa fa realmente il flag della release di sviluppo

-d o --devel-release fa leggere all'upgrader meta-release-development invece del file selezionato da Prompt. La pagina del manuale lo descrive così: "Se si utilizza l'ultima release supportata, eseguire l'upgrade 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 consiglio precedente di "aggiungere semplicemente -d" era stato scritto per il periodo precedente al rilascio di una LTS. Ripeterlo ora indirizza il server verso una release diversa da quella prevista. Se Prompt=lts è ancora presente, il flag si interrompe mostrando un messaggio specifico:

There is no development version of an LTS available.

La documentazione Ubuntu per i server è chiara su questo flag: "l'utilizzo 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. Di conseguenza, un pacchetto che funziona al mattino può interrompere un servizio nel pomeriggio. Usala in una macchina virtuale temporanea creata per testare la tua configurazione. Non usarla su un server da cui dipendono altri utenti o servizi. Se vuoi installare una 26.04 rilasciata prima dell'apertura del blocco LTS, Prompt=normal è il percorso corretto.

Esegui l'upgrade in modo che una sessione SSH interrotta non possa bloccarlo

Un upgrade 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 pacchetti estratti ma non configurati. È esattamente lo stato che impedisce il tentativo successivo. Avvia sempre l'upgrade 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 di nuovo ed esegui tmux attach -t upgrade. L'upgrade ha continuato 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 eseguito tramite SSH, propone di avviare un secondo sshd sulla porta 1022, così una sessione principale interrotta lascia comunque un modo per accedere al server. Lo determina risalendo ai propri processi padre e cercandone uno chiamato sshd. All'interno di tmux o screen, questa ricerca trova invece il server del multiplexer. L'offerta quindi non viene visualizzata e il file PID /var/run/release-upgrader-sshd.pid viene scritto solo quando il demone aggiuntivo viene effettivamente avviato. Se il prompt non viene visualizzato, non c'è alcun problema. Hai già una protezione migliore.

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

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

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

Prima di digitare il comando, assicurati di avere predisposto 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 si avvia è un problema separato, con procedure di ripristino proprie, descritte in un VPS che non si avvia 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. Un salto di versione principale di PostgreSQL o PHP arriva insieme alla release, indipendentemente dal fatto che tu lo abbia pianificato.

FAQ

Perché do-release-upgrade indica che non è stata trovata nessuna 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 nessuna release LTS più recente contrassegnata come disponibile e quindi si arresta. Controlla direttamente il file con curl -s https://changelogs.ubuntu.com/meta-release-lts e leggi l'ultimo blocco. Al 13 agosto 2026 il flag era ancora 0, mentre Ubuntu 26.04.1 era prevista per il 27 agosto 2026.

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

L'operazione esegue l'upgrade alla 26.04 rilasciata, non a una build di sviluppo, perché Prompt=normal legge meta-release, dove la 26.04 riporta già Supported: 1. Il rischio riguarda la tempistica. Esegui l'upgrade prima che siano stati corretti i problemi individuati dai primi utenti. Procedi su un server che puoi ripristinare da uno snapshot e sul quale puoi raggiungere la console del provider se il riavvio non va a buon fine. Al termine, reimposta il valore su lts.

Il flag -d esegue l'upgrade alla 26.04?

No. -d legge meta-release-development, la cui voce più recente al 13 agosto 2026 era Ubuntu 26.10, una release ancora in fase di 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 indica che la release di sviluppo non è consigliata in produzione. Usa quindi Prompt=normal quando vuoi installare in anticipo una 26.04 rilasciata.

apt update restituisce errori 404 su una release obsoleta. Come posso eseguire l'upgrade?

La release ha raggiunto la fine del ciclo di vita e i relativi pacchetti sono stati spostati da archive.ubuntu.com a old-releases.ubuntu.com. Modifica soltanto i nomi host in /etc/apt/sources.list.d/ubuntu.sources oppure, nei layout più vecchi, in /etc/apt/sources.list, mantenendo invariato il codename. Esegui quindi sudo apt update e sudo apt full-upgrade. Quando il sistema è nuovamente 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 è obbligatorio, perché l'upgrader commenta qualsiasi sorgente che non pubblica pacchetti per la nuova release e stampa una riga come was disabled (no Release file) per ciascuna di esse. È comunque preferibile farlo prima manualmente, perché puoi scegliere l'ordine e verificare il risultato. Esegui apt policy sui pacchetti che ti interessano per individuare quelli provenienti da ciascun PPA, quindi reinstalla quelli dall'archivio se la versione del PPA è più recente di quella disponibile nella nuova release.