Corrigir fontes apt duplicadas e ficheiros deb822

O que significa o erro de fontes apt duplicadas

Fontes apt duplicadas significam que um repositório foi declarado duas vezes, em dois ficheiros diferentes, e o APT (advanced package tool) encontrou ambas as cópias. No Ubuntu 24.04 e posteriores, isto acontece quase sempre porque um script de instalação de terceiros gravou um ficheiro antigo de uma linha .list, enquanto já existia no disco um ficheiro deb822 .sources para o mesmo repositório. Nada está corrompido e nenhum pacote está em risco. Elimine uma das duas declarações e a mensagem desaparece.

Esta é a linha que as pessoas colam numa caixa de pesquisa:

W: Target Packages (stable/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/docker.list:1 and /etc/apt/sources.list.d/docker.sources:1

Leia-a a partir do fim. Dois ficheiros, cada um com um número de linha, declaram a mesma coisa. Target Packages é o índice que o apt descarrega para saber que pacotes um repositório disponibiliza, e stable/binary-amd64/Packages identifica o componente (stable) e a arquitetura (amd64) abrangidos por esse índice. Portanto, o apt está a informar que o índice amd64 do componente stable está configurado em docker.list na linha 1 e novamente em docker.sources na linha 1.

No apt 3.0 e posteriores, ou seja, no Ubuntu 25.04 e posteriores e no Debian 13, a mesma mensagem começa por Warning: em vez de W:. O texto depois do prefixo é igual.

Esse aviso é o caso simples. O apt junta as duas declarações e a atualização continua, porque ambas descrevem o mesmo arquivo com a mesma chave. O caso grave interrompe tudo:

E: Conflicting values set for option Signed-By regarding source https://download.docker.com/linux/ubuntu/ noble: /usr/share/keyrings/docker-archive-keyring.gpg != /etc/apt/keyrings/docker.asc
E: The list of sources could not be read.

O apt recusa-se a continuar neste caso porque as duas declarações indicam chaves de assinatura diferentes para um arquivo. Junta duas declarações idênticas, mas não escolhe entre dois valores Signed-By, porque escolher o valor errado significa verificar as assinaturas dos pacotes com uma chave que o proprietário do arquivo nunca utilizou para assinar. Por isso, o apt não lê nenhuma fonte. apt update e apt install falham ambos com estas mesmas duas linhas até editar os ficheiros manualmente.

Como o duplicado aparece

Os dois formatos ficam em ficheiros separados, com extensões diferentes. Por isso, nada no disco impede que ambos existam. O apt deteta a sobreposição mais tarde, quando expande cada ficheiro de fontes para a lista de destinos de índices que pretende obter. Até esse momento, docker.list e docker.sources são dois ficheiros sem relação entre si.

Quatro eventos comuns produzem este par:

• Um script de instalação do fornecedor, ou um comando copiado de um artigo antigo, grava /etc/apt/sources.list.d/vendor.list com uma linha tee.
• Mais tarde, o pacote do próprio fornecedor disponibiliza /etc/apt/sources.list.d/vendor.sources e instala-o por si.
• add-apt-repository no Ubuntu 24.04 e versões posteriores grava ficheiros deb822 .sources. Assim, um PPA (arquivo de pacotes pessoal) que adicionou manualmente no passado como .list volta a aparecer como .sources.
• Uma atualização de versão converteu as fontes próprias da distribuição para deb822 e deixou o seu ficheiro .list escrito manualmente ao lado delas.

Cada caminho é razoável por si só. O duplicado aparece quando dois deles ocorrem no mesmo sistema, muitas vezes com meses de intervalo.

Os dois formatos, lado a lado

O formato antigo usa uma linha por repositório, e cada parte tem uma posição definida.

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable

A ordem é fixa: o tipo (deb para pacotes binários, deb-src para pacotes-fonte), depois as opções entre parênteses retos, o URI (identificador uniforme de recursos) do arquivo, a suite e, por fim, um ou mais componentes. Como o significado depende da posição, um espaço no local errado altera a forma como o apt interpreta a linha.

O deb822 exprime a mesma informação como um bloco de campos nomeados. O nome vem da RFC 822, o formato de cabeçalhos de e-mail que o Debian já utiliza nos ficheiros de controlo dos pacotes.

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

É o mesmo repositório e a mesma chave, sem qualquer informação adicional. O mapeamento é direto: deb passa a ser Types, o endereço do arquivo passa a ser URIs, a suite passa a ser Suites, os componentes passam a ser Components e cada opção entre parênteses retos passa a ter o seu próprio campo; assim, signed-by= passa a ser Signed-By: e arch= passa a ser Architectures:.

Todos os nomes dos campos estão no plural porque cada campo aceita uma lista de valores separados por espaços. Suites: noble noble-updates noble-backports num bloco substitui três linhas deb separadas. Uma linha em branco termina um bloco, por isso um único ficheiro .sources pode conter vários repositórios. O deb822 também suporta definições que o formato de uma linha trata de forma limitada: Enabled: no para desativar um repositório, Trusted, Check-Valid-Until e uma chave incorporada diretamente em Signed-By, com cada linha indentada por um espaço e as linhas em branco representadas por um único ponto.

Onde cada ficheiro fica

• /etc/apt/sources.list: o ficheiro único original. No Ubuntu 24.04 e versões posteriores, normalmente está vazio ou contém apenas um comentário que aponta para a nova localização.
• /etc/apt/sources.list.d/*.list: entradas de uma linha, normalmente um ficheiro por repositório.
• /etc/apt/sources.list.d/*.sources: blocos deb822. No Ubuntu 24.04 e versões posteriores, os repositórios próprios da distribuição ficam aqui, em ubuntu.sources.
• /etc/apt/keyrings/: local onde devem ficar as chaves que adicionar. /usr/share/keyrings/ contém as chaves provenientes de um pacote.

apt lê apenas ficheiros terminados em .list ou .sources, e o nome do ficheiro pode conter letras, dígitos, sublinhado, hífen e ponto. Um ficheiro com qualquer outra extensão é ignorado com um aviso, o que é importante para a correção apresentada abaixo.

Encontrar o par duplicado

Comece pela listagem do diretório:

ls -l /etc/apt/sources.list.d/

-rw-r--r-- 1 root root  195 Aug  3 09:12 docker.list
-rw-r--r-- 1 root root  254 Aug  9 14:40 docker.sources
-rw-r--r-- 1 root root 2683 Jun 11 08:02 ubuntu.sources

Dois ficheiros com o mesmo nome-base e extensões diferentes são o par mais comum, mas não confie nos nomes. Leia o conteúdo, porque uma duplicação pode estar num ficheiro com qualquer nome:

grep -rn -E '^(deb |deb-src |Types:|URIs:|Suites:|Signed-By:)' /etc/apt/sources.list /etc/apt/sources.list.d/

/etc/apt/sources.list.d/docker.list:1:deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu noble stable
/etc/apt/sources.list.d/docker.sources:1:Types: deb
/etc/apt/sources.list.d/docker.sources:2:URIs: https://download.docker.com/linux/ubuntu
/etc/apt/sources.list.d/docker.sources:3:Suites: noble
/etc/apt/sources.list.d/docker.sources:6:Signed-By: /etc/apt/keyrings/docker.asc

O par é formado pelas duas entradas com o mesmo host e a mesma suite. Ambas apontam para https://download.docker.com/linux/ubuntu e para a suite noble, pelo que representam o mesmo repositório escrito duas vezes. Os caminhos Signed-By também são diferentes, o que produz o erro Conflicting values apresentado anteriormente.

Use grep em vez de um comando apt nesta etapa. Quando o apt já está a parar devido ao conflito, também não consegue listar as fontes. Por isso, apt-cache policy apresenta o mesmo erro, em vez da resposta pretendida.

Corrigir: manter o ficheiro deb822 e remover o ficheiro legado

Mantenha o ficheiro .sources. Este é o formato que as ferramentas do apt escrevem atualmente e é o formato adotado pelo Debian e pelo Ubuntu. Antes de eliminar qualquer ficheiro, verifique qual dos dois caminhos principais existe no disco:

ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker

-rw-r--r-- 1 root root 4813 Aug  9 14:40 docker.asc

Apenas /etc/apt/keyrings/docker.asc está presente. Portanto, o ficheiro deb822 é o que contém a configuração correta, e o ficheiro .list aponta para uma chave que foi removida. Se o ficheiro que pretende manter indicar a chave em falta, copie primeiro para ele o caminho funcional e elimine depois o outro ficheiro.

Retire o ficheiro legado do diretório em vez de o eliminar diretamente:

sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt update

Também pode mudar o nome para docker.list.bak e mantê-lo no mesmo diretório, porque o apt ignora extensões desconhecidas. Nesse caso, porém, cada execução do apt apresenta o seguinte:

N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extension

Mover o ficheiro para outro local evita essa mensagem e mantém a cópia de segurança. Depois, uma situação normal de apt update é semelhante a esta, sem nenhuma linha que indique dois ficheiros:

Hit:1 http://archive.ubuntu.com/ubuntu noble InRelease
Get:2 https://download.docker.com/linux/ubuntu noble InRelease [48.8 kB]
Get:3 http://security.ubuntu.com/ubuntu noble-security InRelease [126 kB]
Fetched 175 kB in 1s (146 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

Agora confirme que o repositório continua configurado corretamente:

apt-cache policy | grep download.docker.com

 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
     origin download.docker.com

Se a documentação de um fornecedor ainda pressupuser o ficheiro de uma linha, pode manter esse ficheiro e eliminar o ficheiro .sources. A regra é sempre a mesma: apenas um ficheiro pode declarar um determinado arquivo e suite.

Por que uma fonte de terceiros com problemas bloqueia o apt update

A falha adjacente parece diferente, mas tem a mesma causa: uma fonte de terceiros que o apt não consegue usar. A primeira versão é uma chave em falta:

Err:5 https://download.docker.com/linux/ubuntu noble InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7EA0A9C3F273FCD8
E: The repository 'https://download.docker.com/linux/ubuntu noble InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.

O campo Signed-By está em falta ou aponta para um ficheiro que não contém uma chave utilizável. Por isso, o apt não consegue verificar a assinatura do ficheiro InRelease do arquivo. Em seguida, rejeita todo esse repositório, em vez de confiar em listas de pacotes que não consegue verificar. Consulte o próprio ficheiro da chave:

ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc

Uma chave válida apresenta uma linha pub com um ID de chave e uma linha uid que identifica o fornecedor. gpg: no valid OpenPGP data found. significa que o ficheiro não é uma chave. Normalmente, isto acontece porque a transferência guardou uma página de erro depois de o URL da chave ter mudado. Transfira novamente a chave, verifique o ficheiro e execute apt update.

A segunda versão surge depois de uma atualização da release:

Err:6 https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky InRelease
  404  Not Found [IP: 10.0.0.80 443]
E: The repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu plucky Release' does not have a Release file.

A PPA não publicou nada para essa suite. Por isso, o caminho não existe no servidor e o pedido devolve 404. Os outros repositórios continuam a ser atualizados e os pacotes que já tem não são alterados. No entanto, a execução termina com um código diferente de zero. Assim, qualquer script que verifique o estado de saída de apt update passa a reportar uma falha sempre que é executado. Por isso, vale a pena remover uma fonte inativa num sistema com atualizações de segurança não supervisionadas configuradas: é no ruído diário que uma falha real fica escondida.

Desativar uma fonte sem afetar as restantes

Num ficheiro deb822, adicione um campo ao bloco de configuração e guarde-o:

Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: no

O manual do apt recomenda este método em vez de comentar cada linha do bloco. Também é mais fácil revertê-lo. Num ficheiro com uma linha, coloque um # no início da linha. Em qualquer dos formatos, também pode mover o ficheiro para fora de /etc/apt/sources.list.d/. Escolha esta opção quando o repositório tiver sido removido definitivamente.

Execute sudo apt update novamente. O bloco Err: desse repositório desaparece e o estado de saída volta a 0. Pode confirmar isso com echo $? na linha seguinte.

Nunca corrija uma fonte danificada com sudo rm /etc/apt/sources.list.d/*. No Ubuntu 24.04 e posteriores, esse comando elimina ubuntu.sources, que contém os repositórios da própria distribuição. O apt fica então sem listas de pacotes e apresenta E: Unable to locate package curl para software que existe claramente. Se já tiver executado esse comando, restaure o ficheiro:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Guarde-o como /etc/apt/sources.list.d/ubuntu.sources, substituindo noble pelo nome da sua própria versão, obtido em lsb_release -cs. Em seguida, execute sudo apt update.

Converter ficheiros .list antigos para deb822

A partir de agosto de 2026, o apt 3.0 e versões posteriores incluem um conversor para este efeito. O Debian 13 inclui-o, tal como o Ubuntu 25.04 e todas as versões posteriores, incluindo a 26.04. Verifique a versão e execute-o:

apt --version
sudo apt modernize-sources

O comando reescreve os ficheiros de uma linha em /etc/apt/sources.list.d/ como ficheiros deb822 .sources. Leia o que é apresentado, liste depois o diretório manualmente e execute apt update antes de confiar no resultado. O Ubuntu 24.04 inclui uma versão mais antiga do apt, sem este subcomando; nessa versão, o comando devolve E: Invalid operation modernize-sources. Nessa versão, faça a conversão manualmente usando o mapeamento de campos acima.

A conversão é opcional atualmente, porque o apt continua a ler ambos os formatos. Vale a pena fazê-la num servidor que pretende manter, porque todas as ferramentas que escrevem fontes de software agora usam deb822, e uma máquina que tenha apenas ficheiros .sources não pode acumular este tipo de duplicado.

Mantenha as fontes de terceiros organizadas num servidor

Os repositórios de terceiros são a parte de um servidor que mais envelhece mal. Cada um representa uma promessa de outra entidade de continuar a publicar pacotes para a sua versão do Ubuntu, e uma atualização de versão testa todas essas promessas na mesma altura.

• Adicione um repositório de terceiros apenas quando o pacote da distribuição não for suficiente. Uma stack LAMP no Ubuntu 24.04 simples não precisa de nenhum: o arquivo do Ubuntu contém todos os pacotes utilizados, com atualizações de segurança durante o ciclo de vida da versão.
• Mantenha as chaves em /etc/apt/keyrings/, um ficheiro por fornecedor, com o modo 644. O utilizador sem privilégios _apt faz o download e precisa de ler a chave. Por isso, um ficheiro de chave legível apenas por root gera um erro de permissões em cada obtenção desse repositório.
• Aponte Signed-By para esse ficheiro exato em cada stanza. Uma chave guardada em /etc/apt/trusted.gpg ou /etc/apt/trusted.gpg.d/ é considerada fidedigna para todos os repositórios do sistema. Isso significa que uma chave de fornecedor adicionada há anos pode validar pacotes de qualquer origem.
• Antes de uma atualização de versão, leia as suas fontes e confirme que cada fornecedor já publica pacotes para a suite de destino.

Uma chave no antigo keyring global fica evidente em cada atualização:

W: https://download.docker.com/linux/ubuntu/dists/noble/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

Exporte essa chave individual para o seu próprio ficheiro e aponte a stanza para esse ficheiro:

gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --export 7EA0A9C3F273FCD8 | sudo tee /etc/apt/keyrings/docker.gpg > /dev/null
sudo chmod 644 /etc/apt/keyrings/docker.gpg

Adicione Signed-By: /etc/apt/keyrings/docker.gpg à stanza do repositório e execute sudo apt update. O aviso deixa de aparecer quando nenhum repositório depender do keyring antigo. Depois, pode remover a entrada com sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8.

Outro hábito evita a maioria dos problemas. do-release-upgrade desativa as fontes de terceiros durante a atualização e deixa-as desativadas depois. Reativá-las manualmente, uma de cada vez, é precisamente quando são criadas declarações duplicadas. Leia o guia de atualização do Ubuntu 24.04 para 26.04 antes de começar e anote os repositórios de que ainda precisa. Numa máquina que acabou de criar, o momento mais barato para corrigir as fontes é durante os primeiros dez minutos num VPS novo, enquanto as únicas entradas no sistema são as fornecidas pelo Ubuntu.

FAQ

Por que o apt informa que um destino está configurado várias vezes?

Isso acontece porque dois ficheiros em /etc/apt/sources.list.d/ declaram o mesmo repositório, suite e componente. A mensagem identifica os dois ficheiros com os números das linhas, como docker.list:1 e docker.sources:1. O apt combina essas definições e continua, portanto a atualização ainda funciona. Mesmo assim, vale a pena eliminar a duplicação: assim que os dois ficheiros indicarem chaves de assinatura diferentes, o apt para com E: Conflicting values set for option Signed-By e recusa ler qualquer fonte, o que também bloqueia apt install.

Devo manter o ficheiro .list ou o ficheiro .sources?

Mantenha o ficheiro .sources. O formato deb822 é o que add-apt-repository grava no Ubuntu 24.04 e versões posteriores. Ele mantém um campo nomeado por definição, em vez de texto posicional entre parênteses retos, e é o formato adotado pelas distribuições. Antes de eliminar o ficheiro .list, confirme, com ls -l /etc/apt/keyrings/, que o caminho Signed-By dentro do ficheiro .sources aponta para uma chave existente. Mova o ficheiro antigo para fora de /etc/apt/sources.list.d/ em vez de o renomear dentro desse diretório, porque um nome .bak deixado no local faz o apt mostrar um aviso sobre ficheiro ignorado em cada execução.

Como desativo um repositório apt sem o remover?

Num ficheiro .sources deb822, adicione Enabled: no à estrofe. Num ficheiro .list de uma linha, coloque um # no início da linha. Em ambos os casos, execute sudo apt update depois, e o bloco Err: desse repositório desaparece. Esta é a opção correta quando um repositório de terceiros ainda não tem pacotes para a sua versão do Ubuntu e o seu erro 404 faz apt update terminar com um código diferente de zero.

O formato de uma linha do sources.list vai deixar de existir?

Está obsoleto, mas não foi removido. O apt continua a ler ficheiros .list e continuará a fazê-lo durante bastante tempo, portanto nada no servidor deixa de funcionar amanhã. As ferramentas novas gravam no formato deb822: o Ubuntu 24.04 e versões posteriores mantêm os repositórios da distribuição em /etc/apt/sources.list.d/ubuntu.sources, e add-apt-repository grava ficheiros .sources. No apt 3.0 e versões posteriores, sudo apt modernize-sources converte os ficheiros que ainda existirem.