Come risolvere le sorgenti apt duplicate

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. Su Ubuntu 24.04 e versioni successive, questo accade quasi sempre perché uno script di installazione di terze parti ha creato un vecchio file a riga singola .list, mentre sul disco era già presente un file .sources in formato deb822 per lo stesso repository. Non c'è alcuna corruzione e nessun pacchetto è a rischio. Eliminate una delle due dichiarazioni e il messaggio scomparirà.

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

Leggetela 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; stable/binary-amd64/Packages indica il componente (stable) e l'architettura (amd64) coperti da quell'indice. Quindi apt segnala che l'indice amd64 per il componente stable è configurato in docker.list alla riga 1 e di nuovo 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 viene comunque eseguito, perché entrambe descrivono lo stesso archivio con la stessa chiave. Il caso grave interrompe l'intera operazione:

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 errato significherebbe verificare le firme dei pacchetti con una chiave con cui il proprietario dell'archivio non li ha mai firmati. Di conseguenza, apt non legge alcuna sorgente. apt update e apt install falliscono entrambi con le stesse due righe finché non modificate manualmente i file.

Come si crea il duplicato

I due formati si trovano in file separati con estensioni diverse, quindi nulla sul disco impedisce che esistano entrambi. apt rileva la sovrapposizione solo in una fase successiva, quando espande ogni file delle sorgenti nell'elenco delle destinazioni degli indici che intende scaricare. Fino a quel momento, docker.list e docker.sources sono due file indipendenti.

Quattro eventi comuni producono questa coppia:

• Uno script di installazione del fornitore, oppure un comando copiato da un articolo precedente, 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 .sources in formato deb822, quindi una PPA (personal package archive) aggiunta manualmente in precedenza come .list ricompare come .sources.
• Un aggiornamento di versione riscrive le sorgenti della distribuzione nel formato deb822 e lascia intatto il file .list scritto manualmente, accanto agli altri.

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

I due formati, a confronto

Il formato precedente usa una riga per repository e ogni elemento ha una posizione definita.

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, l’URI (uniform resource identifier) dell’archivio, la suite e uno o più componenti. Poiché il significato dipende dalla posizione, uno spazio nel punto sbagliato cambia il modo in cui apt interpreta la riga.

deb822 esprime le stesse informazioni tramite uno stanza con campi denominati. Il nome deriva da RFC 822, lo stile degli header di posta che Debian usa già 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

Lo stesso repository, la 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 separato; quindi signed-by= diventa Signed-By: e arch= diventa Architectures:.

Ogni nome di campo è al plurale perché ogni campo accetta un elenco di valori separati da spazi. Suites: noble noble-updates noble-backports in una stanza sostituisce tre righe deb separate. Una riga vuota termina una stanza, quindi un singolo file .sources può contenere più repository. deb822 gestisce anche impostazioni che il formato su una riga gestisce male: Enabled: no per disabilitare un repository, Trusted, Check-Valid-Until e una chiave inline incollata direttamente in Signed-By, con ogni riga indentata di uno spazio e le righe vuote rappresentate da un singolo punto.

Dove si trova ogni file

• /etc/apt/sources.list: il file originale unico. In Ubuntu 24.04 e versioni successive di solito è vuoto oppure contiene solo un commento che rimanda alla nuova posizione.
• /etc/apt/sources.list.d/*.list: voci su una sola riga, normalmente un file per repository.
• /etc/apt/sources.list.d/*.sources: blocchi deb822. Ubuntu 24.04 e versioni successive mantengono qui i repository propri della distribuzione, in ubuntu.sources.
• /etc/apt/keyrings/: la directory in cui inserire 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 un'estensione diversa viene ignorato e apt visualizza un avviso. Questo aspetto è 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

La coppia comune è formata da due file con lo stesso nome di base e un'estensione diversa, ma non fidarti dei nomi. Leggi il contenuto dei file, perché un duplicato 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 rappresentano lo stesso repository scritto 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 arresta già a causa del conflitto, non può elencare neppure le sorgenti; di conseguenza apt-cache policy stampa lo stesso errore invece della risposta che cerchi.

Correzione: mantenere il file deb822 e rimuovere quello legacy

Mantenere il file .sources. È il formato che gli strumenti di apt scrivono attualmente ed è il formato verso cui stanno convergendo Debian e Ubuntu. Prima di eliminare qualsiasi file, verificare 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 soltanto /etc/apt/keyrings/docker.asc. Il file deb822 è quindi quello corretto e il file .list punta a una chiave che è stata rimossa. Se il file che si intende mantenere indica la chiave mancante, copiarvi prima il percorso funzionante, quindi eliminare l'altro file.

Spostare 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. In questo caso, però, ogni esecuzione di apt stampa:

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

Spostare il file in un'altra posizione evita che l'avviso venga mostrato e conserva comunque il backup. In seguito, un file apt update corretto sarà simile al seguente e non conterrà alcuna riga che nomina 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 verificare 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 composto da una sola riga, è possibile mantenere quello e rimuovere invece il file .sources. La regola è la stessa in entrambi i casi: un determinato archivio e suite possono essere dichiarati in un solo file.

Perché una 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ò utilizzare. Il primo caso riguarda una chiave mancante:

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 è mancante 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 usare elenchi 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 che indica il fornitore. gpg: no valid OpenPGP data found. significa che il file non contiene affatto una chiave. Di solito questo accade perché il download ha salvato una pagina di errore dopo lo spostamento dell'URL della chiave. Scarica nuovamente 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 a ogni esecuzione. Per questo conviene rimuovere una sorgente non più valida su un sistema con aggiornamenti di sicurezza automatici configurati: è nel rumore quotidiano che può nascondersi un errore reale. Gli script di installazione dei fornitori possono incorrere in entrambi i casi. Per questo, la maggior parte degli errori di installazione di Tailscale su Ubuntu dipende da un keyring che lo script non ha mai scritto oppure da un codename della release che l'archivio non supporta.

Disabilitare una sorgente senza compromettere le altre

Per un file deb822, aggiungi un campo alla stanza e salvalo:

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 consiglia questa soluzione invece di commentare ogni riga della stanza, ed è più semplice da annullare. Per un file di una sola riga, inserisci # 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 è stato rimosso 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. apt rimane quindi senza alcun elenco di pacchetti e restituisce E: Unable to locate package curl per software che esiste. Se hai già eseguito il comando, ripristina 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 file come /etc/apt/sources.list.d/ubuntu.sources, sostituendo noble con il nome della tua release, ricavato da lsb_release -cs, quindi esegui sudo apt update.

Converti i file .list legacy nel formato deb822

A partire da agosto 2026, apt 3.0 e versioni successive includono un convertitore per questa operazione. Debian 13 lo include, così come Ubuntu 25.04 e tutte le versioni successive, inclusa la 26.04. Controlla la versione, quindi esegui:

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 deb822 .sources. Leggi l'output, quindi elenca personalmente la directory ed esegui apt update prima di considerare affidabile 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 quella release, esegui manualmente la conversione usando la mappatura dei campi riportata sopra.

La conversione è oggi facoltativa, perché apt continua a leggere entrambi i formati. È comunque consigliabile eseguirla su un server che prevedi di mantenere, poiché tutti gli strumenti che scrivono le sorgenti usano ormai il formato deb822. Un sistema che contiene solo file .sources non può introdurre questo tipo di duplicato.

Mantenere in ordine le sorgenti di terze parti su un server

I repository di terze parti sono la parte del server che tende a invecchiare peggio. Ognuno rappresenta l'impegno di un soggetto esterno a continuare a pubblicare pacchetti per la vostra release di Ubuntu, e un aggiornamento della release verifica tutti questi impegni nello stesso momento.

• Aggiungete un repository di terze parti solo quando il pacchetto della distribuzione non è sufficiente. Un semplice stack LAMP su Ubuntu 24.04 non ne richiede nessuno: l'archivio Ubuntu contiene tutti i pacchetti utilizzati, con aggiornamenti di sicurezza per l'intero ciclo di vita della release.
• Conservate le chiavi in /etc/apt/keyrings/, un file per ogni vendor, con modalità 644. L'utente senza privilegi _apt scarica i pacchetti e deve poter leggere la chiave; se il file della chiave è leggibile solo da root, ogni download da quel repository genera un errore di autorizzazione.
• Indicate Signed-By sul file esatto in ogni stanza. Una chiave presente in /etc/apt/trusted.gpg o /etc/apt/trusted.gpg.d/ è considerata attendibile per ogni repository del server. Questo significa che una chiave del vendor aggiunta anni prima può convalidare pacchetti provenienti da qualsiasi repository.
• Prima di aggiornare la release, leggete le sorgenti e verificate che ogni vendor pubblichi già pacchetti per la suite di destinazione.

Una chiave presente nel vecchio portachiavi globale viene utilizzata per 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.

Esportate quella singola chiave in un file dedicato, quindi indicate 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

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

Un'ultima abitudine evita i problemi più gravi. 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 momento in cui vengono create dichiarazioni duplicate. Leggete la guida all'aggiornamento da Ubuntu 24.04 a 26.04 prima di iniziare e annotate quali repository vi servono ancora. Su una macchina appena configurata, il momento meno costoso per sistemare le sorgenti è durante i primi dieci minuti su un nuovo VPS, quando le uniche voci presenti sul server sono quelle fornite da Ubuntu.

FAQ

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

Perché due file nella directory /etc/apt/sources.list.d/ dichiarano lo stesso repository, la stessa suite e lo stesso 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 prosegue, quindi l'aggiornamento funziona comunque. È comunque opportuno rimuovere il duplicato: non appena i due file indicano chiavi di firma diverse, apt si arresta con E: Conflicting values set for option Signed-By e rifiuta di leggere qualsiasi sorgente, bloccando anche apt install.

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

Mantieni il file .sources. deb822 è il formato che add-apt-repository scrive in Ubuntu 24.04 e versioni successive. Contiene un campo con nome 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 nel file .sources punti a una chiave esistente. Sposta il vecchio file fuori da /etc/apt/sources.list.d/ invece di rinominarlo all'interno della directory, perché un nome .bak residuo fa stampare ad apt un avviso relativo a un file ignorato a ogni esecuzione.

Come posso disattivare un repository apt senza rimuoverlo?

In un file deb822 .sources, aggiungi Enabled: no alla stanza. In un file .list a riga singola, inserisci un # all'inizio della riga. In entrambi i casi, esegui successivamente sudo apt update: il blocco Err: relativo a quel repository scompare. È la soluzione corretta quando un repository di terze parti non dispone ancora di pacchetti per la tua release di Ubuntu e il relativo errore 404 fa terminare apt update con un codice diverso da zero.

Il formato a riga singola di sources.list verrà eliminato?

È deprecato, non rimosso. apt legge ancora i file .list e continuerà a farlo a lungo, quindi il 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, mentre add-apt-repository scrive file .sources. In apt 3.0 e versioni successive, sudo apt modernize-sources converte i file ancora presenti.