Como recuperar de uma atualização do Ubuntu interrompida

Atualização do Ubuntu falhou a meio: leia primeiro o sintoma

Uma atualização de versão do Ubuntu de 24.04 para 26.04 que falha deixa o servidor num de quatro estados, e cada estado requer uma correção diferente. O atualizador pode ainda estar a ser executado numa sessão do screen com a qual perdeu o contacto. O dpkg pode ter sido terminado enquanto um pacote estava parcialmente configurado, pelo que o apt recusa agora qualquer operação que instale, remova ou atualize pacotes, embora apt update e comandos apenas de leitura, como apt show, continuem a funcionar. As fontes do apt podem indicar 26.04 enquanto os pacotes instalados ainda são da versão 24.04. Ou o servidor pode nem sequer arrancar. Determine qual destes estados se aplica antes de executar qualquer comando, porque a correção de um estado pode agravar outro.

Uma regra aplica-se aos quatro estados. Não reinicie até saber em que estado está o dpkg. Reiniciar durante a substituição de um pacote é o que transforma uma interrupção recuperável do dpkg no caso em que o sistema não arranca, descrito perto do fim deste guia. Também não inicie um segundo processo apt ou dpkg enquanto o primeiro ainda puder estar ativo, porque dois processos a escrever na base de dados de pacotes podem corrompê-la.

Este guia pressupõe que seguiu o guia de atualização de 24.04 para 26.04 e criou um snapshot antes de começar. Se não o fez, leia a secção sobre o arranque tendo isso em conta, porque o snapshot é a solução para o pior caso.

A atualização ainda está em execução?

Muitas atualizações reportadas como falhadas ainda estão em execução. A sessão SSH caiu, o terminal ficou em branco e o atualizador continuou sem si.

do-release-upgrade foi concebido para este cenário. Quando é executado com a interface de texto, que é a interface usada num servidor, inicia-se dentro de uma sessão GNU screen. Assim, a atualização sobrevive à perda do terminal que a iniciou. Além disso, quando deteta que foi iniciado a partir de uma sessão SSH, oferece iniciar uma segunda instância de sshd noutra porta, 1022 por predefinição. Assim, ainda pode iniciar sessão se o daemon SSH principal falhar durante a substituição dos pacotes. Ambos os factos são importantes neste momento.

Ligue-se novamente por SSH e procure a sessão screen. O atualizador foi executado com sudo, por isso a sessão screen pertence a root. Um screen -ls simples, executado com o seu próprio utilizador, não a vai listar.

sudo screen -ls

screen -ls indica se cada sessão está anexada ou desanexada. Se existir uma sessão na lista, volte a anexar-se a ela. Se ainda estiver marcada como anexada porque a ligação SSH interrompida nunca a libertou, -d desanexa primeiro essa ligação obsoleta.

sudo screen -d -r

Se forem listadas várias sessões, coloque o nome da sessão indicado por screen -ls depois de -r. Não conte com sudo do-release-upgrade para voltar a anexar a sessão automaticamente. O código que encontra a sessão screen existente está no atualizador que ele descarrega. Antes de descarregar qualquer coisa, do-release-upgrade termina com "Please install all available updates for your release before upgrading" sempre que encontra um pacote com uma atualização pendente, exceto atualizações faseadas. Esse é exatamente o estado de um sistema a meio da substituição dos pacotes. Depois de voltar a anexar a sessão, regressa à atualização em execução. Normalmente, esta está à espera de uma resposta sobre um ficheiro de configuração alterado ou sobre o reinício de um serviço. Responda e deixe a atualização terminar.

Se iniciou a atualização dentro do tmux, conforme recomendado pelo guia de atualização, volte primeiro a anexar o tmux com tmux attach. A sessão screen está a ser executada dentro desse painel do tmux, por isso verá diretamente a atualização. Se o painel mostrar apenas uma prompt de shell, o atualizador já não está a ser executado nesse painel. Nesse caso, sudo screen -ls é a verificação seguinte.

Se a porta SSH principal recusar a ligação, tente a porta alternativa: ssh -p 1022 user@host. Esse daemon existe apenas durante a atualização. Se não conseguir iniciar sessão em nenhuma das duas portas, utilize a consola do fornecedor. A partir da consola, sudo ss -ltnp mostra em que portas está à escuta um processo sshd. sudo ufw status indica se a firewall permitiu a passagem pela porta alternativa.

Quando não existe nenhuma sessão screen e nada está à espera na consola, a atualização parou efetivamente. Confirme que não existe ainda nenhuma operação na base de dados de pacotes antes de a alterar:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Um resultado vazio significa que o dpkg está inativo e que pode avançar para a reparação. Um processo dpkg ou apt com um tempo de execução elevado e sem nenhuma sessão screen à qual voltar a anexar está bloqueado. Aguarde alguns minutos, verifique na consola se existe uma pergunta do debconf sem resposta e só depois termine o processo. Nunca elimine os ficheiros de bloqueio em /var/lib/dpkg/ ou /var/lib/apt/lists/ enquanto um processo os mantiver abertos. O bloqueio é o único mecanismo que impede dois processos de escrita de corromperem a base de dados de pacotes.

dpkg foi interrompido e o apt recusa-se a executar

Quando o dpkg é terminado entre a descompactação de um pacote e a execução do respetivo script de configuração, deixa o pacote marcado como parcialmente concluído e deixa entradas incompletas no seu diário em /var/lib/dpkg/updates/. Todos os comandos do apt que obtêm o bloqueio do dpkg, ou seja, os que instalam, removem ou atualizam pacotes, verificam primeiro esse diário e param com dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.. Os comandos que nunca obtêm esse bloqueio, como apt update, apt list, apt show e apt-cache, continuam a funcionar, pelo que ainda pode consultar o sistema. Independentemente do resto da saída do apt, o primeiro passo é sempre o mesmo.

sudo dpkg --configure -a

Isto conclui a configuração de todos os pacotes que foram descompactados, mas nunca configurados. Executa os scripts do maintainer pela ordem das dependências e pode demorar bastante tempo num sistema com uma atualização incompleta, por isso deixe-o terminar. Se parar num pacote, apresenta o nome do pacote e o script que falhou. Anote esse nome. É o pacote que interrompeu a atualização, e a secção seguinte mostra como interpretar o erro.

Depois deixe o apt reparar as dependências que a interrupção deixou por satisfazer, porque alguns pacotes foram atualizados, mas os pacotes de que dependem não foram.

sudo apt --fix-broken install

Depois conclua a atualização que o programa de atualização estava a executar:

sudo apt update
sudo apt full-upgrade

Use full-upgrade em vez de upgrade, porque uma atualização de versão remove pacotes e o upgrade normal recusa-se a remover qualquer pacote. Leia o resumo apresentado pelo apt antes de confirmar. Uma lista curta de remoções é normal. Uma lista que remova ubuntu-server, systemd, openssh-server ou o seu pacote do kernel não é normal. Nesse caso, responda não e descubra por que motivo o apt pretende removê-los antes de continuar.

Verifique o resultado antes de fazer qualquer outra coisa:

sudo dpkg --audit
sudo apt-get check

dpkg --audit lista todos os pacotes que ainda estão num estado inconsistente, e apt-get check apresenta as dependências não satisfeitas. Ambos devem não apresentar qualquer saída. Quando isso acontecer, execute sudo apt autoremove para remover as dependências instaladas automaticamente de que já nada precisa. Os pacotes marcados como instalados manualmente permanecem, mesmo quando nada depende deles. Depois confirme a versão com cat /etc/os-release, execute sudo update-initramfs -u -k all e sudo update-grub e só então reinicie o sistema.

Como ler /var/log/dist-upgrade para encontrar o pacote que interrompeu a atualização

O programa de atualização escreve tudo em /var/log/dist-upgrade/. Se o executou mais de uma vez, move os logs da tentativa anterior para um subdiretório com um nome baseado num timestamp. Por isso, consulte primeiro ls -la /var/log/dist-upgrade/ e leia o diretório correspondente à execução que falhou.

main.log é o diário do próprio programa de atualização. Regista a fase em que a execução se encontrava e as decisões tomadas sobre as suas fontes de pacotes. Se o próprio programa de atualização terminou de forma inesperada, o traceback do Python também está aqui. Leia-o a partir do fim: as últimas linhas indicam a fase em que o programa parou. Um traceback nesse ponto significa que a ferramenta falhou, não um pacote.

apt.log contém o raciocínio do resolvedor de dependências. É detalhado e é relevante quando o apt recusou calcular a atualização, o que significa que a falha ocorreu antes de qualquer pacote ser alterado. Se a atualização chegou a instalar pacotes, normalmente pode ignorá-lo.

apt-term.log é o ficheiro que deve consultar quando um pacote falha. Regista a saída do terminal do dpkg durante a atualização, ou seja, o mesmo texto que teria sido apresentado no ecrã. O último pacote mencionado antes do fim é o que estava a ser processado quando a atualização parou. Se um script do maintainer falhou, a mensagem de erro do dpkg está nesse ponto, acompanhada pelo erro do próprio script logo acima.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Compare essa informação com /var/log/dpkg.log, que regista as alterações de estado e as ações executadas pelo dpkg, cada uma com um timestamp. tail -n 30 /var/log/dpkg.log mostra o último pacote tocado pelo dpkg e a operação que estava a executar. Essa é a mesma resposta obtida de uma segunda fonte, mas apenas se nada tiver executado o dpkg desde a falha. Depois de executar dpkg --configure -a ou apt --fix-broken install, as respetivas entradas aparecem no fim. Nesse caso, recue até às linhas com o timestamp da altura em que a atualização parou.

A maioria das falhas nesta fase num servidor resulta de uma destas causas. Um serviço que o pacote reinicia no postinst falha ao iniciar devido a um ficheiro de configuração que personalizou, e systemctl status juntamente com journalctl -xeu nesse serviço indica a linha que o serviço não aceita. Um sistema de ficheiros ficou sem espaço, normalmente /boot devido a kernels antigos ou /var devido à cache de pacotes do apt, e df -h / /boot /var mostra essa situação. sudo apt clean esvazia a cache mesmo quando o apt está bloqueado, e um disco que indica estar cheio quando du diz que não está tem uma explicação própria. Um pacote de um repositório de terceiros que o programa de atualização desativou depende de uma biblioteca que a versão 26.04 já não disponibiliza. Um pacote retido (apt-mark showhold) impediu a atualização de uma dependência. Corrija a causa e execute sudo dpkg --configure -a novamente. O comando retoma a operação no ponto em que parou.

Se um pacote se recusar a ser configurado independentemente do que fizer e nada importante depender dele, remova-o e reinstale-o depois de concluir a atualização:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Use este procedimento apenas num pacote que consiga identificar e justificar. Nunca o use numa biblioteca ou em qualquer componente da cadeia de dependências de ubuntu-server, porque a remoção forçada ignora as verificações que indicariam o que mais ficaria danificado.

As fontes foram alteradas, mas os pacotes não

O atualizador reescreve as fontes do apt no início, antes de transferir qualquer pacote. Se for interrompido depois desse ponto, as fontes passam a indicar 26.04, enquanto os pacotes instalados ficam numa combinação de versões. Essa combinação confunde as ferramentas e explica por que do-release-upgrade pode agora insistir que não existe uma nova versão.

Compare os dois locais que indicam em que versão está. /etc/apt/sources.list.d/ubuntu.sources é o ficheiro de fontes deb822 introduzido em 24.04, e as linhas Suites: contêm o codinome da versão. /etc/os-release é escrito pelo pacote base-files e indica qual versão está efetivamente instalada.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Há três combinações importantes. Se as fontes ainda indicarem 24.04 (codinome noble) e os-release também indicar 24.04, a atualização não passou das verificações. Pode executar sudo do-release-upgrade novamente depois de consultar main.log para saber por que foi interrompida. O processo recusa iniciar enquanto houver qualquer atualização de 24.04 pendente ou enquanto /var/run/reboot-required.pkgs indicar libc6, linux-base ou um pacote linux-image. Por isso, execute sudo apt full-upgrade e reinicie se esse ficheiro solicitar primeiro. Se as fontes indicarem o codinome de 26.04 e os-release ainda indicar 24.04, a substituição dos pacotes começou e foi interrompida. Nesse caso, a reparação do dpkg descrita na secção anterior, terminando com apt full-upgrade, é a forma de concluir o processo. Não execute novamente o atualizador neste estado. Com pacotes de 26.04 pendentes, ele para e solicita a instalação de todas as atualizações disponíveis primeiro. Se as fontes indicarem 26.04 e os-release também indicar 26.04, base-files foi um dos pacotes que conseguiu ser instalado. O sistema agora identifica-se como 26.04, mesmo que a maior parte dos pacotes ainda não esteja nessa versão.

A última combinação é a armadilha. do-release-upgrade determina a versão instalada com base na mesma informação que os-release contém. Se essa informação já indicar 26.04, o resultado seguinte depende da linha Prompt= em /etc/update-manager/release-upgrades. Com Prompt=lts, a predefinição em 26.04, a ferramenta procura uma versão LTS posterior a 26.04, não encontra nenhuma e informa que não existe uma nova versão disponível. Com Prompt=normal, o anúncio da Canonical sobre 26.10, disponibilizada em 15 October 2026, indica que os utilizadores de 26.04 receberão a proposta de atualização para 26.10. Os metadados de atualização de versões do Ubuntu ainda não listavam 26.10 quando foram verificados em 24 October 2026. Por isso, nessa data, a ferramenta continuava a informar que não havia uma nova versão disponível. Quando 26.10 for listada, a ferramenta encontrará 26.10 e depois parará com "Please install all available updates for your release before upgrading", porque os pacotes que ainda estão em 24.04 têm atualizações pendentes. Em qualquer dos casos, a ferramenta está a responder a uma pergunta sobre os-release, e os-release está incorreto. Pare de usar o atualizador e conclua com apt: sudo apt update e depois sudo apt full-upgrade. Isto atualiza os pacotes que ainda estão na versão de 24.04, exceto os que estiverem retidos (apt-mark showhold lista-os), e pode remover alguns pacotes em vez de os atualizar. Leia o resumo e execute depois sudo apt autoremove. Vale a pena excluir as outras razões pelas quais do-release-upgrade informa que não existe uma nova versão se os-release ainda indicar 24.04. A espera pela primeira versão de manutenção no aviso de atualização LTS já não se aplica: os metadados de atualização LTS do Ubuntu listavam 26.04.1 como suportada quando foram verificados em 24 October 2026.

O atualizador também desativa as fontes de terceiros em /etc/apt/sources.list.d/ e mantém uma cópia de segurança de cada ficheiro alterado, adicionando um sufixo ao nome original. Execute ls -la /etc/apt/sources.list.d/ e diff para comparar cada ficheiro original com a respetiva cópia de segurança e ver exatamente o que foi alterado. Mantenha as entradas de terceiros desativadas até os pacotes do Ubuntu estarem consistentes. Depois, reative cada entrada apenas quando confirmar que o fornecedor publica pacotes para 26.04. Se apt update informar que uma fonte está configurada mais de uma vez, uma entrada antiga de sources.list e a nova entrada de ubuntu.sources descrevem a mesma suite. O erro de fonte duplicada em deb822 explica qual delas deve remover.

O servidor não arranca depois da atualização

Um reboot revela o custo de uma atualização incompleta. Num VPS, as causas mais prováveis são um kernel instalado sem o respetivo initramfs, uma configuração do GRUB que nunca foi regenerada, um pacote que ficou parcialmente configurado e de que uma unidade de arranque depende, ou um disco que ficou sem espaço enquanto o dpkg escrevia.

Abra a consola do fornecedor antes de fazer qualquer outra coisa. Ela mostra onde o arranque para: no menu do GRUB, num kernel panic, numa verificação do sistema de ficheiros à espera de uma resposta, ou numa shell de emergência do systemd a pedir a palavra-passe de root. Essa observação determina o passo seguinte.

Se o GRUB aparecer, arranque com o kernel 24.04 anterior através do submenu de opções avançadas. O kernel antigo normalmente permanece instalado até autoremove ser executado. Depois de o sistema arrancar com o kernel antigo, execute sudo dpkg --configure -a e faça o restante processo de reparação da secção anterior. Em seguida, execute sudo update-initramfs -u -k all e sudo update-grub antes de tentar novamente arrancar com o kernel novo. Recuperar um VPS que não arranca depois de uma atualização do kernel explica em detalhe a parte do GRUB e do initramfs.

Se entrar numa shell de emergência, o sistema de ficheiros root normalmente está montado como apenas de leitura. Monte-o novamente com permissões de escrita e faça a mesma reparação:

mount -o remount,rw /
dpkg --configure -a

Se o sistema não chegar sequer a uma shell, arranque a imagem de rescue do fornecedor, monte o disco do VPS e faça a reparação a partir de um chroot. Encontre a partição root com lsblk em vez de adivinhar o respetivo nome.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Antes de passar uma hora nesse chroot, compare essa opção com o snapshot. Criou um snapshot antes de começar, e a maioria dos fornecedores consegue restaurá-lo em poucos minutos. Depois volta a executar a atualização, o que demora bem menos de uma hora num VPS, e desta vez já sabe qual é o pacote que precisa de correção. Restaurar é a opção mais rápida quando qualquer uma destas condições se aplica: não consegue aceder a uma consola nem a uma imagem de rescue, não consegue identificar o pacote que interrompeu a atualização, há mais de um pacote bloqueado, ou o servidor executa um serviço de que outras pessoas estão à espera. Fazer a correção manual é mais rápido apenas quando sabe exatamente o que falhou e a correção consiste num único comando.

Copie /var/log/dist-upgrade/ para fora do servidor antes de restaurar, usando a imagem de rescue se essa for a única forma de aceder ao sistema. A restauração apaga esses logs, e uma segunda tentativa falhará exatamente da mesma forma se nunca descobrir por que motivo a primeira falhou. Vale a pena ler O que um snapshot pode e não pode restaurar antes de depender de um. Um snapshot reverte o disco inteiro, incluindo todos os dados escritos desde a sua criação. Isso é aceitável durante uma atualização, mas não é aceitável uma semana mais tarde.

Três sinais de que o sistema deve ser reconstruído

Algumas atualizações não compensam ser reparadas. Restaurar um snapshot e repetir a operação é barato, mas, se a falha tiver origem no estado do próprio sistema, a segunda tentativa também falhará. Nesse caso, a solução correta é uma imagem nova do 26.04, com os seus dados restaurados a partir de uma cópia de segurança. Há três sinais de que chegou a esse ponto.

Primeiro, a própria base de dados do dpkg está danificada. Se dpkg --audit ou apt-get check não conseguir ler /var/lib/dpkg/status, em vez de indicar pacotes danificados dentro desse ficheiro, perdeu-se o registo do que está instalado. O Ubuntu mantém cópias diárias em /var/backups/ (ls -la /var/backups/dpkg.status*), e substituir o ficheiro atual pela cópia íntegra mais recente por vezes resolve o problema. Mas, quando essa cópia já não corresponde ao que existe realmente no disco, está a trabalhar por tentativa, e cada execução posterior do apt baseia-se nessa suposição.

Segundo, as ferramentas necessárias para reparar o sistema também estão danificadas. Se apt ou dpkg não iniciar porque uma biblioteca partilhada foi removida ou parcialmente substituída, ou se systemd não conseguir iniciar unidades porque o próprio pacote está parcialmente configurado, já não existe um gestor de pacotes funcional para reparar o gestor de pacotes. ldd /usr/bin/apt indica se todas as bibliotecas do apt estão presentes. Por vezes, é possível recuperar a partir de um chroot na imagem de recuperação, mas normalmente esse processo demora mais do que reconstruir o sistema.

Terceiro, a lista de pacotes danificados não está a diminuir. Se executou dpkg --configure -a e apt --fix-broken install repetidamente durante mais de uma hora e cada passagem revela um pacote novo em vez de resolver o anterior, o sistema levou para a atualização problemas que ela não criou: ficheiros em /usr editados manualmente, pacotes fixados ou retidos, um repositório de terceiros que substituiu bibliotecas essenciais ou uma atualização anterior que nunca foi concluída. Uma imagem nova não contém esses problemas, e restaurar os seus dados nela demora menos do que identificá-los.

A reconstrução só é barata se os dados estiverem armazenados noutro local. Essa é a diferença entre um snapshot e uma cópia de segurança, e é por isso que o guia de atualização pede ambos.

FAQ

Posso simplesmente executar do-release-upgrade novamente depois de uma interrupção?

Não como primeira medida. Se o atualizador ainda estiver em execução na sessão screen, volte a ligar-se com sudo screen -d -r; uma segunda execução de do-release-upgrade para antes de chegar ao seu próprio código de ligação, porque se recusa a iniciar enquanto houver algum pacote com uma atualização pendente. Se o atualizador tiver terminado, execute primeiro sudo dpkg --configure -a e sudo apt --fix-broken install. Quando as fontes já indicarem 26.04, conclua com sudo apt full-upgrade em vez de usar o atualizador. Quando ainda indicarem 24.04, execute sudo apt full-upgrade, reinicie se /var/run/reboot-required.pkgs listar libc6, linux-base ou um kernel e, em seguida, inicie novamente o atualizador. Ele também recusa iniciar quando Prompt=never está definido em /etc/update-manager/release-upgrades ou quando o servidor do Ubuntu responde "Release upgrade not possible right now".

Por que razão do-release-upgrade indica que não existe uma nova versão depois de a atualização ter falhado?

Porque base-files, o pacote que escreve /etc/os-release, foi um dos pacotes atualizados antes da interrupção. A ferramenta lê agora esse ficheiro, conclui que está em 26.04 e, com a definição predefinida Prompt=lts, não encontra uma versão LTS mais recente para disponibilizar. Se definir Prompt=normal, encontrará a versão 26.10 assim que os metadados de atualização do Ubuntu a listarem e, em seguida, recusará continuar porque ainda há pacotes à espera de atualizações. Compare grep VERSION_ID /etc/os-release com grep Suites /etc/apt/sources.list.d/ubuntu.sources e conclua com sudo apt update && sudo apt full-upgrade.

É seguro reiniciar um servidor Ubuntu com uma atualização incompleta?

Não até sudo dpkg --audit não devolver nada. Reiniciar com um kernel desempacotado mas não configurado, ou sem regenerar o GRUB, é a forma mais comum de transformar uma atualização que poderia ser corrigida em dez minutos numa tarefa de recuperação através de uma imagem de rescue. Conclua a reparação do dpkg e apt full-upgrade, execute update-initramfs -u -k all e update-grub e só depois reinicie.

Como descubro qual pacote interrompeu a atualização?

Leia o fim de /var/log/dist-upgrade/apt-term.log, que contém a saída final do dpkg. O último pacote indicado antes do fim do log é o pacote que estava em execução, e um script de manutenção com falhas apresenta o erro imediatamente acima da mensagem do dpkg. /var/log/dpkg.log é uma segunda fonte: as linhas com o timestamp do momento em que a atualização parou indicam o mesmo pacote, mas tudo o que tenha executado através do dpkg desde então é registado depois dessas linhas, pelo que as últimas linhas podem não ser relevantes. Se, em vez disso, main.log terminar com um traceback de Python, o próprio atualizador terminou de forma anormal e nenhum pacote é responsável.

Devo restaurar o snapshot ou continuar a corrigir o sistema?

Restaure quando não conseguir identificar o pacote que falhou, quando houver mais de um pacote bloqueado, quando não tiver acesso à consola ou quando o servidor precisar de voltar rapidamente ao serviço. Continue a corrigir apenas quando souber exatamente o que falhou e a correção consistir num único comando. Copie /var/log/dist-upgrade/ para fora do servidor antes de restaurar; caso contrário, a segunda tentativa falhará da mesma forma.