Como corrigir fontes APT duplicadas e ficheiros .sources

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 versões posteriores, isto quase sempre acontece porque um script de instalação de terceiros escreveu um ficheiro antigo de uma linha .list, embora já existisse 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 para que a mensagem desapareça.

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 versões posteriores, ou seja, a partir do Ubuntu 25.04 e no Debian 13, a mesma mensagem começa com Warning: em vez de W:. O texto depois do prefixo é igual.

Esse aviso é o caso menos grave. O apt combina 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.

Neste caso, o apt recusa continuar porque as duas declarações indicam chaves de assinatura diferentes para um único arquivo. O apt combina duas declarações idênticas, mas não escolhe entre dois valores Signed-By, porque escolher o valor errado faria a validação das assinaturas dos pacotes contra uma chave que o proprietário do arquivo nunca usou para assinar. Por isso, o apt não lê nenhuma fonte. apt update e apt install falham com as 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 tarde, quando expande cada ficheiro de fontes para a lista de destinos de índices que pretende transferir. 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 de um fornecedor, ou um comando copiado de uma publicação antiga, escreve /etc/apt/sources.list.d/vendor.list com uma linha tee.
• Mais tarde, o próprio pacote do fornecedor disponibiliza /etc/apt/sources.list.d/vendor.sources e instala-o por si.
• add-apt-repository no Ubuntu 24.04 e posteriores escreve ficheiros .sources em formato deb822, por isso uma PPA (arquivo pessoal de pacotes) que adicionou manualmente no passado como .list reaparece como .sources.
• Uma atualização da versão reescreveu as próprias fontes da distribuição em formato deb822 e deixou o seu ficheiro .list criado manualmente intacto ao lado delas.

Cada caminho é razoável por si só. O duplicado surge quando dois deles acontecem 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 (uniform resource identifier) 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 entrada.

O deb822 representa a mesma informação como um bloco de campos nomeados. O nome vem da RFC 822, o formato de cabeçalhos de correio que o Debian já usa 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, a mesma chave, sem nada acrescentado. O mapeamento é direto: deb torna-se Types, o endereço do arquivo torna-se URIs, a suite torna-se Suites, os componentes tornam-se Components e cada opção entre parênteses retos torna-se o seu próprio campo; assim, signed-by= torna-se Signed-By: e arch= torna-se Architectures:.

Todos os nomes de campos estão no plural porque cada campo aceita uma lista separada 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 permite definir opções que o formato de uma linha trata mal: Enabled: no para desativar um repositório, Trusted, Check-Valid-Until e uma chave incorporada colada diretamente em Signed-By, com cada linha indentada por um espaço e as linhas em branco escritas como 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. O Ubuntu 24.04 e versões posteriores mantêm aqui os repositórios da própria distribuição, em ubuntu.sources.
• /etc/apt/keyrings/: local onde devem ficar as chaves adicionadas por si. /usr/share/keyrings/ contém as chaves provenientes de um pacote.

apt lê apenas ficheiros que terminam 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 é relevante para a correção apresentada abaixo.

Identificar 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 habitual, mas não confie nos nomes. Leia o conteúdo, porque uma duplicação pode estar escondida 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, portanto são o mesmo repositório escrito duas vezes. Os caminhos Signed-By também são diferentes, o que produz o erro Conflicting values mostrado 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.

Corrija o problema: mantenha o ficheiro deb822 e remova 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, em seguida, elimine o outro ficheiro.

Mova o ficheiro legado para fora 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 deixá-lo no mesmo diretório, porque o apt ignora extensões desconhecidas. Nesse caso, 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 remove esse aviso do ecrã e mantém a cópia de segurança. Depois da alteração, um apt update correto tem este aspeto, 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 funcional depois da alteração:

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 é a mesma em qualquer caso: exatamente um ficheiro pode declarar um determinado arquivo e suite.

Por que uma fonte de terceiros interrompe o apt update

A falha seguinte parece diferente, mas tem a mesma causa: uma fonte de terceiros que o apt não consegue usar. A primeira versão resulta de 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, descarta 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 funcional apresenta uma linha pub com um ID de chave e uma linha uid com o nome do fornecedor. gpg: no valid OpenPGP data found. significa que o ficheiro não é uma chave. Normalmente, isso acontece porque a transferência guardou uma página de erro depois de o URL da chave ter mudado. Transfira a chave novamente, 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 já instalados 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 indicar uma falha sempre que é executado. É por isso que 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. Os scripts de instalação dos fornecedores encontram ambas as versões deste problema. Por isso, a maioria dos erros de instalação do Tailscale no Ubuntu acaba por resultar de um keyring que o script nunca escreveu ou de um codename de release que o arquivo não disponibiliza.

Desativar uma fonte sem afetar as restantes

Num ficheiro deb822, adicione um campo ao bloco 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, e é mais fácil revertê-lo. Num ficheiro de 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 ser 0. Pode confirmar isso com echo $? na linha seguinte.

Nunca corrija uma fonte com problemas usando 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 quaisquer listas de pacotes e comunica E: Unable to locate package curl para software que existe claramente. Se já executou esse comando, reponha 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. Depois execute sudo apt update.

Converter ficheiros .list legados para deb822

A partir de agosto de 2026, o apt 3.0 e versões posteriores incluem um conversor para este fim. 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 conversor reescreve os ficheiros de uma linha em /etc/apt/sources.list.d/ como ficheiros deb822 .sources. Leia o que o comando apresentar, liste 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 esse subcomando, e nesse caso o comando responde E: Invalid operation modernize-sources. Nessa versão, faça a conversão manualmente usando o mapeamento de campos acima.

A conversão é opcional por enquanto, porque o apt continua a ler ambos os formatos. Ainda assim, vale a pena fazê-la num servidor que pretende manter, porque todas as ferramentas que escrevem fontes utilizam agora deb822, e um sistema que contenha apenas ficheiros .sources não pode acumular este tipo de duplicado.

Mantenha as fontes de terceiros organizadas no servidor

Os repositórios de terceiros são a parte de um servidor que mais envelhece mal. Cada um é 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 tarde.

• 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 todo 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 confiável para todos os repositórios do servidor. 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 fontes configuradas e confirme que cada fornecedor já publica pacotes para a suite de destino.

Uma chave no keyring global antigo é apresentada em todas as atualizações:

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 isolada 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 desaparece 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 o ponto em que 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 configurar, o momento mais simples para corrigir as fontes é durante os primeiros dez minutos num VPS novo, enquanto as únicas entradas no servidor são as fornecidas pelo Ubuntu.

FAQ

Porque é que o apt indica que um destino está configurado várias vezes?

Porque existem dois ficheiros em /etc/apt/sources.list.d/ que 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 funde as entradas e continua, por isso a atualização continua a funcionar. Ainda 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 origem, o que também bloqueia apt install.

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

Mantenha o ficheiro .sources. O formato deb822 é utilizado pelo add-apt-repository no Ubuntu 24.04 e posteriores. Contém um campo com nome para cada 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/, se 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 residual faz com que o apt apresente um aviso sobre ficheiro ignorado em cada execução.

Como desativo um repositório apt sem o remover?

Num ficheiro deb822 .sources, 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. 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 respetivo erro 404 faz com que apt update termine com um código diferente de zero.

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

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