O que fazer quando o apt update / apt install falha na VPS (2026): diagnóstico de travas do dpkg, chaves GPG, repositórios inválidos e conflitos de dependências

Execute:

sudo apt update

Não olhe só a última linha. Classifique os erros em categorias:

Classifique primeiro, depois aja. O pior com problemas de apt é "não olhar nada e simplesmente apagar travas, trocar repositórios e remover pacotes à força".

Se aparecer:

Temporary failure resolving 'archive.ubuntu.com'

Primeiro confirme se é DNS:

ping -c 3 1.1.1.1
ping -c 3 archive.ubuntu.com

Se o IP responde mas o nome de domínio não, corrija o DNS primeiro em vez de continuar mexendo no apt. Você pode testar temporariamente um DNS público:

dig @1.1.1.1 archive.ubuntu.com

Também pode verificar o resolver local:

resolvectl status
cat /etc/resolv.conf

Se você acabou de ler o artigo anterior sobre resolução DNS, sabe que esse tipo de problema deve ser investigado começando por systemd-resolved, /etc/resolv.conf e pela configuração de DNS entregue pelo provedor de nuvem.

Se o DNS está normal mas os downloads do apt estão lentos ou falhando, tente IPv4:

sudo apt -o Acquire::ForceIPv4=true update

Algumas VPS têm um endereço IPv6 configurado mas sem rota funcional, e o apt fica travado no IPv6. A correção de longo prazo é tratar o roteamento IPv6 ou a configuração do repositório; não é recomendável apenas esconder o problema com um parâmetro temporário.

Se você vir:

404 Not Found
The repository does not have a Release file

Primeiro veja a versão do sistema:

lsb_release -a
cat /etc/os-release

Depois olhe os arquivos de repositório:

cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Quando uma versão do Ubuntu chega ao EOL, os repositórios padrão podem deixar de oferecer os caminhos correspondentes. Por exemplo, versões antigas do Ubuntu precisam mudar para old-releases, ou melhor ainda, atualizar para uma versão suportada.

Não copie às cegas jammy, noble e focal da internet e misture tudo. O Ubuntu 22.04 é jammy e o 24.04 é noble. Se a versão do sistema e o codinome do repositório não coincidirem, vai aparecer uma pilha de conflitos de dependências.

Você pode verificar rapidamente quais codinomes são usados nos repositórios:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/*.list

Se na mesma máquina houver vários codinomes de distribuição misturados, pare. Misturar repositórios é uma das principais causas de desastres com apt.

Erro comum:

NO_PUBKEY ABCD1234EFGH5678
The following signatures couldn't be verified

Normalmente isso significa que a chave de assinatura de um repositório de terceiros não foi instalada corretamente, expirou, ou um tutorial antigo ainda usa o obsoleto apt-key.

Primeiro descubra qual é o repositório:

grep -R "第三方域名或仓库名" /etc/apt/sources.list.d/ /etc/apt/sources.list

O método moderno costuma ser colocar a chave em:

/etc/apt/keyrings/

E depois, no arquivo de repositório, usar:

signed-by=/etc/apt/keyrings/example.gpg

Por exemplo, o repositório oficial do Docker usa mais ou menos essa estrutura. A documentação oficial de instalação de cada software fornece os comandos correspondentes. Não copie um comando de keyserver de um fórum sem critério, porque você está confiando nesse repositório para instalar software no seu sistema.

Depois de corrigir, execute novamente:

sudo apt update

Muita gente se depara com:

Could not get lock /var/lib/dpkg/lock-frontend

e logo faz:

sudo rm /var/lib/dpkg/lock-frontend

Não recomendado.

Primeiro verifique se há uma atualização automática do sistema em execução:

ps aux | grep -E "apt|dpkg|unattended"
systemctl status apt-daily.service apt-daily-upgrade.service --no-pager

Depois veja quem está ocupando a trava:

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock

Se apt.systemd.daily ou unattended-upgrades estiverem em execução, normalmente é mais seguro esperar que terminem.

Só se você confirmar que o processo está realmente travado deve considerar encerrar o processo relacionado. Antes de encerrar, confirme que nenhum pacote importante está sendo instalado:

sudo fuser -v /var/lib/dpkg/lock-frontend

Não saia matando processos só para ir mais rápido. Depois de interromper o dpkg, você ainda vai precisar corrigir o estado de instalação parcial.

Se aparecer:

dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'

faça o que ele indica:

sudo dpkg --configure -a

Esse comando continua a configuração dos pacotes cuja instalação foi interrompida da última vez.

Quando terminar, execute:

sudo apt --fix-broken install
sudo apt update

A comunidade do Ubuntu e os fluxos oficiais de diagnóstico também costumam usar comandos como dpkg --configure -a e apt --fix-broken install para corrigir o estado interrompido. A ordem importa: primeiro deixe o dpkg concluir a configuração incompleta, depois trate as dependências.

Se você vir:

You have held broken packages

primeiro veja se há pacotes retidos (hold):

apt-mark showhold

Se realmente houver pacotes retidos, descubra por quê. Não remova o hold às cegas; pode ser que tenham sido retidos antes para fixar a versão do banco de dados, do PHP ou do Nginx.

Veja a política do pacote:

apt-cache policy 包名

Simule a instalação sem executá-la de verdade:

sudo apt install -s 包名

-s é uma simulação, útil para ver primeiro o que o apt pretende instalar e remover.

Se faltarem dependências:

sudo apt --fix-broken install

Se repositórios misturados estiverem fazendo as versões brigarem entre si, priorize limpar os repositórios errados em vez de forçar a instalação.

Você pode auditar com o dpkg:

sudo dpkg --audit

Também pode ver estados anômalos:

dpkg -l | grep -E "^(..r|..U|..F|..H|iF|iU|iH)"

Estados comuns:

• iU: pacote desempacotado mas não configurado
• iF: falha na configuração
• rc: pacote removido mas arquivos de configuração remanescentes

Para iU e iF, normalmente primeiro:

sudo dpkg --configure -a
sudo apt --fix-broken install

Se um pacote continua falhando na configuração, veja os erros do postinst, os logs de inicialização do serviço e o espaço em disco, em vez de removê-lo à força diretamente.

O apt/dpkg precisa gravar cache, desempacotar e gravar arquivos de configuração. Se o disco ou os inodes estiverem cheios, também vai falhar.

Primeiro veja:

df -h
df -i

Depois limpe o cache do apt:

sudo apt clean

Se /boot estiver cheio, a causa comum é excesso de kernels antigos. Primeiro veja o kernel em execução:

uname -r

Depois veja os kernels instalados:

dpkg -l 'linux-image*' | grep '^ii'

Não remova o kernel que está em execução. Para limpar kernels antigos, recomenda-se usar o mecanismo autoremove do apt:

sudo apt autoremove

Antes de executar, veja com atenção o que ele vai remover.

apt update apenas atualiza o índice de pacotes. Na instalação de verdade, ainda podem surgir dependências, conflitos, disco ou falhas de inicialização de serviços.

Recomenda-se simular primeiro:

sudo apt install -s nginx

Depois de confirmar que ele não vai remover pacotes estranhos, execute:

sudo apt install nginx

Se a instalação de algum serviço falhar, como MySQL, Nginx ou Docker, continue verificando os logs do serviço correspondente:

systemctl status nginx --no-pager
journalctl -u nginx --since "30 minutes ago" --no-pager

Algumas falhas de instalação de pacotes não são porque o apt está quebrado, mas porque o serviço não inicia após a instalação e o script postinst do dpkg retorna erro.

Quando encontro erros de apt/dpkg, geralmente sigo esta ordem:

sudo apt update

Primeiro veja o tipo de erro. Se for DNS, corrija o DNS primeiro. Se for trava:

ps aux | grep -E "apt|dpkg|unattended"
sudo lsof /var/lib/dpkg/lock-frontend

Se for interrupção:

sudo dpkg --configure -a

Depois corrija as dependências:

sudo apt --fix-broken install

Limpe o cache e atualize:

sudo apt clean
sudo apt update

Verifique estados corrompidos:

sudo dpkg --audit
apt-mark showhold

Por fim, instale o software desejado:

sudo apt install -s 包名
sudo apt install 包名

Esse fluxo é bem mais estável do que "apagar a trava + instalar à força".

Trocar de repositório não é solução para tudo, mas há algumas situações em que vale considerar:

• O mirror atual está retornando 404 ou dando timeout há muito tempo
• A região onde a VPS está tem acesso muito lento aos repositórios oficiais
• O mirror interno do provedor de nuvem é mais estável
• O repositório atual não suporta a sua versão do sistema

Faça backup antes de trocar de repositório:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

Depois confirme o codinome do sistema:

. /etc/os-release
echo "$VERSION_CODENAME"

O codinome no repositório precisa coincidir com o do sistema. Não use repositórios do 24.04 no Ubuntu 22.04, nem misture repositórios do Ubuntu no Debian 12.

Depois de trocar:

sudo apt update

Se aparecerem erros de GPG, Release file ou conflitos de dependências, significa que os repositórios ainda não estão corretamente combinados.

Há situações em que continuar forçando o reparo tem risco alto:

• Um banco de dados de produção está em execução e o apt quer remover pacotes relacionados ao banco
• Os repositórios do sistema misturam vários codinomes de distribuição
• /boot e / já estão cheios
• O estado do dpkg está anômalo em muitos pontos
• Você não sabe por que um pacote com hold está retido
• A imagem do provedor de nuvem está muito antiga e o sistema já está em EOL

Nesse momento, faça primeiro um snapshot ou backup e depois continue. O gerenciador de pacotes está na base do sistema; uma remoção forçada pode derrubar SSH, rede e banco de dados juntos.

• Você leu o erro completo do apt, não só a última linha
• Problemas de DNS/rede foram descartados primeiro com ping, dig, resolvectl
• O codinome do repositório coincide com a versão do sistema
• Repositórios de terceiros usam a chave GPG correta e signed-by
• Para travas do dpkg, verifique primeiro os processos; não apague o arquivo de trava diretamente
• Para dpkg was interrupted, execute primeiro dpkg --configure -a
• Para problemas de dependências, execute depois apt --fix-broken install
• Use dpkg --audit para verificar pacotes parcialmente instalados
• Use apt-mark showhold para verificar pacotes retidos
• Verifique df -h e df -i
• Simule com apt install -s antes de instalar
• Faça snapshot/backup antes de mudanças grandes nos repositórios ou de remover pacotes à força

As falhas de apt/dpkg parecem um monte de erros em inglês, mas a maioria pode ser classificada: resolução de rede, configuração de repositórios, assinaturas, travas, interrupções, dependências, disco. Classifique primeiro e depois corrija na ordem. Desde que você não comece apagando travas, trocando repositórios e removendo pacotes à força sem critério, a maioria dos apt de VPS pode ser recuperada.