do-release-upgrade: nenhuma nova versão encontrada

Por que do-release-upgrade informa que não foi encontrada uma nova versão

do-release-upgrade que termina em No new release found. quase nunca indica uma ferramenta com problemas. O caminho solicitado está fechado naquele momento, e a ferramenta informa isso da forma mais curta possível. Cinco situações podem fechá-lo: a definição Prompt em /etc/update-manager/release-upgrades, o bloqueio da versão de atualização das versões LTS (suporte de longo prazo), repositórios de terceiros, pacotes mantidos ou parcialmente configurados e uma versão cujo suporte já terminou.

Analise-as nessa ordem. Cada uma tem um comando que comprova se se aplica ao seu servidor. Assim, não é necessário adivinhar qual das cinco situações está a ocorrer.

O que o sinalizador check-only realmente informa

sudo do-release-upgrade -c
echo $?

-c executa apenas a verificação. Lê os metadados de versões da Canonical por HTTPS (hypertext transfer protocol secure) e apresenta o resultado. Não descarrega nenhuma ferramenta de atualização nem reescreve ficheiros de origem. Há dois resultados importantes:

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.

O código de saída transmite a mesma resposta para scripts. É 0 quando existe uma versão disponível e 1 quando não existe nenhuma. Isto é o inverso da convenção habitual da shell, por isso leia o valor com atenção antes de criar uma verificação baseada nele.

Se a mensagem de login ainda mostrar o resultado antigo, este está em cache. Essa linha vem de /etc/update-motd.d/91-release-upgrade, que apresenta um resultado guardado em vez de consultar a rede. Atualize-o com sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd ou confie diretamente em -c. A mensagem repete apenas o resultado da última verificação executada.

A verificação também precisa de alcançar changelogs.ubuntu.com. Num servidor protegido por uma firewall de saída restritiva ou por um proxy que a ferramenta não consegue consultar, não é possível obter informações e nenhuma versão será encontrada.

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

Uma linha HTTP/2 200 indica que o servidor consegue consultar os metadados. Uma linha curl: (28) Connection timed out indica que as regras de saída são a causa real. Alterar ficheiros do APT (advanced package tool) não mudará o resultado.

Se o comando não existir, está disponível em ubuntu-release-upgrader-core. Algumas imagens cloud mínimas não incluem esse pacote.

sudo apt install ubuntu-release-upgrader-core

Leia /etc/update-manager/release-upgrades antes de alterar qualquer coisa

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

O ficheiro inclui a sua própria documentação nos comentários. São válidos três valores:

• never: nunca procurar nem permitir uma atualização para uma nova release.
• normal: oferecer a release suportada imediatamente seguinte à que está em execução.
• lts: oferecer a primeira release LTS posterior à que está em execução.

Prompt=never é o mais fácil dos três de diagnosticar, porque a ferramenta identifica no resultado tanto o ficheiro como a definição:

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

Os fornecedores de alojamento e as ferramentas de gestão de configuração definem never deliberadamente para impedir que uma frota fique distribuída por várias releases. Se o encontrar nesse estado, alguém o escolheu. Altere-o para lts num servidor que queira manter no canal de suporte de longo prazo e reponha-o depois se a sua automação esperar o valor anterior.

Há um detalhe nesses comentários que causa problemas. Quando Prompt=lts está definido e a release em execução não é uma release LTS, o atualizador interpreta essa definição como normal. Numa máquina com 25.10, os dois valores comportam-se da mesma forma. Numa máquina com 24.04, não, e essa diferença constitui toda a secção seguinte.

Por que uma atualização de LTS para LTS aguarda o primeiro point release

Prompt determina o ficheiro de metadados que o atualizador lê. Os endereços estão em /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 lê meta-release-lts. Prompt=normal lê meta-release. Ambos os ficheiros descrevem cada release num pequeno bloco de chaves, e o atualizador só disponibiliza uma release quando o respetivo sinalizador Supported: é 1. Consulte os ficheiros diretamente, no mesmo servidor:

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

Verificado em 13 August 2026, os dois ficheiros têm informações diferentes sobre Ubuntu 26.04. O ficheiro LTS indica:

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

O ficheiro normal indica:

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

Esse Supported: 0 no ficheiro LTS é o bloqueio. Um servidor 24.04 que use o Prompt=lts predefinido lê esse ficheiro, não encontra uma release LTS mais recente marcada como disponível e apresenta No new release found.. Não há nada de errado no seu sistema. A Canonical ainda não abriu o caminho de atualização.

O sinalizador muda para 1 quando o primeiro point release é lançado. O lançamento de Ubuntu 26.04.1 está agendado para 27 August 2026, mas os calendários de lançamento podem mudar. Por isso, consulte os metadados em vez de confiar numa data. Um point release não é uma versão nova de Ubuntu. É apenas a mesma release com todas as atualizações desde o lançamento integradas em novos meios de instalação. Para um servidor em execução, o que importa é o bloqueio que o point release remove, não o meio de instalação. O atraso é intencional: os utilizadores que atualizam primeiro encontram os problemas, que são corrigidos antes de a população muito maior de servidores LTS fazer a atualização.

Isto deixa duas opções legítimas. Aguarde pelo point release. Essa é a escolha certa para qualquer servidor que prefira não ter de monitorizar durante a atualização. Ou defina Prompt=normal, que direciona a mesma ferramenta para meta-release, onde 26.04 já está marcada como suportada. Este segundo caminho atualiza o sistema para a versão lançada 26.04, não para uma versão de desenvolvimento. Por isso, é uma opção defensável num sistema que possa restaurar a partir de um snapshot. Reponha o valor lts quando terminar. O procedimento completo, passo a passo, está em o guia completo para atualizar um servidor de 24.04 para 26.04.

Repositórios de terceiros e PPAs que bloqueiam a atualização

O atualizador reescreve as fontes do APT para apontarem para a nova versão. Só consegue fazer isso para um repositório que publique pacotes para a nova versão, por isso todos os outros são comentados. Os motivos são apresentados uma linha por entrada e são específicos: was disabled (unknown mirror), was disabled (unknown dist) e was disabled (no Release file).

Um PPA (arquivo de pacotes pessoal) criado para noble não tem um diretório para resolute no servidor. Por isso, o atualizador não consegue obter um ficheiro Release para a nova série e desativa a entrada. Normalmente, pode aceitar isto como um aviso. A situação torna-se um bloqueio quando um repositório de terceiros fornece um pacote que a nova versão também inclui, porque o cálculo da atualização passa a ter dois candidatos e não consegue satisfazer ambos.

Tome esta decisão antes de iniciar a atualização, em vez de deixar a ferramenta decidir durante uma execução longa e não supervisionada.

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

apt policy num nome de pacote mostra de que repositório veio cada versão instalada. Assim, pode ver exatamente quais pacotes dependem da fonte que pretende desativar. Remover a fonte não faz downgrade de nada. Por isso, um pacote instalado a partir de um PPA mantém a versão do PPA e pode ser mais recente do que a versão incluída na nova versão. Quando isso for relevante, remova também o pacote e reinstale-o a partir do arquivo depois da atualização. Se pretender voltar a ativar um repositório, como o do Tailscale, terá de atualizar o seu codename para a nova versão antes de o pacote voltar a instalar. É daí que vêm a maioria dos erros de instalação do Tailscale no Ubuntu.

Existe uma flag para escolher a opção oposta. A página do manual descreve --allow-third-party como "Tentar a atualização com mirrors e repositórios de terceiros ativados, em vez de os comentar." Use-a apenas depois de confirmar que o repositório já publica pacotes para a versão de destino. Caso contrário, estará a pedir ao APT para resolver um grafo de dependências com base numa série para a qual esse repositório nunca criou pacotes.

No Ubuntu 24.04 e posteriores, a maioria das fontes está em /etc/apt/sources.list.d/ubuntu.sources, no formato deb822. O mesmo repositório escrito nos formatos antigo e novo constitui um erro separado, com a sua própria mensagem. Esse caso é abordado em o erro de entrada de fonte duplicada no formato deb822.

Pacotes retidos e parcialmente configurados interrompem a resolução de dependências

Uma atualização de versão tem de atualizar quase todos os pacotes do sistema. Se um pacote não puder ser atualizado, a resolução de dependências falha. O atualizador prefere parar logo no início a deixar o sistema num estado intermédio. Dois comandos identificam a causa.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold mostra os pacotes retidos, um por linha, e não mostra nada num sistema sem pacotes retidos. Uma retenção é uma instrução manual para nunca alterar esse pacote. Alguém fixou uma versão do kernel ou da base de dados e depois esqueceu-se dela. Remova a retenção dos pacotes que já não precisa com sudo apt-mark unhold seguido do nome do pacote.

dpkg --audit lista os pacotes que foram desempacotados, mas nunca configurados. Esse estado resulta de uma instalação interrompida, normalmente porque a sessão foi terminada. O atualizador tenta reparar o problema e mostra dpkg interrupted, calling dpkg --configure -a, mas executar primeiro a reparação permite ler o erro em vez de o ver passar no ecrã. Se a ferramenta não conseguir reparar um pacote, mostra a mensagem Package in inconsistent state. Esse pacote precisa de atenção antes de tentar novamente.

Atualize completamente a versão em execução antes de a atualizar para uma versão posterior.

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

A opção de atualizações faseadas é mais importante do que parece. O Ubuntu distribui algumas atualizações por uma percentagem das máquinas de cada vez. Por isso, um apt upgrade simples pode deixar pacotes para trás corretamente, e o servidor fica menos atualizado do que parece. Essa opção instala todas as atualizações. Reinicie depois se alguma delas incluir um kernel, para fazer a atualização a partir do kernel que está efetivamente em execução. Um servidor que já se mantém atualizado através de atualizações de segurança não supervisionadas tem menos trabalho nesta fase, embora esse mecanismo nunca atravesse uma fronteira de versão por definição.

Quando a versão ultrapassa o fim do suporte padrão

Uma versão interim do Ubuntu tem suporte durante nove meses. Quando esse suporte termina, o sinalizador Supported: passa para 0, e o caminho normal não oferece nenhuma atualização a partir dessa versão. Verificado em 13 August 2026, meta-release informa o seguinte sobre a 25.10:

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

O arquivo também é movido nesse momento. Os pacotes de uma versão cujo ciclo de vida terminou são removidos de archive.ubuntu.com e mantidos em old-releases.ubuntu.com. Por isso, apt update começa a devolver 404 Not Found, o sistema deixa de poder ser atualizado e, como o atualizador exige um sistema atualizado, nada prossegue. Corrija primeiro as fontes.

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

Aponte archive.ubuntu.com e security.ubuntu.com para old-releases.ubuntu.com e mantenha o seu codename inalterado. Só muda o nome do 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

Execute o mesmo comando contra /etc/apt/sources.list se o seu servidor ainda mantiver as fontes nesse único ficheiro. A opção -i.bak cria uma cópia de segurança junto do original, para que possa repô-lo se a edição tiver sido aplicada ao ficheiro errado. Um apt update limpo depois disso significa que o arquivo voltou a estar acessível, e do-release-upgrade passará a comunicar consigo.

Seja realista quanto ao alcance desta operação. O Ubuntu suporta uma atualização de versão de cada vez. Por isso, um servidor que esteja duas ou três versões descontinuadas atrás precisa de passar por cada etapa, e cada etapa pode falhar devido ao seu próprio repositório de terceiros ou ao seu próprio pacote retido. Num VPS, é muitas vezes mais rápido criar um servidor novo com a LTS atual, migrar o serviço e manter o servidor antigo até ter a certeza de que tudo funciona. Isso também lhe dá uma opção de rollback, que uma atualização in place nunca oferece. Se estiver a escolher em que ciclo permanecer depois, vale a pena ler a diferença entre versões LTS e interim num servidor antes de decidir.

O que o sinalizador de versão de desenvolvimento realmente faz

-d ou --devel-release faz o atualizador ler meta-release-development em vez do ficheiro selecionado por Prompt. A página de manual descreve-o como "Se estiver a usar a versão mais recente suportada, atualize para a versão de desenvolvimento."

Verificado em 13 de agosto de 2026, o registo mais recente nesse ficheiro não é 26.04:

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

Por isso, -d não fornece 26.04, já lançada, a um servidor 24.04. O objetivo é 26.10, uma versão que ainda está a ser preparada. A recomendação antiga de "adicionar apenas -d" foi escrita para o período anterior ao lançamento de uma versão LTS. Repeti-la agora encaminha o servidor para uma versão que não pretendia usar. Com Prompt=lts ainda ativo, o sinalizador termina com uma mensagem própria:

There is no development version of an LTS available.

A documentação de servidor do Ubuntu é clara sobre este sinalizador: "não é recomendado usar a versão de desenvolvimento (ou o sinalizador -d) em ambientes de produção". Uma versão de desenvolvimento muda diariamente e não oferece garantia de suporte de segurança. Por isso, um pacote que funciona de manhã pode interromper um serviço à tarde. Use-a numa máquina virtual descartável criada para testar a sua própria configuração. Não a use num servidor de que alguém dependa. Quando quiser obter uma versão 26.04 já lançada antes de o bloqueio da LTS ser removido, Prompt=normal é o procedimento correto.

Execute a atualização num terminal que uma sessão SSH interrompida não consiga afetar

Uma atualização de versão substitui a maior parte do sistema, incluindo openssh-server e systemd. Se a sua sessão SSH (secure shell) terminar enquanto o dpkg está a trabalhar, o processo é terminado com pacotes desempacotados e não configurados. Esse é precisamente o estado que impede a tentativa seguinte. Inicie sempre a atualização dentro de um multiplexador de terminal.

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

Se a ligação cair, volte a iniciar sessão e execute tmux attach -t upgrade. A atualização continuou a ser executada porque é filha do servidor tmux, e não da sua sessão SSH. screen -S upgrade e screen -r upgrade fazem o mesmo se preferir usar screen.

O atualizador tem a sua própria proteção para quem não usa um multiplexador. Quando deteta que está a ser executado através de SSH, oferece iniciar um segundo sshd na porta 1022. Assim, uma sessão principal interrompida continua a deixar uma forma de acesso. A deteção é feita percorrendo os próprios processos pai à procura de um processo chamado sshd. Dentro do tmux ou do screen, essa procura encontra o servidor do multiplexador. Por isso, a oferta nunca aparece, e o ficheiro de PID /var/run/release-upgrader-sshd.pid só é criado quando o daemon adicional é realmente iniciado. Não há qualquer problema se não vir o aviso. Já tem uma proteção melhor.

Se aceitar a oferta, a porta não é aberta automaticamente. A ferramenta informa-o claramente, porque abrir uma porta é uma decisão de segurança que não pode tomar em seu nome. Abra-a durante a atualização e feche-a novamente depois.

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

A maioria dos fornecedores de VPS executa uma segunda firewall no painel de controlo, fora do sistema operativo. A porta 1022 também tem de estar aberta nesse painel. Caso contrário, o listener de fallback está em execução, mas inacessível. Esse é o pior dos dois cenários.

Antes de introduzir o comando, confirme estes quatro pontos:

• Crie um snapshot ou faça uma cópia de segurança completa. Uma atualização de versão no próprio sistema não pode ser revertida, e esta é a única cópia que terá.
• Confirme que consegue abrir a consola do fornecedor antes de precisar dela. Se o servidor não voltar depois do reboot, o SSH será precisamente o acesso que não terá. Um kernel que não arranca é um problema separado, com procedimentos próprios de recuperação, descritos em um VPS que não arranca depois de uma atualização do kernel.
• Verifique o espaço livre com df -h / /boot. A atualização descarrega um conjunto completo de pacotes, e uma partição /boot que contenha vários kernels antigos é um local comum para a atualização ficar bloqueada.
• Leia as notas da versão dos serviços que executa. Uma mudança de versão principal do PostgreSQL ou do PHP acompanha a versão do sistema, quer a tenha planeado ou não.

FAQ

Por que do-release-upgrade informa que não encontrou uma nova versão no Ubuntu 24.04?

O Prompt=lts predefinido em /etc/update-manager/release-upgrades faz a ferramenta ler https://changelogs.ubuntu.com/meta-release-lts, e o Ubuntu 26.04 mantém Supported: 0 nesse ficheiro até à sua primeira versão de manutenção. O atualizador não encontra uma versão LTS mais recente marcada como disponível e, por isso, para. Verifique o ficheiro manualmente com curl -s https://changelogs.ubuntu.com/meta-release-lts e leia o último bloco. Em 13 August 2026, o sinalizador ainda era 0, e o Ubuntu 26.04.1 estava agendado para 27 August 2026.

É seguro definir Prompt=normal em vez de esperar pela versão de manutenção?

Isto atualiza o sistema para a versão 26.04 lançada, não para uma versão de desenvolvimento, porque Prompt=normal lê meta-release, onde a versão 26.04 já tem Supported: 1. O risco está no momento da atualização. Está a atualizar antes de os problemas encontrados pelos primeiros utilizadores terem sido corrigidos. Faça isto num servidor que possa restaurar a partir de um snapshot e ao qual possa aceder através da consola do fornecedor se o reboot falhar. Depois, volte a definir o valor como lts.

O sinalizador -d atualiza o sistema para a versão 26.04?

Não. -d lê meta-release-development, cuja entrada mais recente em 13 August 2026 era o Ubuntu 26.10, uma versão ainda em desenvolvimento. Numa máquina LTS com Prompt=lts, o sinalizador apresenta There is no development version of an LTS available. e para. A documentação oficial do Ubuntu para servidores indica que a versão de desenvolvimento não é recomendada para produção. Por isso, use Prompt=normal quando quiser obter antecipadamente uma versão 26.04 lançada.

apt update devolve erros 404 numa versão antiga. Como faço a atualização?

Essa versão chegou ao fim da vida útil, por isso os respetivos pacotes foram movidos de archive.ubuntu.com para old-releases.ubuntu.com. Altere apenas os nomes dos hosts em /etc/apt/sources.list.d/ubuntu.sources ou em /etc/apt/sources.list nas estruturas mais antigas, e mantenha o seu codename. Depois, execute sudo apt update e sudo apt full-upgrade. Quando o sistema estiver novamente atualizado, do-release-upgrade poderá avançá-lo uma versão de cada vez.

Preciso de remover os meus PPAs antes de executar do-release-upgrade?

Não é obrigatório, porque o atualizador comenta qualquer fonte que não publique pacotes para a nova versão e apresenta uma linha como was disabled (no Release file) para cada uma. É melhor fazer isso manualmente primeiro, porque assim escolhe a ordem e vê o resultado. Execute apt policy nos pacotes relevantes para identificar quais vieram de cada PPA. Depois, reinstale-os a partir do arquivo se a versão do PPA for mais recente do que a disponibilizada pela nova versão.