著者 aptの重複ソースを解消する方法 .listと.sources
apt updateの「Target is configured multiple times」エラーを解決します。Ubuntu 24.04以降で増えた.listと.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 は両方を統合し、更新も実行します。深刻なケースでは、処理全体が停止します。
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 は処理を拒否します。同一の定義であれば統合しますが、2 つの Signed-By のどちらを使うかは選択しません。誤ったキーを選ぶと、アーカイブの所有者が署名に使用していないキーでパッケージ署名を検証することになるためです。そのため、apt はソースを 1 つも読み込みません。ファイルを手動で編集するまで、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 つ以上のコンポーネントを記述します。意味が位置で決まるため、空白の位置を誤ると apt が読み取る内容が変わります。
deb822 では、同じ内容を名前付きフィールドの stanza として記述します。この名前は RFC 822 に由来します。RFC 822 は、Debian がパッケージの control ファイルですでに使用しているメールヘッダー形式です。
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 に、コンポーネントは 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 に直接貼り付ける設定などです。インラインキーでは各行を 1 個の空白でインデントし、空行は単一のドットとして記述します。
各ファイルの配置場所
/etc/apt/sources.list: 以前から使われている単一ファイルです。Ubuntu 24.04 以降では通常、空であるか、新しい配置場所を示すコメントだけが記載されています。/etc/apt/sources.list.d/*.list: 1 行形式のエントリです。通常はリポジトリごとに 1 ファイルを配置します。/etc/apt/sources.list.d/*.sources: deb822 形式のスタンザです。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同じステム名で拡張子が異なる 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同じホストと同じスイートを持つ 2 つのエントリがペアです。どちらも https://download.docker.com/linux/ubuntu とスイート noble を指定しているため、同じリポジトリを 2 回記述しています。また、Signed-By のパスも一致していません。この不一致が、先ほど示した Conflicting values エラーの原因です。
この手順では、apt コマンドではなく grep を使用します。apt が競合で停止している場合、ソースの一覧も表示できません。そのため、apt-cache policy は必要な答えではなく、同じエラーを出力します。
修正する: deb822 ファイルを残し、legacy ファイルを削除する
.sources ファイルを残します。現在の apt tooling が書き込む形式であり、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 ファイルは削除された key を参照しています。残す予定のファイルが存在しない key を指定している場合は、先に動作しているパスをそのファイルへコピーしてから、もう一方のファイルを削除します。
legacy ファイルは、いきなり削除するのではなく、ディレクトリの外へ移動します。
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.次に、編集後も repository が維持されていることを確認します。
apt-cache policy | grep download.docker.com 500 https://download.docker.com/linux/ubuntu noble/stable amd64 Packages
origin download.docker.comvendor のドキュメントが今も 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 を返します。他のリポジトリは引き続き更新され、すでにインストールされているパッケージにも影響はありません。ただし、実行結果は non-zero で終了します。そのため、apt update の終了ステータスを確認するスクリプトは、実行のたびに失敗を報告します。自動セキュリティ更新を設定したサーバーでは、使用できないソースを削除しておくべき理由がここにあります。毎日のノイズに埋もれると、本当の障害を見落とすためです。
残りのソースを壊さずに 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: noapt のマニュアルでは、stanza の各行をコメントアウトする方法よりも、この方法が推奨されています。元に戻すのも簡単です。1 行形式のファイルでは、行頭に # を付けます。どちらの形式でも、ファイルを /etc/apt/sources.list.d/ の外へ移動する方法もあります。リポジトリを今後使用しない場合は、この方法を選択してください。
sudo apt update を再度実行します。そのリポジトリに対応する Err: ブロックが表示されなくなり、終了ステータスは 0 に戻ります。次の行で echo $? を実行すると確認できます。
壊れたソースを sudo rm /etc/apt/sources.list.d/* で修復しないでください。Ubuntu 24.04 以降では、このコマンドによって ubuntu.sources が削除されます。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/に保存された鍵は、サーバー上のすべてのリポジトリで信頼されます。そのため、数年前に追加されたベンダー鍵によって、任意の場所のパッケージを検証できてしまいます。 - リリースアップグレードの前にソースを確認し、移行先の 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 つのファイルで異なる signing key を指定すると、apt は E: Conflicting values set for option Signed-By で停止し、すべての source の読み込みを拒否するため、apt install も実行できなくなります。
.list ファイルと .sources ファイルのどちらを残すべきですか？
.sources ファイルを残してください。deb822 は Ubuntu 24.04 以降で add-apt-repository が書き込む形式です。角括弧内の位置依存テキストではなく、各設定を名前付きフィールドとして保持します。今後、ディストリビューションはこの形式へ移行します。.list ファイルを削除する前に、.sources ファイル内の Signed-By パスが、実在する key を指していることを 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 release 向けパッケージがまだなく、その 404 によって apt update がゼロ以外の終了コードで終了する場合に適切な方法です。
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 により残っているファイルを変換できます。