Doppelte apt-Quellen und deb822-Dateien beheben

Was der Fehler wegen doppelter apt-Quellen bedeutet

Doppelte apt-Quellen bedeuten, dass ein Repository zweimal in zwei verschiedenen Dateien definiert ist und APT (advanced package tool) beide Kopien gefunden hat. Unter Ubuntu 24.04 und neuer passiert das fast immer, weil ein Installationsskript eines Drittanbieters eine alte einzeilige .list-Datei geschrieben hat, während eine deb822-.sources-Datei für dasselbe Repository bereits vorhanden war. Es ist nichts beschädigt, und kein Paket ist gefährdet. Löschen Sie eine der beiden Definitionen. Dann verschwindet die Meldung.

Diese Zeile fügen viele Benutzer in ein Suchfeld ein:

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

Lesen Sie die Zeile vom Ende her. Zwei Dateien definieren mit Angabe der jeweiligen Zeilennummer dasselbe. Target Packages ist der Index, den apt herunterlädt, um zu erfahren, welche Pakete ein Repository anbietet. stable/binary-amd64/Packages bezeichnet die Komponente (stable) und die Architektur (amd64), für die dieser Index gilt. apt teilt Ihnen also mit, dass der amd64-Index für die Komponente stable in docker.list in Zeile 1 konfiguriert ist und nochmals in docker.sources in Zeile 1.

In apt 3.0 und neuer, also ab Ubuntu 25.04 und unter Debian 13, beginnt dieselbe Meldung mit Warning: statt mit W:. Der Text nach dem Präfix ist identisch.

Diese Warnung ist der unkritische Fall. apt führt die beiden Definitionen zusammen, und das Update läuft weiterhin, weil beide dasselbe Archiv mit demselben Schlüssel beschreiben. Der kritische Fall bricht den gesamten Vorgang ab:

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.

apt verweigert den Vorgang hier, weil die beiden Definitionen für ein Archiv unterschiedliche Signaturschlüssel angeben. Identische Definitionen führt apt zusammen. Zwischen zwei Signed-By-Werten wählt apt jedoch nicht, weil bei einer falschen Auswahl die Paketsignaturen mit einem Schlüssel geprüft würden, mit dem der Betreiber des Archivs sie nie signiert hat. Deshalb liest apt überhaupt keine Quellen ein. apt update und apt install schlagen beide mit denselben zwei Zeilen fehl, bis Sie die Dateien manuell bearbeiten.

So entsteht der doppelte Eintrag

Die beiden Formate befinden sich in separaten Dateien mit unterschiedlichen Erweiterungen. Daher verhindert nichts auf dem Datenträger, dass beide gleichzeitig vorhanden sind. apt erkennt die Überschneidung erst spät, wenn es jede Quelldatei in die Liste der Indexziele auflöst, die abgerufen werden sollen. Bis dahin sind docker.list und docker.sources zwei voneinander unabhängige Dateien.

Vier gewöhnliche Ereignisse erzeugen dieses Paar:

• Ein Installationsskript des Anbieters oder ein aus einem älteren Beitrag kopierter Befehl schreibt /etc/apt/sources.list.d/vendor.list mit einer tee-Zeile.
• Das eigene Paket des Anbieters liefert später /etc/apt/sources.list.d/vendor.sources aus und installiert es automatisch.
• add-apt-repository schreibt unter Ubuntu 24.04 und neuer deb822-.sources-Dateien. Dadurch erscheint ein PPA (Personal Package Archive), das Sie früher manuell als .list hinzugefügt hatten, erneut als .sources.
• Ein Release-Upgrade schreibt die eigenen Paketquellen der Distribution in das deb822-Format um und lässt Ihre selbst erstellte .list-Datei unverändert daneben bestehen.

Jeder dieser Wege ist für sich genommen plausibel. Der doppelte Eintrag entsteht, wenn zwei davon auf demselben System auftreten, häufig im Abstand von mehreren Monaten.

Die beiden Formate im Vergleich

Das alte Format verwendet eine Zeile pro Repository. Jeder Bestandteil steht an einer festen Position.

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

Die Reihenfolge ist festgelegt: zuerst der Typ (deb für Binärpakete, deb-src für Quellpakete), dann die Optionen in eckigen Klammern, anschließend der URI (Uniform Resource Identifier) des Archivs, die Suite und danach eine oder mehrere Komponenten. Da die Bedeutung von der Position abhängt, verändert bereits ein Leerzeichen an der falschen Stelle, wie apt den Eintrag interpretiert.

deb822 beschreibt dasselbe als Abschnitt mit benannten Feldern. Die Bezeichnung stammt aus RFC 822, dem Format für Mail-Header, das Debian bereits für Paketsteuerungsdateien verwendet.

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

Dasselbe Repository, derselbe Schlüssel, nichts wurde hinzugefügt. Die Zuordnung ist direkt: deb wird zu Types, die Archivadresse wird zu URIs, die Suite wird zu Suites, die Komponenten werden zu Components, und jede Option in eckigen Klammern erhält ein eigenes Feld. Dadurch wird signed-by= zu Signed-By: und arch= zu Architectures:.

Jeder Feldname steht im Plural, weil jedes Feld eine durch Leerzeichen getrennte Liste aufnimmt. Suites: noble noble-updates noble-backports in einem Abschnitt ersetzt drei separate deb-Zeilen. Eine Leerzeile beendet einen Abschnitt. Daher kann eine einzelne .sources-Datei mehrere Repositories enthalten. deb822 unterstützt außerdem Einstellungen, die sich im einzeiligen Format nur schlecht darstellen lassen: Enabled: no zum Deaktivieren eines Repositorys, Trusted, Check-Valid-Until sowie einen direkt in Signed-By eingefügten Schlüssel. Dabei muss jede Zeile um ein Leerzeichen eingerückt werden, und Leerzeilen werden als einzelner Punkt geschrieben.

Wo die einzelnen Dateien liegen

• /etc/apt/sources.list: die ursprüngliche Einzeldatei. Unter Ubuntu 24.04 und neuer ist sie normalerweise leer oder enthält nur einen Kommentar, der auf den neuen Speicherort verweist.
• /etc/apt/sources.list.d/*.list: Einträge mit jeweils einer Zeile, normalerweise eine Datei pro Repository.
• /etc/apt/sources.list.d/*.sources: deb822-Abschnitte. Ubuntu 24.04 und neuer speichert die eigenen Repositories der Distribution hier in ubuntu.sources.
• /etc/apt/keyrings/: Hier gehören die von Ihnen hinzugefügten Schlüssel hin. /usr/share/keyrings/ enthält Schlüssel, die aus einem Paket stammen.

apt liest nur Dateien, die auf .list oder .sources enden. Ein Dateiname darf Buchstaben, Ziffern, Unterstrich, Bindestrich und Punkt enthalten. Eine Datei mit einer anderen Endung wird mit einem Hinweis übersprungen. Das ist für die folgende Korrektur relevant.

Das doppelte Paar finden

Beginnen Sie mit der Verzeichnisauflistung:

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

Zwei Dateien mit demselben Stammnamen und unterschiedlichen Erweiterungen bilden häufig das Paar. Verlassen Sie sich jedoch nicht auf die Dateinamen. Lesen Sie den Inhalt, denn ein Duplikat kann sich in einer beliebig benannten Datei befinden:

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

Das Paar besteht aus den beiden Einträgen mit demselben Host und derselben Suite. Beide verweisen auf https://download.docker.com/linux/ubuntu und die Suite noble. Damit ist dasselbe Repository zweimal eingetragen. Auch ihre Signed-By-Pfade unterscheiden sich. Dadurch entsteht der zuvor angezeigte Fehler Conflicting values.

Verwenden Sie für diesen Schritt grep statt eines apt-Befehls. Wenn apt wegen des Konflikts bereits abbricht, kann apt Ihre Paketquellen ebenfalls nicht auflisten. apt-cache policy gibt dann denselben Fehler aus, statt die gewünschte Antwort zu liefern.

Fehlerbehebung: Die deb822-Datei behalten und die Legacy-Datei entfernen

Behalten Sie die .sources-Datei. Dies ist das Format, in das apt-Tools inzwischen schreiben, und Debian sowie Ubuntu entwickeln sich beide in diese Richtung. Prüfen Sie vor dem Löschen, welcher der beiden relevanten Pfade auf dem Datenträger vorhanden ist:

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

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

Nur /etc/apt/keyrings/docker.asc ist vorhanden. Damit enthält die deb822-Datei den korrekten Eintrag, während die .list-Datei auf einen entfernten Schlüssel verweist. Falls die Datei, die Sie behalten möchten, den fehlenden Schlüssel angibt, tragen Sie zuerst den funktionierenden Pfad in diese Datei ein. Löschen Sie anschließend die andere Datei.

Verschieben Sie die Legacy-Datei aus dem Verzeichnis, anstatt sie direkt zu löschen:

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

Sie können sie auch in docker.list.bak umbenennen und an ihrem Platz lassen, da apt unbekannte Dateierweiterungen ignoriert. Dann gibt jedoch jeder apt-Aufruf Folgendes aus:

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

Wenn Sie die Datei an einen anderen Ort verschieben, erscheint diese Meldung nicht mehr. Gleichzeitig bleibt die Sicherung erhalten. Ein gültiges apt update sieht anschließend so aus, ohne eine Zeile, in der zwei Dateien genannt werden:

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.

Prüfen Sie nun, ob das Repository die Änderung weiterhin korrekt verarbeitet:

apt-cache policy | grep download.docker.com

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

Falls die Dokumentation eines Anbieters weiterhin von der Datei mit einer einzelnen Zeile ausgeht, können Sie diese Datei behalten und stattdessen die .sources-Datei löschen. Es gilt in beiden Fällen dieselbe Regel: Genau eine Datei darf ein bestimmtes Archiv und eine bestimmte Suite deklarieren.

Warum eine fehlerhafte Quelle eines Drittanbieters apt update blockiert

Der benachbarte Fehler sieht anders aus, hat aber dieselbe Ursache: eine Quelle eines Drittanbieters, die apt nicht verwenden kann. Die erste Variante ist ein fehlender Schlüssel:

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.

Das Feld Signed-By fehlt oder verweist auf eine Datei, die keinen gültigen Schlüssel enthält. Deshalb kann apt die Signatur der Datei InRelease des Archivs nicht prüfen. Die Quelle wird dann vollständig verworfen, anstatt nicht überprüfbaren Paketlisten zu vertrauen. Prüfen Sie die Schlüsseldatei selbst:

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

Ein funktionierender Schlüssel gibt eine Zeile pub mit einer Schlüssel-ID und eine Zeile uid mit dem Namen des Anbieters aus. gpg: no valid OpenPGP data found. bedeutet, dass die Datei überhaupt kein Schlüssel ist. Meist wurde eine Fehlerseite gespeichert, weil sich die URL des Schlüssels geändert hat. Rufen Sie den Schlüssel erneut ab, prüfen Sie die Datei und führen Sie anschließend apt update aus.

Die zweite Variante tritt nach einem Release-Upgrade auf:

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.

Das PPA hat für diese Suite nichts veröffentlicht. Deshalb existiert der Pfad auf dem Server nicht, und die Anfrage liefert 404 zurück. Ihre anderen Repositorys werden weiterhin aktualisiert. Bereits installierte Pakete bleiben unverändert. Der Lauf endet jedoch mit einem Status ungleich 0. Daher meldet jedes Skript, das den Exit-Status von apt update prüft, bei jeder Ausführung einen Fehler. Deshalb sollten Sie eine nicht mehr erreichbare Quelle auf einem System mit konfigurierten unbeaufsichtigten Sicherheitsupdates entfernen: In den täglichen Meldungen kann sich sonst ein echter Fehler verbergen.

Eine Quelle deaktivieren, ohne den Rest zu beeinträchtigen

Fügen Sie bei einer deb822-Datei ein Feld zum Abschnitt hinzu und speichern Sie die Datei:

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

Das apt-Handbuch empfiehlt diese Vorgehensweise, anstatt jede Zeile des Abschnitts auszukommentieren. Außerdem lässt sie sich leichter rückgängig machen. Bei einer einzeiligen Datei setzen Sie # an den Zeilenanfang. Bei beiden Formaten funktioniert es auch, die Datei aus /etc/apt/sources.list.d/ zu verschieben. Diese Option sollten Sie wählen, wenn das Repository dauerhaft entfernt wurde.

Führen Sie sudo apt update erneut aus. Der Err:-Block für dieses Repository wird nicht mehr angezeigt. Der Exit-Status ist wieder 0. Sie können ihn in der nächsten Zeile mit echo $? prüfen.

Beheben Sie eine fehlerhafte Quelle niemals mit sudo rm /etc/apt/sources.list.d/*. Unter Ubuntu 24.04 und neuer wird dadurch ubuntu.sources gelöscht. Diese Datei enthält die Repositorys der Distribution. apt hat dann überhaupt keine Paketlisten mehr und meldet für Software, die offensichtlich vorhanden ist, E: Unable to locate package curl. Wenn Sie den Befehl bereits ausgeführt haben, stellen Sie die Datei wieder her:

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

Speichern Sie diese Datei als /etc/apt/sources.list.d/ubuntu.sources. Ersetzen Sie noble durch den Namen Ihres eigenen Releases aus lsb_release -cs. Führen Sie anschließend sudo apt update aus.

Legacy-.list-Dateien in deb822 konvertieren

Ab August 2026 enthalten apt 3.0 und neuere Versionen einen Konverter dafür. Debian 13 enthält ihn ebenfalls, ebenso Ubuntu 25.04 und alle danach veröffentlichten Versionen, einschließlich 26.04. Prüfen Sie die Version und führen Sie den Konverter anschließend aus:

apt --version
sudo apt modernize-sources

Der Befehl schreibt die einzeiligen Dateien unter /etc/apt/sources.list.d/ als deb822-.sources-Dateien neu. Lesen Sie die Ausgabe, listen Sie anschließend das Verzeichnis selbst auf und führen Sie apt update aus, bevor Sie dem Ergebnis vertrauen. Ubuntu 24.04 enthält eine ältere apt-Version ohne dieses Unterkommando. Dort antwortet der Befehl mit E: Invalid operation modernize-sources. Konvertieren Sie die Dateien in dieser Version anhand der oben beschriebenen Feldzuordnung manuell.

Die Konvertierung ist derzeit optional, da apt weiterhin beide Formate liest. Auf einem Server, den Sie dauerhaft betreiben möchten, ist sie dennoch sinnvoll. Jedes Tool, das inzwischen Paketquellen schreibt, verwendet deb822. Ein System mit ausschließlich .sources-Dateien kann diese Art von Duplikat nicht mehr erzeugen.

Drittanbieterquellen auf einem Server übersichtlich halten

Drittanbieter-Repositorys gehören zu den Bestandteilen eines Servers, die am schnellsten veralten. Jedes Repository ist ein Versprechen eines anderen Anbieters, weiterhin Pakete für Ihre Ubuntu-Version zu veröffentlichen. Bei einem Release-Upgrade wird jedes dieser Versprechen am selben Nachmittag geprüft.

• Fügen Sie ein Drittanbieter-Repository nur hinzu, wenn das Distributionspaket nicht ausreicht. Ein einfacher LAMP-Stack auf Ubuntu 24.04 benötigt keines: Das Ubuntu-Archiv enthält jedes verwendete Paket und stellt während der gesamten Laufzeit des Releases Security Updates bereit.
• Bewahren Sie Schlüssel in /etc/apt/keyrings/ auf, jeweils eine Datei pro Anbieter und mit dem Modus 644. Der unprivilegierte Benutzer _apt lädt die Daten herunter und muss den Schlüssel lesen können. Eine nur für root lesbare Schlüsseldatei verursacht bei jedem Abruf aus diesem Repository einen Berechtigungsfehler.
• Verweisen Sie in jedem Eintrag mit Signed-By auf genau diese Datei. Ein Schlüssel in /etc/apt/trusted.gpg oder /etc/apt/trusted.gpg.d/ gilt für jedes Repository auf dem System als vertrauenswürdig. Dadurch kann ein vor Jahren hinzugefügter Anbieterschlüssel Pakete aus beliebigen Quellen validieren.
• Lesen Sie vor einem Release-Upgrade Ihre Quellen und prüfen Sie, ob jeder Anbieter bereits Pakete für die Ziel-Suite veröffentlicht.

Ein Schlüssel im alten globalen Keyring macht sich bei jedem Update bemerkbar:

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.

Exportieren Sie diesen einzelnen Schlüssel in eine eigene Datei und verweisen Sie anschließend im Eintrag darauf:

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

Fügen Sie Signed-By: /etc/apt/keyrings/docker.gpg zum Repository-Eintrag hinzu und führen Sie sudo apt update aus. Die Warnung verschwindet, sobald kein Repository mehr vom alten Keyring abhängt. Danach können Sie den Eintrag mit sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 entfernen.

Eine weitere Gewohnheit erspart den meisten Aufwand. do-release-upgrade deaktiviert Drittanbieterquellen für das Upgrade und lässt sie anschließend deaktiviert. Wenn Sie sie danach manuell einzeln wieder aktivieren, entstehen genau dabei häufig doppelte Einträge. Lesen Sie vor dem Start den Upgrade-Leitfaden für Ubuntu 24.04 auf 26.04 und notieren Sie, welche Repositorys Sie weiterhin benötigen. Auf einem gerade erst eingerichteten System ist der günstigste Zeitpunkt für eine korrekte Quellenkonfiguration während der ersten zehn Minuten auf einem neuen VPS, solange sich nur die von Ubuntu ausgelieferten Einträge auf dem System befinden.

FAQ

Warum meldet apt, dass ein Ziel mehrfach konfiguriert ist?

Zwei Dateien unter /etc/apt/sources.list.d/ deklarieren dasselbe Repository, dieselbe Suite und dieselbe Komponente. Die Meldung nennt beide Dateien mit Zeilennummern, beispielsweise docker.list:1 und docker.sources:1. apt führt die Angaben zusammen und arbeitet weiter. Das Update selbst funktioniert daher weiterhin. Die doppelte Definition sollte trotzdem entfernt werden: Sobald die beiden Dateien unterschiedliche Signatur-Keys angeben, bricht apt mit E: Conflicting values set for option Signed-By ab und verweigert das Einlesen sämtlicher Paketquellen. Dadurch ist auch apt install blockiert.

Sollte ich die .list-Datei oder die .sources-Datei behalten?

Behalten Sie die .sources-Datei. deb822 wird von add-apt-repository unter Ubuntu 24.04 und neuer verwendet. Das Format enthält für jede Einstellung ein benanntes Feld statt positionsabhängigem Text in eckigen Klammern und entspricht der zukünftigen Ausrichtung der Distributionen. Bevor Sie die .list-Datei löschen, prüfen Sie mit ls -l /etc/apt/keyrings/, ob der Signed-By-Pfad in der .sources-Datei auf einen vorhandenen Key verweist. Verschieben Sie die alte Datei aus /etc/apt/sources.list.d/ heraus, anstatt sie innerhalb des Verzeichnisses umzubenennen. Ein verbliebener .bak-Name führt sonst bei jedem Aufruf zu einer Meldung über eine ignorierte Datei.

Wie deaktiviere ich ein apt-Repository, ohne es zu entfernen?

Fügen Sie in einer deb822-.sources-Datei Enabled: no zum Abschnitt hinzu. Setzen Sie in einer einzeiligen .list-Datei am Anfang der Zeile ein #. Führen Sie anschließend sudo apt update aus. Danach verschwindet der Err:-Block für dieses Repository. Das ist die richtige Vorgehensweise, wenn ein Repository eines Drittanbieters noch keine Pakete für Ihre Ubuntu-Version bereitstellt und der dadurch verursachte 404-Fehler apt update mit einem Fehlerstatus ungleich 0 beendet.

Wird das einzeilige sources.list-Format abgeschafft?

Es ist veraltet, wurde aber nicht entfernt. apt liest .list-Dateien weiterhin und wird dies noch lange tun. Daher fällt auf Ihrem Server nicht sofort etwas aus. Neue Werkzeuge schreiben deb822: Ubuntu 24.04 und neuer verwalten die Distributions-Repositorys in /etc/apt/sources.list.d/ubuntu.sources, und add-apt-repository schreibt .sources-Dateien. Unter apt 3.0 und neuer konvertiert sudo apt modernize-sources die noch vorhandenen Dateien.