Jak naprawić błąd zduplikowanych źródeł w apt

Co oznacza błąd zduplikowanych źródeł apt

Zduplikowane źródła apt oznaczają, że to samo repozytorium zostało zadeklarowane dwukrotnie w dwóch różnych plikach, a narzędzie APT (advanced package tool) wykryło obie kopie. W systemie Ubuntu 24.04 i nowszych sytuacja ta występuje niemal zawsze, gdy skrypt instalacyjny zewnętrznego dostawcy utworzył stary plik w formacie jednowierszowym .list, podczas gdy na dysku istniał już plik w formacie deb822 .sources dla tego samego repozytorium. Żadne dane nie są uszkodzone i żaden pakiet nie jest zagrożony. Należy usunąć jedną z dwóch deklaracji, aby komunikat przestał się pojawiać.

Oto wiersz, który użytkownicy wklejają w wyszukiwarkę:

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

Należy czytać go od końca. Dwa pliki, każdy z numerem wiersza, deklarują to samo. Target Packages to indeks pobierany przez apt, aby sprawdzić, jakie pakiety oferuje repozytorium, a stable/binary-amd64/Packages określa komponent (stable) oraz architekturę (amd64), których dotyczy ten indeks. Zatem apt informuje, że indeks amd64 dla komponentu stable jest skonfigurowany w docker.list w wierszu 1 oraz ponownie w docker.sources w wierszu 1.

W wersji apt 3.0 i nowszych, co dotyczy Ubuntu 25.04 oraz Debian 13, ten sam komunikat rozpoczyna się od Warning: zamiast W:. Tekst po prefiksie pozostaje bez zmian.

To ostrzeżenie jest łagodnym przypadkiem. apt scala obie deklaracje i aktualizacja przebiega pomyślnie, ponieważ oba wpisy opisują to samo archiwum z tym samym kluczem. Przypadek krytyczny zatrzymuje cały proces:

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.

W tym przypadku apt odmawia działania, ponieważ dwie deklaracje wskazują różne klucze podpisu dla tego samego archiwum. Narzędzie scala identyczne deklaracje, ale nie wybierze między dwiema wartościami Signed-By, ponieważ wybór niewłaściwej oznaczałby weryfikację podpisów pakietów kluczem, którym właściciel archiwum nigdy nie podpisywał plików. W rezultacie apt nie odczytuje żadnych źródeł. Polecenia apt update oraz apt install kończą się niepowodzeniem z tymi samymi dwiema liniami błędu, dopóki pliki nie zostaną ręcznie poprawione.

Jak powstaje duplikat

Oba formaty znajdują się w oddzielnych plikach o różnych rozszerzeniach, więc nic na dysku nie blokuje ich jednoczesnego istnienia. apt wykrywa konflikt dopiero w późniejszym etapie, gdy rozwija każdy plik źródłowy do listy celów indeksu, które zamierza pobrać. Do tego momentu docker.list oraz docker.sources są dwoma niezależnymi plikami.

Cztery typowe zdarzenia prowadzą do powstania takiej pary:

• Skrypt instalacyjny dostawcy lub polecenie skopiowane ze starszego poradnika tworzy /etc/apt/sources.list.d/vendor.list z linią tee.
• Własny pakiet dostawcy w późniejszym czasie dostarcza /etc/apt/sources.list.d/vendor.sources i instaluje go w systemie.
• add-apt-repository w systemie Ubuntu 24.04 i nowszych tworzy pliki deb822 .sources, przez co PPA (personal package archive) dodane wcześniej ręcznie jako .list powraca jako .sources.
• Aktualizacja wydania systemu nadpisała własne źródła dystrybucji do formatu deb822, pozostawiając ręcznie utworzony plik .list bez zmian.

Każda z tych ścieżek jest uzasadniona. Duplikat powstaje, gdy dwa z tych zdarzeń wystąpią na tej samej maszynie, często w odstępie wielu miesięcy.

Porównanie obu formatów

Stary format to jedna linia na repozytorium, w której każda część ma ściśle określoną pozycję.

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

Kolejność jest stała: typ (deb dla pakietów binarnych, deb-src dla pakietów źródłowych), następnie opcje w nawiasach kwadratowych, potem URI (uniform resource identifier) archiwum, następnie suite, a na końcu jeden lub więcej komponentów. Ponieważ znaczenie wynika z pozycji, spacja w niewłaściwym miejscu zmienia sposób odczytu danych przez apt.

Format deb822 przedstawia te same informacje w postaci bloku nazwanych pól. Nazwa pochodzi od RFC 822, stylu nagłówków pocztowych, który Debian wykorzystuje już w plikach kontrolnych pakietów.

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

To samo repozytorium, ten sam klucz, brak dodatkowych elementów. Odwzorowanie jest bezpośrednie: deb staje się Types, adres archiwum staje się URIs, suite staje się Suites, komponenty stają się Components, a każda opcja w nawiasach staje się osobnym polem, więc signed-by= staje się Signed-By:, a arch= staje się Architectures:.

Każda nazwa pola jest w liczbie mnogiej, ponieważ każde pole przyjmuje listę rozdzielaną spacjami. Suites: noble noble-updates noble-backports w jednym bloku zastępuje trzy oddzielne linie deb. Pusta linia kończy blok, więc pojedynczy plik .sources może zawierać kilka repozytoriów. Format deb822 obsługuje również ustawienia, z którymi format jednoliniowy radzi sobie słabo: Enabled: no do wyłączenia repozytorium, Trusted, Check-Valid-Until oraz klucz wklejony bezpośrednio w Signed-By, gdzie każda linia jest wcięta o jedną spację, a puste linie są zapisywane jako pojedyncza kropka.

Lokalizacja plików

• /etc/apt/sources.list: oryginalny pojedynczy plik. W systemie Ubuntu 24.04 i nowszych jest zazwyczaj pusty lub zawiera jedynie komentarz wskazujący na nową lokalizację.
• /etc/apt/sources.list.d/*.list: wpisy jednowierszowe, zazwyczaj jeden plik na repozytorium.
• /etc/apt/sources.list.d/*.sources: sekcje w formacie deb822. System Ubuntu 24.04 i nowsze przechowują tutaj własne repozytoria dystrybucji, w pliku ubuntu.sources.
• /etc/apt/keyrings/: miejsce na dodawane klucze. /usr/share/keyrings/ przechowuje klucze dostarczone w pakietach.

Narzędzie apt odczytuje wyłącznie pliki z rozszerzeniem .list lub .sources. Nazwa pliku może zawierać litery, cyfry, znaki podkreślenia, myślniki oraz kropki. Plik z innym rozszerzeniem jest pomijany z odpowiednim powiadomieniem, co ma znaczenie w przypadku poniższej poprawki.

Znajdowanie duplikatu pary

Rozpocznij od wyświetlenia zawartości katalogu:

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

Wspólną parę stanowią dwa pliki o tej samej nazwie bazowej, lecz różnych rozszerzeniach, jednak nie należy polegać wyłącznie na nazwach. Odczytaj zawartość plików, ponieważ duplikat może ukrywać się pod dowolną nazwą:

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

Parę stanowią dwa wpisy o tym samym hoście i tym samym pakiecie. Oba wskazują na https://download.docker.com/linux/ubuntu oraz pakiet noble, co oznacza, że jest to to samo repozytorium zdefiniowane dwukrotnie. Ich ścieżki Signed-By również są rozbieżne, co powoduje błąd Conflicting values wyświetlony wcześniej.

W tym kroku użyj grep zamiast polecenia apt. Gdy apt przerywa działanie z powodu konfliktu, nie może również wyświetlić listy źródeł, dlatego apt-cache policy wypisuje ten sam błąd zamiast oczekiwanej odpowiedzi.

Naprawa: zachowanie pliku deb822 i usunięcie starszego formatu

Zachowaj plik .sources. Jest to format, w którym obecnie zapisują dane narzędzia apt i w tym kierunku zmierzają zarówno Debian, jak i Ubuntu. Przed usunięciem czegokolwiek sprawdź, która z dwóch ścieżek kluczy istnieje na dysku:

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

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

Obecny jest tylko /etc/apt/keyrings/docker.asc, więc to plik deb822 zawiera poprawne informacje, a plik .list wskazuje na klucz, który został usunięty. Jeśli okaże się, że plik, który chcesz zachować, wskazuje na brakujący klucz, najpierw skopiuj do niego działającą ścieżkę, a następnie usuń drugi plik.

Przenieś starszy plik poza katalog, zamiast go od razu usuwać:

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

Zmiana nazwy na docker.list.bak i pozostawienie pliku w tym samym miejscu również zadziała, ponieważ apt ignoruje nieznane rozszerzenia, jednak przy każdym uruchomieniu apt pojawi się następujący komunikat:

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

Przeniesienie pliku w inne miejsce eliminuje ten komunikat z ekranu, zachowując jednocześnie kopię zapasową. Poprawny wynik apt update po tej operacji wygląda następująco, bez linii wskazującej na dwa pliki:

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.

Teraz potwierdź, że repozytorium przetrwało edycję:

apt-cache policy | grep download.docker.com

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

Jeśli dokumentacja dostawcy nadal zakłada użycie pliku jednowierszowego, możesz zachować ten plik, a usunąć plik .sources. Obowiązuje jedna zasada: dokładnie jeden plik może deklarować dane archiwum i zestaw (suite).

Dlaczego jedno uszkodzone źródło zewnętrzne blokuje apt update

Sąsiednia awaria wygląda inaczej, ale ma to samo źródło: zewnętrzny zasób, którego apt nie może użyć. Pierwszy wariant to brakujący klucz:

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.

Pole Signed-By jest puste lub wskazuje na plik, który nie jest poprawnym kluczem, więc apt nie może zweryfikować podpisu pliku InRelease archiwum. W rezultacie odrzuca całe repozytorium, zamiast ufać listom pakietów, których nie może sprawdzić. Należy sprawdzić sam plik klucza:

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

Działający klucz wyświetla linię pub z identyfikatorem klucza oraz linię uid z nazwą dostawcy. gpg: no valid OpenPGP data found. oznacza, że plik w ogóle nie jest kluczem, co zazwyczaj wynika z pobrania strony błędu zamiast pliku, ponieważ adres URL klucza uległ zmianie. Należy ponownie pobrać klucz, sprawdzić plik, a następnie uruchomić apt update.

Drugi wariant pojawia się po aktualizacji wydania systemu:

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.

PPA nie opublikowało żadnych pakietów dla tej wersji systemu, więc ścieżka nie istnieje na serwerze, a żądanie zwraca błąd 404. Pozostałe repozytoria nadal się aktualizują, a zainstalowane pakiety pozostają nienaruszone. Proces kończy się jednak kodem wyjścia różnym od zera, więc każdy skrypt sprawdzający status wyjścia apt update będzie teraz zgłaszał błąd przy każdym uruchomieniu. Dlatego warto usuwać martwe źródła na serwerach z skonfigurowanymi automatycznymi aktualizacjami bezpieczeństwa: w codziennych komunikatach o błędach łatwo przeoczyć rzeczywistą awarię.

Wyłączanie jednego źródła bez wpływu na pozostałe

W przypadku pliku w formacie deb822 należy dodać jedno pole do sekcji i zapisać zmiany:

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

Podręcznik apt zaleca to rozwiązanie zamiast komentowania każdej linii sekcji, ponieważ jest ono łatwiejsze do cofnięcia. W przypadku pliku jednowierszowego należy umieścić # na początku linii. Dla obu formatów skuteczne jest również przeniesienie pliku poza katalog /etc/apt/sources.list.d/; jest to opcja zalecana, gdy repozytorium nie będzie już używane.

Ponownie uruchom sudo apt update. Blok Err: dla tego repozytorium zniknie, a kod wyjścia powróci do wartości 0, co można sprawdzić za pomocą echo $? w następnej linii.

Nigdy nie naprawiaj uszkodzonego źródła za pomocą sudo rm /etc/apt/sources.list.d/*. W systemie Ubuntu 24.04 i nowszych polecenie to usuwa plik ubuntu.sources, który zawiera domyślne repozytoria dystrybucji. W rezultacie apt pozostaje bez list pakietów i zgłasza E: Unable to locate package curl dla oprogramowania, które jest dostępne. Jeśli polecenie zostało już wykonane, należy przywrócić plik:

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

Zapisz powyższą treść jako /etc/apt/sources.list.d/ubuntu.sources, zastępując noble nazwą własnego wydania z pliku lsb_release -cs, a następnie uruchom sudo apt update.

Konwersja starszych plików .list do formatu deb822

Od sierpnia 2026 roku apt w wersji 3.0 i nowszych zawiera konwerter tego formatu. Jest on dostępny w Debian 13, Ubuntu 25.04 oraz wszystkich późniejszych wydaniach, w tym 26.04. Należy sprawdzić wersję, a następnie wykonać polecenie:

apt --version
sudo apt modernize-sources

Narzędzie to przepisuje jednowierszowe pliki z katalogu /etc/apt/sources.list.d/ na pliki deb822 w formacie .sources. Należy zapoznać się z wyjściem polecenia, sprawdzić zawartość katalogu i wykonać apt update przed uznaniem wyniku za poprawny. Ubuntu 24.04 zawiera starszą wersję apt bez tego podpolecenia, w związku z czym system zwróci E: Invalid operation modernize-sources. W tym wydaniu konwersję należy przeprowadzić ręcznie, korzystając z powyższego mapowania pól.

Konwersja jest obecnie opcjonalna, ponieważ apt nadal obsługuje oba formaty. Warto ją jednak przeprowadzić na serwerach utrzymywanych długoterminowo, ponieważ wszystkie narzędzia zapisujące źródła oprogramowania używają już formatu deb822, a system zawierający wyłącznie pliki .sources eliminuje ryzyko powstawania duplikatów tego typu.

Utrzymywanie porządku w zewnętrznych źródłach oprogramowania na serwerze

Zewnętrzne repozytoria to element serwera, który starzeje się najszybciej. Każde z nich stanowi obietnicę zewnętrznego dostawcy dotyczącą utrzymywania publikacji dla konkretnego wydania Ubuntu, a aktualizacja dystrybucji weryfikuje wszystkie te obietnice w tym samym czasie.

• Dodawaj zewnętrzne repozytorium tylko wtedy, gdy pakiet dystrybucyjny nie spełnia wymagań. Standardowy stos LAMP na Ubuntu 24.04 nie wymaga żadnego z nich: archiwum Ubuntu zawiera wszystkie niezbędne pakiety wraz z aktualizacjami bezpieczeństwa przez cały okres wsparcia wydania.
• Przechowuj klucze w /etc/apt/keyrings/, po jednym pliku na dostawcę, z uprawnieniami 644. Nieuprzywilejowany użytkownik _apt odpowiada za pobieranie i musi mieć możliwość odczytu klucza, dlatego plik klucza dostępny tylko dla root spowoduje błąd uprawnień przy każdym pobieraniu z danego repozytorium.
• Wskaż Signed-By na konkretny plik w każdej sekcji konfiguracji. Klucz znajdujący się w /etc/apt/trusted.gpg lub /etc/apt/trusted.gpg.d/ jest uznawany za zaufany dla każdego repozytorium w systemie, co oznacza, że klucz dostawcy dodany przed laty może autoryzować pakiety z dowolnego źródła.
• Przed aktualizacją wydania przejrzyj źródła i sprawdź, czy każdy dostawca publikuje już pakiety dla wersji, do której migrujesz.

Klucz w starym globalnym zbiorze kluczy zgłasza się przy każdej aktualizacji:

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.

Wyeksportuj ten pojedynczy klucz do osobnego pliku, a następnie wskaż go w sekcji konfiguracji:

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

Dodaj Signed-By: /etc/apt/keyrings/docker.gpg do sekcji repozytorium i uruchom sudo apt update. Ostrzeżenie zniknie, gdy żadne repozytorium nie będzie już korzystać ze starego zbioru kluczy, co pozwoli na usunięcie wpisu za pomocą sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8.

Jeszcze jeden nawyk pozwala uniknąć największych problemów. do-release-upgrade wyłącza zewnętrzne źródła na czas aktualizacji i pozostawia je wyłączone po jej zakończeniu, a ręczne włączanie ich pojedynczo to najczęstsza przyczyna powstawania zduplikowanych deklaracji. Przeczytaj przewodnik aktualizacji Ubuntu 24.04 do 26.04 przed rozpoczęciem prac i zanotuj, które repozytoria są nadal potrzebne. Na świeżo zainstalowanej maszynie najlepszym momentem na uporządkowanie źródeł jest pierwsze dziesięć minut na nowym VPS, gdy jedyne wpisy w systemie to te dostarczone przez Ubuntu.

FAQ

Dlaczego apt zgłasza, że cel jest skonfigurowany wielokrotnie?

Ponieważ dwa pliki w /etc/apt/sources.list.d/ deklarują to samo repozytorium, dystrybucję i komponent. Komunikat wskazuje oba pliki wraz z numerami linii, na przykład docker.list:1 oraz docker.sources:1. apt scala te wpisy i kontynuuje działanie, więc sama aktualizacja przebiega poprawnie. Duplikat warto jednak usunąć: gdy tylko pliki wskażą różne klucze podpisu, apt zatrzyma się z błędem E: Conflicting values set for option Signed-By i odmówi odczytu jakiegokolwiek źródła, co zablokuje również apt install.

Czy zachować plik .list czy plik .sources?

Należy zachować plik .sources. Format deb822 jest używany przez add-apt-repository w systemie Ubuntu 24.04 i nowszych; zawiera on nazwane pola dla każdego ustawienia zamiast tekstu pozycyjnego w nawiasach kwadratowych i stanowi standard, w stronę którego zmierzają dystrybucje. Przed usunięciem pliku .list należy potwierdzić za pomocą ls -l /etc/apt/keyrings/, czy ścieżka Signed-By wewnątrz pliku .sources wskazuje na istniejący klucz. Stary plik należy przenieść poza /etc/apt/sources.list.d/ zamiast zmieniać jego nazwę wewnątrz tego katalogu, ponieważ pozostawienie pliku z rozszerzeniem .bak spowoduje, że apt będzie wyświetlać powiadomienie o ignorowanym pliku przy każdym uruchomieniu.

Jak wyłączyć repozytorium apt bez jego usuwania?

W pliku .sources w formacie deb822 należy dodać wpis Enabled: no do sekcji. W pliku .list w formacie jednowierszowym należy umieścić znak # na początku linii. W obu przypadkach po tej operacji należy wykonać sudo apt update, a blok Err: dla danego repozytorium zniknie. Jest to właściwe rozwiązanie, gdy repozytorium zewnętrznego dostawcy nie posiada jeszcze pakietów dla używanej wersji Ubuntu, a błąd 404 powoduje, że apt update kończy pracę z kodem wyjścia innym niż zero.

Czy format jednowierszowy sources.list zostanie wycofany?

Jest on przestarzały, ale nie usunięty. apt nadal odczytuje pliki .list i będzie to robić przez długi czas, więc konfiguracja serwera pozostanie sprawna. Nowe narzędzia zapisują dane w formacie deb822: Ubuntu 24.04 i nowsze przechowują repozytoria dystrybucyjne w /etc/apt/sources.list.d/ubuntu.sources, a add-apt-repository tworzy pliki .sources. W wersji apt 3.0 i nowszych polecenie sudo apt modernize-sources umożliwia konwersję posiadanych plików.