著者 aptの重複ソースエラーを解決する方法
apt updateの「Target is configured multiple times」警告を解決します。Ubuntu 24.04以降で増えた.listとdeb822の.sourcesを特定し、片方だけ残して正常な更新に戻す手順です。
重複した apt ソースエラーの意味
重複した apt ソースとは、1 つのリポジトリが 2 つの異なるファイルで 2 回定義され、APT (advanced package tool) が両方を検出した状態です。Ubuntu 24.04 以降では、同じリポジトリ用の deb822 .sources ファイルがすでに存在するのに、サードパーティーのインストールスクリプトが古い 1 行形式の .list ファイルを書き込んだことが原因である場合がほとんどです。ファイルが壊れているわけではなく、パッケージが危険にさらされているわけでもありません。2 つの定義のどちらかを削除すれば、メッセージは表示されなくなります。
検索ボックスに貼り付けるのは、次の行です。
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末尾から読みます。2 つのファイルが、それぞれ行番号付きで同じ内容を定義しています。Target Packages は、リポジトリが提供するパッケージを確認するために apt がダウンロードするインデックスです。stable/binary-amd64/Packages は、そのインデックスが対象とするコンポーネント (stable) とアーキテクチャ (amd64) を示します。つまり apt は、stable コンポーネントの amd64 インデックスが docker.list の 1 行目で設定され、docker.sources の 1 行目でも設定されていると通知しています。
apt 3.0 以降、つまり Ubuntu 25.04 以降および Debian 13 では、同じメッセージが W: ではなく Warning: で始まります。プレフィックスの後のテキストは同じです。
この警告は軽微なケースです。2 つの定義が同じアーカイブと同じ鍵を示しているため、apt は両方を統合し、update も実行されます。重大なケースでは、処理全体が停止します。
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.この場合、2 つの定義が 1 つのアーカイブに対して異なる署名鍵を指定しているため、apt は処理を拒否します。apt は同一の定義を統合できますが、2 つの Signed-By のどちらを選ぶこともありません。誤った鍵を選ぶと、アーカイブの所有者が署名に使用していない鍵でパッケージ署名を検証することになるためです。そのため、apt はソースをまったく読み込みません。ファイルを手動で編集するまで、apt update と apt install は同じ 2 行を示して失敗します。
重複が発生する経緯
2 つの形式は拡張子が異なる別々のファイルに保存されるため、ディスク上で両方が存在することを妨げるものはありません。apt は、取得対象として計画しているインデックスの一覧にすべてのソースファイルを展開する段階で、初めて重複に気付きます。それまでは、docker.list と docker.sources は互いに無関係な 2 つのファイルです。
通常、次の 4 つの出来事によってこの組み合わせが発生します。
- ベンダーのインストールスクリプト、または古い記事からコピーしたコマンドが、
tee行を含む/etc/apt/sources.list.d/vendor.listを書き込みます。 - その後、ベンダー独自のパッケージが
/etc/apt/sources.list.d/vendor.sourcesをリリースし、自動的にインストールします。 - Ubuntu 24.04 以降では、
add-apt-repositoryが deb822 形式の.sourcesファイルを書き込むため、以前に.listとして手動で追加した PPA (personal package archive) が.sourcesとして再び現れます。 - リリースアップグレードによってディストリビューション独自のソースが deb822 形式に書き換えられますが、手書きの
.listファイルはそのまま残り、隣に共存します。
それぞれの経緯は単独では妥当です。同じホストで 2 つが発生すると、重複が生じます。多くの場合、発生する時期は数か月ずれます。
2 つの形式を並べて比較する
従来の形式はリポジトリごとに 1 行で記述し、各要素の意味が位置で決まります。
deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable順序は固定されています。最初にタイプ（バイナリパッケージの場合は deb、ソースパッケージの場合は deb-src）、次に角括弧内のオプション、その後にアーカイブの URI（uniform resource identifier）、suite、1 つ以上の component を記述します。意味が位置で決まるため、スペースの位置を誤ると apt が読み取る内容が変わります。
deb822 では、同じ内容を名前付きフィールドの stanza として記述します。この名前は RFC 822 に由来します。RFC 822 は、Debian がパッケージの control file にすでに使用しているメールヘッダー形式です。
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc同じリポジトリで、同じ鍵を使用しており、追加される内容はありません。対応関係は直接的です。deb は Types に、アーカイブアドレスは URIs に、suite は Suites に、component は Components になります。また、角括弧内の各オプションは個別のフィールドになるため、signed-by= は Signed-By: に、arch= は Architectures: になります。
すべてのフィールド名が複数形なのは、各フィールドがスペース区切りのリストを受け取るためです。1 つの stanza にある Suites: noble noble-updates noble-backports は、3 行の個別の deb を置き換えます。空行で stanza が終了するため、1 つの .sources ファイルに複数のリポジトリを記述できます。deb822 では、1 行形式では扱いにくい設定も記述できます。たとえば、リポジトリを無効にする Enabled: no、Trusted、Check-Valid-Until、さらに Signed-By に直接貼り付ける inline key です。inline key の各行は 1 つのスペースでインデントし、空行は単独のドットとして記述します。
各ファイルの場所
/etc/apt/sources.list: 以前から使われている単一のファイルです。Ubuntu 24.04 以降では通常、空になっているか、新しい場所を示すコメントだけが記載されています。/etc/apt/sources.list.d/*.list: 1 行形式のエントリです。通常はリポジトリごとに 1 ファイルを配置します。/etc/apt/sources.list.d/*.sources: deb822 形式の stanza です。Ubuntu 24.04 以降では、ubuntu.sourcesにディストリビューション独自のリポジトリが保存されています。/etc/apt/keyrings/: 追加した鍵を配置する場所です。/usr/share/keyrings/にはパッケージ由来の鍵が保存されています。
apt が読み込むのは、.list または .sources で終わるファイルだけです。ファイル名には英字、数字、アンダースコア、ハイフン、ピリオドを使用できます。それ以外の拡張子を持つファイルは通知を出してスキップされるため、以下の修正に影響します。
重複している組み合わせを見つける
まず、ディレクトリの一覧を確認します。
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同じ stem で拡張子が異なる 2 つのファイルが、一般的な重複ペアです。ただし、ファイル名だけで判断しないでください。重複した設定が、任意の名前のファイルに隠れている可能性があるため、内容を確認します。
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同じホストと同じ suite を指定している 2 つのエントリがペアです。どちらも https://download.docker.com/linux/ubuntu と suite noble を指定しているため、同じリポジトリを 2 回記述しています。さらに、Signed-By のパスも一致していません。この不一致が、先ほど示した Conflicting values エラーの原因です。
この手順では、apt コマンドではなく grep を使用します。apt は競合で停止している場合、ソースの一覧も表示できません。そのため、apt-cache policy を実行しても、必要な結果ではなく同じエラーが表示されます。
修正方法: deb822 ファイルを残し、旧形式のファイルを移動する
.sources ファイルを残します。これは現在 apt ツールが書き込む形式であり、Debian と Ubuntu の両方が今後採用する形式です。削除する前に、主要な 2 つのパスのどちらがディスク上に存在するかを確認します。
ls -l /etc/apt/keyrings/ /usr/share/keyrings/ | grep -i docker-rw-r--r-- 1 root root 4813 Aug 9 14:40 docker.asc存在するのは /etc/apt/keyrings/docker.asc だけです。そのため、deb822 ファイルの内容が正しく、.list ファイルは削除済みの鍵を参照しています。残す予定のファイルが不足している鍵を指定している場合は、先に動作しているパスをそのファイルへコピーし、その後で他方のファイルを削除します。
旧形式のファイルは、完全に削除するのではなくディレクトリの外へ移動します。
sudo mkdir -p /root/apt-sources-backup
sudo mv /etc/apt/sources.list.d/docker.list /root/apt-sources-backup/
sudo apt updatedocker.list.bak に名前を変更してその場に残す方法もあります。apt は未知の拡張子を無視するためです。ただし、その場合は apt を実行するたびに次のメッセージが表示されます。
N: Ignoring file 'docker.list.bak' in directory '/etc/apt/sources.list.d/' as it has an invalid filename extensionファイルを別の場所へ移動すれば、この通知を表示させずにバックアップも残せます。その後の正常な apt update は次のようになります。2 つのファイルを指定する行はありません。
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.次に、編集後もリポジトリが有効であることを確認します。
apt-cache policy | grep download.docker.com 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
origin download.docker.comベンダーのドキュメントが引き続き 1 行形式のファイルを前提としている場合は、そのファイルを残し、代わりに .sources ファイルを削除できます。どちらの場合も、1 つのルールだけが判断基準になります。指定された archive と suite を宣言できるファイルは、必ず 1 つだけです。
apt update が 1 つの壊れたサードパーティーソースで停止する理由
隣接する障害も見た目は異なりますが、根本原因は同じです。apt が利用できないサードパーティーソースです。最初のパターンは鍵がない場合です。
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.Signed-By フィールドがないか、使用可能な鍵ではないファイルを指しているため、apt はアーカイブの InRelease ファイルの署名を検証できません。そのため、確認できないパッケージリストを信頼するのではなく、リポジトリ全体を破棄します。まず鍵ファイル自体を確認します。
ls -l /etc/apt/keyrings/docker.asc
gpg --show-keys /etc/apt/keyrings/docker.asc正常な鍵を指定すると、鍵 ID を含む pub 行と、ベンダー名を示す uid 行が表示されます。gpg: no valid OpenPGP data found. は、そのファイルが鍵ではないことを意味します。通常は、鍵の URL が移動したため、ダウンロード結果としてエラーページが保存されています。鍵を再取得し、ファイルを確認してから apt update を実行します。
2 つ目のパターンは、リリースアップグレード後に発生します。
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 はその suite 向けに何も公開していません。そのため、サーバー上にパスが存在せず、リクエストは 404 を返します。他のリポジトリは引き続き更新され、すでにインストールされているパッケージも影響を受けません。ただし、実行結果は非ゼロで終了します。そのため、apt update の終了ステータスを確認するスクリプトは、実行のたびに失敗を報告します。unattended security upgrades を設定したサーバーでは、不要になったソースを削除する価値があります。毎日のノイズに、本当の障害が埋もれるためです。ベンダーのインストールスクリプトでは、この 2 つのパターンがどちらも発生します。そのため、Ubuntu での Tailscale のインストールエラーの多くは、スクリプトが書き込まなかった keyring、またはアーカイブが提供していないリリース codename が原因です。
ソースを 1 つ無効にし、他のソースに影響を与えない
deb822 ファイルの場合は、stanza にフィールドを 1 つ追加して保存します。
Types: deb
URIs: https://ppa.launchpadcontent.net/ondrej/php/ubuntu
Suites: plucky
Components: main
Signed-By: /etc/apt/keyrings/ondrej-php.asc
Enabled: nostanza の各行をコメントアウトするよりも、この方法が推奨されています。元に戻すのも簡単です。1 行形式のファイルでは、行頭に # を付けます。どちらの形式でも、ファイルを /etc/apt/sources.list.d/ の外へ移動する方法が使えます。リポジトリを今後使用しない場合は、この方法を選択します。
もう一度 sudo apt update を実行します。そのリポジトリの Err: ブロックが表示されなくなり、終了ステータスは 0 に戻ります。次の行で echo $? を実行すると確認できます。
壊れたソースを sudo rm /etc/apt/sources.list.d/* で修復しようとしてはいけません。Ubuntu 24.04 以降では、ディストリビューション独自のリポジトリを保持する ubuntu.sources が削除されます。その結果、apt にパッケージリストがまったく残らず、明らかに存在するソフトウェアに対しても E: Unable to locate package curl と報告されます。すでに実行している場合は、次の内容でファイルを作り直します。
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これを /etc/apt/sources.list.d/ubuntu.sources として保存します。noble は、lsb_release -cs から確認した自分のリリース名に置き換えてください。その後、sudo apt update を実行します。
従来の .list ファイルを deb822 に変換する
2026 年 8 月時点では、apt 3.0 以降にこの変換機能が含まれています。Debian 13 と Ubuntu 25.04 以降のすべてのリリース（26.04 を含む）にも搭載されています。バージョンを確認してから、次のコマンドを実行します。
apt --version
sudo apt modernize-sources/etc/apt/sources.list.d/ 配下の1行形式のファイルが、deb822 形式の .sources ファイルに書き換えられます。出力内容を確認し、結果を信頼する前に自分でディレクトリを一覧表示して、apt update を実行してください。Ubuntu 24.04 に搭載されている apt は古く、このサブコマンドがありません。その場合、コマンドは E: Invalid operation modernize-sources と返します。このリリースでは、上記のフィールド対応表を使って手動で変換してください。
apt は現在も両方の形式を読み取れるため、現時点で変換は必須ではありません。ただし、今後も運用するサーバーでは変換する価値があります。現在、ソースを書き込むすべてのツールが deb822 形式を使用するためです。.sources ファイルだけを持つサーバーでは、この種の重複が新たに発生することもありません。
サードパーティーのソースをサーバー上で整理する
サードパーティーリポジトリは、サーバー上で最も早く古くなる部分です。各リポジトリは、提供元が使用中の Ubuntu リリース向けに公開を続けるという約束です。リリースアップグレードでは、同じ日にその約束をすべて検証することになります。
- ディストリビューションのパッケージでは対応できない場合に限り、サードパーティーリポジトリを追加します。通常の Ubuntu 24.04 の LAMP スタックには不要です。Ubuntu のアーカイブに必要なすべてのパッケージが含まれており、リリースのサポート期間中はセキュリティ更新も提供されます。
- 鍵は
/etc/apt/keyrings/に保存し、ベンダーごとに 1 ファイル、モードは 644 にします。権限のない_aptユーザーがダウンロードを実行し、鍵を読み取る必要があります。そのため、root だけが読み取れる鍵ファイルを使うと、そのリポジトリから取得するたびに権限エラーになります。 - すべての stanza で、
Signed-Byにその正確なファイルを指定します。/etc/apt/trusted.gpgや/etc/apt/trusted.gpg.d/に置かれた鍵は、サーバー上のすべてのリポジトリで信頼されます。つまり、数年前に追加されたベンダーの鍵で、どこから取得したパッケージでも検証できてしまいます。 - リリースアップグレードの前に sources を確認し、各ベンダーが移行先の suite 向けにすでに公開しているかを確認します。
古いグローバル keyring にある鍵は、更新のたびに使用されます。
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.その鍵だけを専用ファイルにエクスポートし、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リポジトリの stanza に Signed-By: /etc/apt/keyrings/docker.gpg を追加し、sudo apt update を実行します。古い keyring に依存するリポジトリがなくなると警告は停止します。その後、sudo gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --delete-key 7EA0A9C3F273FCD8 でエントリを削除できます。
もう 1 つの習慣が、最も大きなトラブルを防ぎます。do-release-upgrade はアップグレード中にサードパーティーソースを無効にし、その後も無効なままにします。手作業で 1 つずつ再有効化すると、重複した定義が作成されやすくなります。開始前に Ubuntu 24.04 から 26.04 へのアップグレードガイドを読み、引き続き必要なリポジトリを書き出しておきます。構築したばかりのマシンでは、ソースを適切に設定する最も安価なタイミングは、新しい VPS の最初の 10 分です。その時点では、サーバー上のエントリは Ubuntu が提供したものだけだからです。
FAQ
apt が target は複数回設定されていると表示するのはなぜですか？
/etc/apt/sources.list.d/ 配下の 2 つのファイルが、同じリポジトリ、suite、component を宣言しているためです。メッセージには、docker.list:1 や docker.sources:1 のように、両方のファイル名と行番号が表示されます。apt はそれらを統合して処理を続けるため、更新自体は成功します。ただし、この重複は解消してください。2 つのファイルで異なる署名鍵を指定すると、apt は E: Conflicting values set for option Signed-By で停止し、すべての source を読み込めなくなります。その結果、apt install も実行できません。
.list ファイルと .sources ファイルのどちらを残すべきですか？
.sources ファイルを残してください。deb822 は Ubuntu 24.04 以降で add-apt-repository が書き込む形式です。角括弧内の位置依存テキストではなく、設定ごとに名前付きフィールドを 1 つ持ちます。今後はこの形式が標準になります。.list ファイルを削除する前に、.sources ファイル内の Signed-By パスが、実在する鍵を指していることを ls -l /etc/apt/keyrings/ で確認してください。古いファイルは /etc/apt/sources.list.d/ の外へ移動してください。ディレクトリ内で名前を変更するだけにすると、.bak という名前が残り、apt は実行のたびに無視したファイルの通知を表示します。
apt リポジトリを削除せずに無効化するにはどうすればよいですか？
deb822 .sources ファイルでは、stanza に Enabled: no を追加します。1 行形式の .list ファイルでは、行頭に # を置きます。どちらの場合も、その後で sudo apt update を実行すると、そのリポジトリに対応する Err: ブロックが表示されなくなります。これは、サードパーティーリポジトリに使用中の Ubuntu リリース向けパッケージがまだなく、404 によって apt update が終了コード 0 以外で終了する場合に適した方法です。
1 行形式の sources.list は廃止されますか？
廃止予定ですが、削除されたわけではありません。apt は引き続き .list ファイルを読み込み、当面はこの動作が続くため、明日サーバーが動かなくなることはありません。新しいツールは deb822 形式を書き込みます。Ubuntu 24.04 以降では、ディストリビューションのリポジトリが /etc/apt/sources.list.d/ubuntu.sources に保存され、add-apt-repository は .sources ファイルを書き込みます。apt 3.0 以降では、sudo apt modernize-sources で既存のファイルを変換できます。