Como corrigir do-release-upgrade sem nova versão

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

do-release-upgrade terminando em No new release found. quase nunca indica uma ferramenta avariada. O caminho solicitado está fechado nesse momento, e a ferramenta informa isso da forma mais curta possível. Cinco fatores podem fechá-lo: a configuração Prompt em /etc/update-manager/release-upgrades, o bloqueio da versão pontual nas atualizações LTS (suporte de longo prazo), repositórios de terceiros, pacotes retidos ou parcialmente configurados e uma versão que já ultrapassou o fim do suporte.

Verifique-os nesta ordem. Cada um tem um comando que confirma se se aplica ao seu servidor, para que não precise adivinhar qual dos cinco está em causa.

O que o sinalizador de verificação realmente informa

sudo do-release-upgrade -c
echo $?

-c executa apenas a verificação. Lê os metadados da versão 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á duas informações 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 o mesmo resultado aos 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 código com atenção antes de criar uma verificação baseada nele.

Se o banner de login ainda mostrar o resultado antigo, esse resultado 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 simplesmente em -c. O banner apenas repete o resultado da última verificação executada.

A verificação também precisa de conseguir aceder a changelogs.ubuntu.com. Num servidor atrás de uma firewall de saída restritiva ou de um proxy que a ferramenta não consiga consultar, não é possível procurar atualizações.

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

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

Se o comando não existir, ele 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 contém 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 o ficheiro e 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 divirja entre releases. Se encontrar esse valor, 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 trata a definição como normal. Numa máquina 25.10, os dois valores comportam-se de forma idêntica. Numa máquina 24.04, não, e essa diferença constitui toda a secção seguinte.

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

Prompt determina qual ficheiro de metadados 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 seu sinalizador Supported: está definido como 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 discordam sobre o Ubuntu 26.04. O ficheiro de LTS diz:

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

O ficheiro normal diz:

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

Esse valor Supported: 0 no ficheiro de LTS é o bloqueio. Um servidor 24.04 que use o Prompt=lts predefinido lê esse ficheiro, não encontra nenhuma release LTS mais recente marcada como disponível e apresenta No new release found.. Não há nenhum problema na sua máquina. A Canonical ainda não abriu o caminho.

O sinalizador muda para 1 quando o primeiro point release é disponibilizado. O Ubuntu 26.04.1 está agendado para 27 August 2026, mas os calendários de releases podem mudar. Por isso, consulte os metadados em vez de confiar numa data. O atraso é deliberado: as pessoas que atualizam primeiro encontram os bloqueios, que são corrigidos antes de a população muito maior de servidores LTS avançar.

Isto deixa duas opções legítimas. Aguarde pelo point release. Essa é a escolha certa para qualquer servidor que prefira não acompanhar de perto. Ou defina Prompt=normal, que direciona a mesma ferramenta para meta-release, onde o 26.04 já está marcado como suportado. O segundo caminho atualiza o sistema para o 26.04 disponibilizado, não para uma build de desenvolvimento. Por isso, é uma opção defensável numa máquina que possa restaurar a partir de um snapshot. Reponha o valor lts quando terminar. O procedimento completo, passo a passo, está em no 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 pessoal de pacotes) 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, isto é um aviso que pode aceitar. 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 começar, em vez de deixar que a ferramenta decida 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 aplicado a um nome de pacote mostra de que repositório veio cada versão instalada. Assim, pode ver exatamente que 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 disponibilizada pela nova versão. Quando isso for relevante, remova também o pacote e volte a instalá-lo a partir do arquivo depois da atualização. Se pretende voltar a ativar um repositório, como o do Tailscale, atualize o respetivo codename para a nova versão antes de instalar novamente o pacote. É daí que surgem a maioria dos erros de instalação do Tailscale no Ubuntu.

Existe uma flag para escolher o comportamento oposto. A página de 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 contra uma série para a qual esse repositório nunca compilou 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 é explicado em o erro de entrada de fonte duplicada no formato deb822.

Pacotes retidos e parcialmente configurados interrompem o cálculo

Uma atualização de versão tem de mover quase todos os pacotes do sistema. Se um pacote não puder ser atualizado, o cálculo falha, e o atualizador prefere parar cedo a deixar o sistema num estado incompleto. Dois comandos encontram a causa.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold apresenta os pacotes retidos, um por linha, e não apresenta nada num sistema sem problemas. 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. Remova a retenção dos pacotes de que já não precisa com sudo apt-mark unhold seguido do nome do pacote.

dpkg --audit apresenta os pacotes que foram desempacotados, mas nunca configurados. Esse estado resulta de uma instalação interrompida, normalmente porque a sessão caiu. O atualizador tenta corrigi-lo e apresenta dpkg interrupted, calling dpkg --configure -a, mas executar primeiro a correção permite ler o erro em vez de o ver passar no ecrã. Se a ferramenta não conseguir corrigir um pacote, apresenta 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.

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 de 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 imagina. Essa opção instala todas as atualizações. Reinicie depois se tiver sido incluído um kernel, para fazer a atualização a partir do kernel que está realmente em execução. Um servidor que já se mantém atualizado através de atualizações de segurança não assistidas tem menos trabalho nesta fase, embora esse mecanismo nunca atravesse uma fronteira de versão por conceçã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 procedimento normal não oferece nenhuma atualização a partir dela. Verificado em 13 de agosto de 2026, meta-release informa o seguinte sobre a versão 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 nessa altura. 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 avança. 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 não altere o seu codename. Apenas o nome do host muda.

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 restaurá-lo se a edição tiver sido aplicada ao ficheiro errado. Um apt update limpo depois disso significa que o arquivo está novamente acessível, e do-release-upgrade poderá comunicar consigo.

Tenha expectativas realistas sobre o resultado. 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 a um pacote mantido. Num VPS, muitas vezes é mais rápido criar um servidor novo com a versão LTS atual, migrar o serviço e manter o servidor antigo até ter a certeza de que tudo funciona. Isso também fornece um rollback, algo que uma atualização no local nunca oferece. Se estiver a escolher qual a linha de versões a utilizar 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 do manual descreve-o assim: "Se estiver a usar a versão suportada mais recente, 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 entrega 26.04, já lançada, a um servidor 24.04. O objetivo é 26.10, uma versão que ainda está em desenvolvimento. As recomendações antigas para "basta adicionar -d" foram escritas para o período anterior ao lançamento de uma versão LTS. Repeti-las agora encaminha o servidor para uma versão que não pretendia usar. Com Prompt=lts ainda ativo, o sinalizador termina e apresenta uma mensagem própria:

There is no development version of an LTS available.

A documentação de servidores do Ubuntu é clara sobre este sinalizador: "não é recomendável 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 deixar um serviço indisponível à 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 a versão 26.04 já lançada antes de a barreira LTS abrir, Prompt=normal é o procedimento correto.

Execute a atualização onde uma sessão SSH interrompida não a possa interromper

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 estiver a trabalhar, o processo é terminado com pacotes descompactados e não configurados. Esse é precisamente o estado que impede a próxima tentativa. 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, porque é um processo filho do servidor tmux, e não da sua sessão SSH. screen -S upgrade e screen -r upgrade fazem o mesmo se preferir screen.

O atualizador tem uma proteção própria para quem não usa um multiplexador. Quando deteta que está a ser executado através de SSH, propõe iniciar um segundo sshd na porta 1022. Assim, uma sessão principal interrompida continua a deixar uma forma de acesso. A decisão é tomada percorrendo os processos pai do próprio atualizador à procura de um processo chamado sshd. Dentro do tmux ou do screen, essa pesquisa encontra o servidor do multiplexador, pelo que a proposta nunca aparece. O ficheiro 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 pedido. Já tem uma proteção melhor.

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

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

A maioria dos fornecedores de VPS executa uma segunda firewall no respetivo painel de controlo, fora do sistema operativo. A porta 1022 também tem de estar aberta nessa firewall. Caso contrário, o listener de fallback estará em execução, mas inacessível. Essa é a pior das duas situações.

Antes de escrever o comando, deixe estas quatro coisas preparadas:

• Crie um snapshot ou uma cópia de segurança completa. Uma atualização de versão no local não tem operação de desfazer, e esta é a única cópia de segurança que terá.
• Confirme que consegue abrir a consola do fornecedor antes de precisar dela. Se o servidor não voltar depois do reboot, não terá SSH, precisamente. Um kernel que não arranca é um problema separado, com os seus próprios passos 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 chega com a versão, 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 valor padrão de Prompt=lts 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é ao primeiro point release. O atualizador não encontra uma versão LTS mais recente marcada como disponível e para. Consulte o ficheiro com curl -s https://changelogs.ubuntu.com/meta-release-lts e leia o último bloco. Em 13 de agosto de 2026, a opção continuava definida como 0, e o Ubuntu 26.04.1 estava agendado para 27 de agosto de 2026.

É seguro definir Prompt=normal em vez de esperar pelo point release?

Isto atualiza o sistema para o 26.04 lançado, e não para uma build de desenvolvimento, porque Prompt=normal lê meta-release, onde 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 correr mal. Depois, volte a definir o valor como lts.

A opção -d atualiza o sistema para o 26.04?

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

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 layouts mais antigos, em /etc/apt/sources.list, 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 source que não publique pacotes para a nova versão e apresenta uma linha como was disabled (no Release file) para cada um. É preferível fazer isto primeiro manualmente, porque assim controla a ordem e vê o resultado. Execute apt policy nos pacotes relevantes para identificar quais foram instalados a partir de cada PPA. Depois, reinstale-os a partir do archive se a versão do PPA for mais recente do que a disponível na nova versão.