Come correggere le sorgenti apt duplicate

Che cosa significa l'errore relativo alle sorgenti apt duplicate

Le sorgenti apt duplicate indicano che un repository è dichiarato due volte, in due file diversi, e che APT (advanced package tool) ha trovato entrambe le copie. In Ubuntu 24.04 e versioni successive, questo accade quasi sempre perché uno script di installazione di terze parti ha creato un vecchio file .list nel formato a una riga, mentre sul disco esisteva già un file .sources in formato deb822 per lo stesso repository. Non ci sono dati corrotti e nessun pacchetto è a rischio. Elimina una delle due dichiarazioni e il messaggio scompare.

Questa è la riga che spesso viene incollata in una casella di ricerca:

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

Leggila dalla fine. Due file, ciascuno con un numero di riga, dichiarano la stessa cosa. Target Packages è l'indice che apt scarica per sapere quali pacchetti offre un repository, mentre stable/binary-amd64/Packages indica il componente (stable) e l'architettura (amd64) coperti da quell'indice. Quindi apt sta dicendo che l'indice amd64 per il componente stable è configurato in docker.list alla riga 1 e nuovamente in docker.sources alla riga 1.

In apt 3.0 e versioni successive, cioè da Ubuntu 25.04 in poi e in Debian 13, lo stesso messaggio inizia con Warning: invece di W:. Il testo dopo il prefisso è identico.

Questo avviso rappresenta il caso meno grave. apt unisce le due dichiarazioni e l'aggiornamento continua, perché entrambe descrivono lo stesso archivio con la stessa chiave. Il caso grave interrompe tutto:

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.

In questo caso apt rifiuta di procedere perché le due dichiarazioni indicano chiavi di firma diverse per uno stesso archivio. Unisce due dichiarazioni identiche, ma non sceglie tra due valori Signed-By, perché scegliere quello sbagliato significa verificare le firme dei pacchetti con una chiave che il proprietario dell'archivio non ha mai usato per firmarli. Di conseguenza, apt non legge alcuna sorgente. apt update e apt install falliscono entrambi con le stesse due righe finché non modifichi manualmente i file.

Come si crea il duplicato

I due formati si trovano in file separati con estensioni diverse, quindi nulla nel filesystem impedisce che entrambi esistano. apt rileva la sovrapposizione solo in un secondo momento, quando espande ogni file delle sorgenti nell'elenco degli indici che prevede di scaricare. Fino a quel momento docker.list e docker.sources sono due file distinti e indipendenti.

La coppia viene creata da quattro eventi comuni:

• Uno script di installazione del fornitore, oppure un comando copiato da un articolo meno recente, scrive /etc/apt/sources.list.d/vendor.list con una riga tee.
• In seguito, il pacchetto del fornitore installa /etc/apt/sources.list.d/vendor.sources.
• add-apt-repository su Ubuntu 24.04 e versioni successive scrive file deb822 .sources, quindi un PPA (archivio personale di pacchetti) aggiunto manualmente in precedenza come .list ricompare come .sources.
• Un aggiornamento di versione converte le sorgenti della distribuzione nel formato deb822 e lascia invariato il file .list creato manualmente, accanto agli altri.

Ogni percorso è ragionevole preso singolarmente. Il duplicato si verifica quando due di questi eventi avvengono sullo stesso server, spesso a distanza di mesi.

I due formati, a confronto

Il formato precedente usa una riga per repository e ogni parte ha una posizione fissa.

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

L’ordine è fisso: il tipo (deb per i pacchetti binari, deb-src per i pacchetti sorgente), quindi le opzioni tra parentesi quadre, poi l’URI (uniform resource identifier) dell’archivio, quindi la suite e infine uno o più componenti. Poiché il significato dipende dalla posizione, uno spazio nel punto sbagliato modifica ciò che apt interpreta.

deb822 esprime le stesse informazioni tramite uno stanza composta da campi denominati. Il nome deriva da RFC 822, lo stile degli header delle email già utilizzato da Debian per i file di controllo dei pacchetti.

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

Stesso repository, stessa chiave, senza aggiunte. La corrispondenza è diretta: deb diventa Types, l’indirizzo dell’archivio diventa URIs, la suite diventa Suites, i componenti diventano Components e ogni opzione tra parentesi quadre diventa un campo distinto; quindi signed-by= diventa Signed-By: e arch= diventa Architectures:.

Ogni nome di campo è al plurale perché ogni campo accetta un elenco separato da spazi. Suites: noble noble-updates noble-backports in una stanza sostituisce tre righe deb distinte. Una riga vuota termina una stanza, quindi un singolo file .sources può contenere più repository. deb822 gestisce inoltre impostazioni che il formato a riga singola tratta con difficoltà: Enabled: no per disabilitare un repository, Trusted, Check-Valid-Until e una chiave inline inserita direttamente in Signed-By, con ogni riga rientrata di uno spazio e le righe vuote rappresentate da un singolo punto.

Dove si trova ogni file

• /etc/apt/sources.list: il file singolo originale. In Ubuntu 24.04 e versioni successive è normalmente vuoto oppure contiene solo un commento che indica la nuova posizione.
• /etc/apt/sources.list.d/*.list: voci su una riga, normalmente un file per repository.
• /etc/apt/sources.list.d/*.sources: blocchi deb822. Ubuntu 24.04 e versioni successive conserva qui i repository della distribuzione, in ubuntu.sources.
• /etc/apt/keyrings/: la directory in cui vanno inserite le chiavi aggiunte dall’amministratore. /usr/share/keyrings/ contiene le chiavi installate da un pacchetto.

apt legge solo i file che terminano con .list o .sources. Il nome del file può contenere lettere, cifre, carattere di sottolineatura, trattino e punto. Un file con qualsiasi altra estensione viene ignorato e apt visualizza una notifica. Questo comportamento è importante per la correzione descritta di seguito.

Individuare la coppia duplicata

Inizia dall'elenco della directory:

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

Due file con lo stesso nome di base e con estensioni diverse costituiscono la coppia più comune, ma non fidarti dei nomi. Leggi il contenuto dei file, perché una voce duplicata può trovarsi in un file con un nome qualsiasi:

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

La coppia è costituita dalle due voci con lo stesso host e la stessa suite. Entrambe puntano a https://download.docker.com/linux/ubuntu e alla suite noble, quindi sono lo stesso repository definito due volte. Anche i relativi percorsi Signed-By non coincidono; questo genera l'errore Conflicting values mostrato in precedenza.

Per questo passaggio usa grep invece di un comando apt. Quando apt si interrompe già a causa del conflitto, non può nemmeno elencare le sorgenti; di conseguenza apt-cache policy stampa lo stesso errore invece della risposta cercata.

Correggere il problema: mantenere il file deb822 e rimuovere quello legacy

Mantieni il file .sources. È il formato che gli strumenti di apt scrivono oggi ed è il formato verso cui si stanno orientando sia Debian sia Ubuntu. Prima di eliminare qualsiasi file, verifica quale dei due percorsi principali esiste sul 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

È presente solo /etc/apt/keyrings/docker.asc. Il file deb822 contiene quindi la configurazione corretta, mentre il file .list fa riferimento a una chiave che è stata rimossa. Se il file che intendi mantenere indica la chiave mancante, copia prima al suo interno il percorso funzionante, quindi elimina l'altro file.

Sposta il file legacy fuori dalla directory invece di eliminarlo direttamente:

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

Rinominarlo in docker.list.bak e lasciarlo nella directory funziona comunque, perché apt ignora le estensioni sconosciute. Tuttavia, ogni esecuzione di apt stampa questo messaggio:

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

Spostando il file altrove, il messaggio non viene più mostrato e il backup resta disponibile. Dopo l'operazione, un file apt update valido ha questo aspetto, senza alcuna riga che indichi due file:

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.

Ora verifica che il repository sia ancora disponibile dopo la modifica:

apt-cache policy | grep download.docker.com

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

Se la documentazione del fornitore presuppone ancora il file con una sola riga, puoi mantenere quello ed eliminare invece il file .sources. La regola è una sola: un determinato archivio e una determinata suite possono essere dichiarati da un solo file.

Perché una sola sorgente di terze parti non valida blocca apt update

Il problema adiacente ha un aspetto diverso, ma la causa è la stessa: una sorgente di terze parti che apt non può usare. Nel primo caso manca una chiave:

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.

Il campo Signed-By manca oppure punta a un file che non contiene una chiave utilizzabile. Di conseguenza, apt non può verificare la firma del file InRelease dell'archivio. Scarta quindi l'intero repository, invece di considerare attendibili liste di pacchetti che non può verificare. Controlla direttamente il file della chiave:

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

Una chiave valida stampa una riga pub con l'ID della chiave e una riga uid con il nome del fornitore. gpg: no valid OpenPGP data found. indica che il file non è affatto una chiave. Di solito significa che il download ha salvato una pagina di errore perché l'URL della chiave è cambiato. Scarica di nuovo la chiave, controlla il file, quindi esegui apt update.

Il secondo caso si verifica dopo un aggiornamento della 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.

Il PPA non ha pubblicato nulla per quella suite. Il percorso quindi non esiste sul server e la richiesta restituisce 404. Gli altri repository continuano ad aggiornarsi e i pacchetti già installati non vengono modificati. Tuttavia, l'esecuzione termina con un codice diverso da zero. Di conseguenza, ogni script che controlla lo stato di uscita di apt update segnala un errore ogni volta che viene eseguito. Per questo conviene rimuovere una sorgente non più disponibile su un server con aggiornamenti di sicurezza automatici configurati: è nel rumore quotidiano che può nascondersi un errore reale.

Disabilitare una sorgente senza compromettere le altre

Per un file deb822, aggiungi un campo alla stanza e salva il file:

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

Il manuale di apt raccomanda questo metodo invece di commentare ogni riga della stanza, ed è più semplice da annullare. Per un file composto da una sola riga, inserisci un # all'inizio della riga. Per entrambi i formati, puoi anche spostare il file fuori da /etc/apt/sources.list.d/. Scegli questa opzione quando il repository non esiste più definitivamente.

Esegui di nuovo sudo apt update. Il blocco Err: relativo a quel repository scompare e lo stato di uscita torna a 0. Puoi verificarlo con echo $? nella riga successiva.

Non correggere mai una sorgente non funzionante con sudo rm /etc/apt/sources.list.d/*. In Ubuntu 24.04 e versioni successive, questo comando elimina ubuntu.sources, che contiene i repository della distribuzione. Di conseguenza, apt non dispone più di alcun elenco di pacchetti e restituisce E: Unable to locate package curl per software che esiste chiaramente. Se hai già eseguito il comando, riscrivi il file:

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

Salva il contenuto come /etc/apt/sources.list.d/ubuntu.sources, sostituendo noble con il nome della tua release ottenuto da lsb_release -cs, quindi esegui sudo apt update.

Convertire i file legacy .list nel formato deb822

Da agosto 2026, apt 3.0 e versioni successive includono un convertitore dedicato. È disponibile in Debian 13 e in Ubuntu 25.04 e in tutte le versioni successive, inclusa la 26.04. Verificate la versione, quindi eseguite:

apt --version
sudo apt modernize-sources

Il comando riscrive i file composti da una sola riga presenti in /etc/apt/sources.list.d/ come file .sources nel formato deb822. Leggete l'output, quindi elencate manualmente la directory ed eseguite apt update prima di considerare valido il risultato. Ubuntu 24.04 include una versione precedente di apt che non dispone di questo sottocomando; in quella versione il comando restituisce E: Invalid operation modernize-sources. Su questa versione, eseguite la conversione manualmente usando la mappatura dei campi precedente.

Oggi la conversione è facoltativa, perché apt continua a leggere entrambi i formati. È consigliabile eseguirla su un server che intendete mantenere, poiché tutti gli strumenti che scrivono le sorgenti usano ora il formato deb822 e un sistema che contiene soltanto file .sources non può generare questo tipo di duplicato.

Mantieni in ordine le sorgenti di terze parti su un server

I repository di terze parti sono la parte di un server che invecchia peggio. Ognuno rappresenta l'impegno di un soggetto esterno a continuare a pubblicare pacchetti per la tua release di Ubuntu, e un aggiornamento della release mette alla prova tutti questi impegni nello stesso momento.

• Aggiungi un repository di terze parti solo quando il pacchetto della distribuzione non è sufficiente. Un semplice stack LAMP su Ubuntu 24.04 non ne richiede alcuno: l'archivio Ubuntu contiene tutti i pacchetti utilizzati, con aggiornamenti di sicurezza per l'intero ciclo di vita della release.
• Conserva le chiavi in /etc/apt/keyrings/, un file per ogni vendor, con modalità 644. L'utente non privilegiato _apt scarica i pacchetti e deve poter leggere la chiave; se il file della chiave è leggibile solo da root, ogni recupero da quel repository termina con un errore di autorizzazione.
• Indica Signed-By a quel file preciso in ogni stanza. Una chiave presente in /etc/apt/trusted.gpg o /etc/apt/trusted.gpg.d/ è considerata attendibile per tutti i repository del server. Di conseguenza, una chiave del vendor aggiunta anni prima può convalidare pacchetti provenienti da qualsiasi sorgente.
• Prima di un aggiornamento della release, leggi le sorgenti configurate e verifica che ogni vendor pubblichi già pacchetti per la suite a cui vuoi passare.

Una chiave nel vecchio keyring globale si manifesta a ogni aggiornamento:

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.

Esporta quella singola chiave in un file dedicato, quindi indica il file nella stanza:

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

Aggiungi Signed-By: /etc/apt/keyrings/docker.gpg alla stanza del repository ed esegui sudo apt update. L'avviso scompare quando nessun repository dipende più dal vecchio keyring; a quel punto puoi rimuovere la voce con sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8.

Un'ultima abitudine evita la maggior parte dei problemi. do-release-upgrade disabilita le sorgenti di terze parti durante l'aggiornamento e le lascia disabilitate anche dopo. Riattivarle manualmente, una alla volta, è proprio il punto in cui vengono create dichiarazioni duplicate. Leggi la guida all'aggiornamento da Ubuntu 24.04 a 26.04 prima di iniziare e annota quali repository ti servono ancora. Su una macchina appena installata, il momento meno costoso per configurare correttamente le sorgenti è durante i primi dieci minuti su un nuovo VPS, quando nel server sono presenti solo le voci fornite da Ubuntu.

FAQ

Perché apt indica che una destinazione è configurata più volte?

Perché due file in /etc/apt/sources.list.d/ dichiarano lo stesso repository, suite e componente. Il messaggio indica entrambi i file con i numeri di riga, ad esempio docker.list:1 e docker.sources:1. apt li unisce e continua, quindi l'aggiornamento funziona comunque. È comunque opportuno eliminare il duplicato: se i due file indicano chiavi di firma diverse, apt si interrompe con E: Conflicting values set for option Signed-By e rifiuta di leggere qualsiasi sorgente. Questo blocca anche apt install.

Devo mantenere il file .list o il file .sources?

Mantieni il file .sources. deb822 è il formato utilizzato da add-apt-repository su Ubuntu 24.04 e versioni successive. Contiene un campo denominato per ogni impostazione, invece di testo posizionale tra parentesi quadre, ed è il formato verso cui si stanno orientando le distribuzioni. Prima di eliminare il file .list, verifica con ls -l /etc/apt/keyrings/ che il percorso Signed-By contenuto nel file .sources punti a una chiave esistente. Sposta il vecchio file fuori da /etc/apt/sources.list.d/ invece di rinominarlo nella directory, perché un nome residuo .bak fa stampare ad apt un avviso relativo a un file ignorato a ogni esecuzione.

Come disattivo un repository apt senza rimuoverlo?

In un file .sources deb822, aggiungi Enabled: no allo stanza. In un file .list su una sola riga, inserisci un # all'inizio della riga. In entrambi i casi, esegui sudo apt update. In questo modo il blocco Err: relativo a quel repository scompare. È la scelta corretta quando un repository di terze parti non offre ancora pacchetti per la tua versione di Ubuntu e il relativo errore 404 fa terminare apt update con un codice diverso da zero.

Il formato sources.list su una sola riga verrà rimosso?

È deprecato, ma non è stato rimosso. apt continua a leggere i file .list e lo farà ancora a lungo, quindi il tuo server non smetterà di funzionare domani. I nuovi strumenti scrivono in formato deb822: Ubuntu 24.04 e versioni successive mantengono i repository della distribuzione in /etc/apt/sources.list.d/ubuntu.sources e add-apt-repository scrive file .sources. Con apt 3.0 e versioni successive, sudo apt modernize-sources converte i file ancora presenti.