Ubuntu APTのトラブルシューティング：壊れたパッケージ、ホールド、GPGエラーの修正

長期間稼働している Ubuntu マシンでは、APT のエラーはよく発生します。これらは通常、リリースアップグレード、サードパーティリポジトリの変更、PPA の削除、手動インストールされた .deb ファイル、または中断されたパッケージインストールの後に現れます。

エラーメッセージは劇的に見えるかもしれませんが、ほとんどの APT 問題は神秘的なわけではありません。それは APT がリポジトリ、バージョン、インストール済みパッケージの状態について、以前と異なる見方をしているため、状態が一致しなくなっている問題です。

APT は以下の 4 つの質問に答えようとしています。

1. どのリポジトリが有効になっていますか？
2. どのパッケージバージョンが利用可能ですか？
3. どのパッケージがすでにインストールされていますか？
4. どのパッケージ変更が許可されていますか？

これらの答えに矛盾が生じると、パッケージの保持、依存関係の破損、公開鍵の欠落、PPA エラー、またはアップグレード時に保留されたパッケージなどが発生します。このガイドでは、Ubuntu APT に対する実用的なトラブルシューティング手順を提供します。これは、フォーラムのスレッドからランダムなコマンドを blindly（盲目的に）コピーして貼り付けることなく、システムを修復したい開発者、DevOps エンジニア、Linux ユーザー向けに書かれています。日常のインストールおよびアップグレードコマンドについては、Ubuntu APT および dpkg チートシート と併せて使用し、関連する Linux ワークフローについては、より広範な 開発者ツール コレクションを参照してください。

短縮版

システムがわずかに壊れている場合は、ここから始めてください。

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt update
sudo apt upgrade

パッケージが保留されている場合：

apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

PPA またはサードパーティリポジトリが失敗している場合：

ls /etc/apt/sources.list.d/
sudo apt update

失敗したリポジトリの行を読み、そのリポジトリを無効化するか修正してください。NO_PUBKEY が見える場合、キーサーバーからランダムなキーを blindly（盲目的に）インポートしないでください。公式のリポジトリ指示を見つけ、リポジトリキーを /etc/apt/keyrings にインストールし、signed-by を使用してそのリポジトリにバインドします。

何よりも先に：APT エラーを読み取る

最初にこれを実行してください。

sudo apt update

これをスキップしないでください。apt update はパッケージメタデータを更新します。パッケージをアップグレードするものではありません。Ubuntu がすべての構成されたリポジトリを読み取り、そのメタデータを検証できるかどうかを知らせます。

次に、Ubuntu のバージョンとコードネームを確認してください。/etc/apt/sources.list.d/ に古いリリース名が残っていると、404 エラーやリリースファイルエラーの頻繁な原因となります。どのリリースを使用しているか不明な場合は、Ubuntu バージョンの確認方法 を参照してください。

lsb_release -a

または：

cat /etc/os-release

また、アップグレード可能なものを確認してください。

apt list --upgradable

そして、パッケージが保持されていないか確認してください。

apt-mark showhold

これにより、決定木における最初の分岐が得られます。失敗のクラスを最初に特定することで、各クラスには異なる初期修正があるため、トラブルシューティングが容易になります。

• リポジトリの問題: apt update が失敗する。
• 依存関係の問題: apt update は成功するが、インストールまたはアップグレードが失敗する。
• 保持されたパッケージの問題: APT が特定のパッケージの変更を拒否する。
• 混合ソースの問題: PPA、手動 .deb、または古いリポジトリが互換性のないバージョンを提供している。
• 中断されたインストールの問題: dpkg がアンパックされたが、設定が完了していないパッケージがある。

一般的な Ubuntu APT 失敗タイプ

保留されたパッケージ

保留されたパッケージは常にエラーというわけではありません。これは、APT が現在のコマンドを使用してパッケージをアップグレードしないことを選択したことを意味します。これは、アップグレードが新しい依存関係のインストール、古いパッケージの削除、または単純な apt upgrade では実行されない方法でのパッケージ変更を必要とする場合に頻繁に発生します。

詳細を確認：

apt list --upgradable
apt-cache policy package-name

APT が何をしたいのかを読み取った後、フルアップグレードを試みてください。

sudo apt full-upgrade

full-upgrade は、アップグレードを完了するために必要な場合は、新しいパッケージのインストールとパッケージの削除を許可されます。これは有用ですが、それゆえに、変更を受け入れる前に提案された変更を読み取るべきです。ワークステーションでは、full-upgrade はレビュー後には通常問題ありませんが、サーバーでは削除対象を二度確認してください。

保持されたパッケージ

保持されたパッケージは、単に保留されているパッケージとは異なります。ホールド（保持）は、APT がそのパッケージの自動インストール、アップグレード、または削除を防止する明示的な指示です。ホールドは、カーネル、データベース、ドライバー、またはランタイムバージョンを固定するために有用ですが、忘れやすいのも事実です。

保持されたパッケージをリスト表示：

apt-mark showhold

パッケージを保持：

sudo apt-mark hold package-name

保持を解除：

sudo apt-mark unhold package-name

保持されたパッケージに関連する依存関係エラーが表示された場合、その保持が依然として意図的なものであるかどうかを判断してください。保持を自動的に解除しないでください。それらは、本番環境のサービス、ドライバー、または互換性に敏感なツールチェーンを保護している可能性があります。

破損した依存関係

破損した依存関係とは、APT が有効なパッケージセットを見つけられないことを意味し、通常はダウンロードの破損ではなくバージョン競合を指摘します。

一般的な原因には以下が含まれます。

• パッケージが利用できないバージョンを必要としている。
• PPA が Ubuntu が想定するよりも新しいライブラリを提供している。
• 手動インストールされた .deb が別のリリースのパッケージに依存している。
• パッケージのインストールが中断された。
• 誤った Ubuntu リリース用のリポジトリが有効になっている。
• パッケージのピン留めまたは保持が必要なバージョン変更を防止している。

以下から始めます。

sudo dpkg --configure -a
sudo apt --fix-broken install

次にパッケージを検査します。

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

次に、これらのコマンドを使用して、APT をブロックしているパッケージバージョンの競合を見つけ、すべての修復コマンドを順番に実行するのではなく、それに対応します。

GPG キーと NO_PUBKEY エラー

NO_PUBKEY エラーは、APT がリポジトリメタデータを受信したが、必要な公開鍵が欠落しているため署名を検証できないことを意味します。これは単なるダウンロード問題ではなく、信頼の問題です。

典型的なエラーは以下のようになります。

The following signatures could not be verified because the public key is not available: NO_PUBKEY ABCD1234EF567890

古い指示では apt-key add がよく使用されていましたが、新しいリポジトリのセットアップにはそれを避けてください。現代の Ubuntu システムでは、リポジトリ固有のキーリングと signed-by を使用するべきです。

より良いパターンは以下のようになります。

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/repo-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

URL とリポジトリ行をベンダーの公式指示に置き換えてください。

重要な部分はこれです。

signed-by=/etc/apt/keyrings/example.gpg

この signed-by 行は、キーを1つのリポジトリにバインドするため、すべてのサードパーティキーをグローバルな信頼ストアに配置するよりもクリーンで安全です。

不良 PPA またはリリースファイルエラー

PPA の失敗は以下のように見えることがよくあります。

The repository does not have a Release file.

または：

404 Not Found

一般的な原因：

• PPA があなたの Ubuntu リリースをサポートしていない。
• Ubuntu をアップグレードしたが、PPA が依然として古いコードネームを指している。
• PPA が削除された。
• メンテナーがパッケージの配信を停止した。
• 異なる Ubuntu バージョン用に意図された PPA を追加した。

コードネームを確認：

. /etc/os-release
echo "$VERSION_CODENAME"

サードパーティのソースファイルをリスト表示：

ls /etc/apt/sources.list.d/

それらを検査：

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

疑わしいソースをリネームして無効化：

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

ファイルを無効化した後に APT が機能するようになった場合、問題の原因となったソースを見つけたことになります。それを修正するか永続的に削除できます。

安全な APT トラブルシューティングワークフロー

ステップ 1: メタデータを更新

sudo apt update

これが失敗した場合は、パッケージ修復を試みる前にリポジトリを修正してください。APT は、パッケージインデックスが古くなっているか不完全な場合、依存関係を正しく解決できません。

以下を含む行を探してください。

NO_PUBKEY
Release file
404 Not Found
does not have a Release file
The repository is not signed

これらはリポジトリまたは信頼の問題であり、パッケージ修復を試みる前に修正する必要があります。

ステップ 2: 中断されたパッケージ設定を完了

パッケージのインストールが中断された場合、dpkg はファイルをアンパックしたが、パッケージを設定しなかった可能性があります。

以下を実行：

sudo dpkg --configure -a

これが成功したら、続けて：

sudo apt --fix-broken install

失敗した場合は、パッケージ名とエラーを注意深く読んでください。エラーの下部にあるパッケージ名は、元々インストールしようとしたパッケージよりも重要であることが多いです。

ステップ 3: APT に依存関係の修復を依頼

sudo apt --fix-broken install

このコマンドは、欠落している依存関係のインストールまたは満たせないパッケージの削除により、依存関係の問題を修正するように APT に依頼します。提案されたアクション、特に削除対象を注意深く読んでください。

APT が以下を削除しようとする場合は注意してください。

• ubuntu-desktop
• ubuntu-server
• linux-generic
• ディスプレイマネージャーパッケージ
• ネットワークパッケージ
• データベースパッケージ
• コンテナランタイムパッケージ
• デスクトップ環境パッケージ

メタパッケージの削除が無害な場合もありますが、時にはパッケージソースがひどく混在していることの警告サインであることもあります。内容を理解せずに大規模な削除を受け入れないでください。

ステップ 4: 保持されたパッケージを確認

apt-mark showhold

保持されたパッケージがアップグレードをブロックしている場合は、それを検査してください。

apt-cache policy package-name

保持がもはや必要でない場合：

sudo apt-mark unhold package-name
sudo apt update
sudo apt upgrade

保持が意図的なものである場合、APT と戦わないでください。保護を解除するのではなく、保持の周りにあるリポジトリまたはパッケージ選択を修正してください。

ステップ 5: パッケージバージョンを検査

依存関係の問題があるパッケージの場合：

apt-cache policy package-name

これにより以下が表示されます。

• インストール済みバージョン
• 候補バージョン
• 利用可能なバージョン
• 各バージョンを提供するリポジトリ

apt-cache policy は、利用可能な各バージョンの来源を示すため、最も有用な APT デバッグコマンドの一つです。

例：

apt-cache policy docker-ce

候補バージョンが予期しない PPA または古いリポジトリから来ている場合、依存関係競合の主要原因を見つけたことになります。

ステップ 6: 混合リポジトリを探す

有効なソースをリスト表示：

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

以下を探してください。

• 古い Ubuntu コードネーム
• Ubuntu 上の Debian リポジトリ
• 他の Ubuntu リリース用の PPA
• 重複したベンダーリポジトリ
• 同じツールのための Snap と APT 指示の混合
• ソフトウェアのアンインストール後に残された古い .list ファイル

一般的なアンチパターンは、ベンダーリポジトリからツールをインストールし、後に重複するライブラリを提供する PPA または手動 .deb を追加することです。APT は多くのソースを処理できますが、リポジトリを自分で整列させない限り、競合する意図を調整することはできません。

ステップ 7: シミュレーションインストールまたはアップグレードを試す

変更を行う前に、シミュレートしてください。

apt -s install package-name

または：

apt -s full-upgrade

-s オプションは操作をシミュレートします。システムを変更せずに APT が何をしようとするかを確認したい場合に有用です。

保持されたパッケージの修正

保持されたパッケージをリスト表示

apt-mark showhold

何も表示されない場合、apt-mark で保持されているパッケージはなく、依存関係またはリポジトリチェックに進むことができます。

意図的にパッケージを保持

sudo apt-mark hold package-name

パッケージを保持する良い理由：

• ハードウェアと互換性のあるカーネルバージョンが既知である。
• データベースのアップグレードに計画が必要である。
• ドライバーの更新が GPU を壊す。
• ランタイムバージョンが本番環境と一致する必要がある。
• ベンダーパッケージが最新の依存関係と互換性がない。

パッケージを保持する悪い理由：

• 古いガイドからコマンドをコピーした。
• なぜ保持したのか忘れた。
• 依存関係エラーを理解せずに回避しようとしている。

保持を解除

sudo apt-mark unhold package-name

次に更新およびアップグレード：

sudo apt update
sudo apt upgrade

パッケージが依然としてアップグレードされない場合、それは保持の問題だけではありませんでした。ポリシーを確認してください。

apt-cache policy package-name

破損した依存関係の修正

標準的な修復シーケンス

パッケージのインストールまたはアップグレードが途中で失敗した場合は、このシーケンスを使用します。

sudo apt update
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

この順序は重要です。各ステップが次のステップの準備をするからです。apt update はリポジトリメタデータを更新し、dpkg --configure -a はアンパックされたパッケージの設定を完了し、apt --fix-broken install は APT に欠落または競合する依存関係を調整させ、apt upgrade は通常のパッケージアップグレードを再開します。

悪くインストールされたローカルパッケージを削除

ダウンロードした .deb のインストール後に問題が開始された場合は、それを検査してください。

dpkg -l | grep package-name
apt-cache policy package-name

削除：

sudo apt remove package-name

設定ファイルも問題を引き起こしている場合：

sudo apt purge package-name

次に修復：

sudo apt --fix-broken install

損傷したパッケージを再インストール

パッケージがインストールされているが壊れている場合：

sudo apt install --reinstall package-name

これは、ファイルが欠落または破損しているが、パッケージソースはそれ以外では健全であり、バージョンを変更せずにインストールされたファイルを更新したい場合に有用です。

PPA およびサードパーティリポジトリの問題の修正

PPA およびサードパーティリポジトリを見つける

ls /etc/apt/sources.list.d/

アクティブなリポジトリ行を表示：

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

新しい Ubuntu システムでは、deb822 形式を使用する .sources ファイルも表示される場合があります。

ls /etc/apt/sources.list.d/*.sources

それらを表示：

cat /etc/apt/sources.list.d/*.sources

PPA を安全に無効化

ソースファイルをリネーム：

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

deb822 ファイルの場合：

sudo mv /etc/apt/sources.list.d/example.sources /etc/apt/sources.list.d/example.sources.disabled
sudo apt update

ソースファイルのリネームは可逆的で、誤ったソースを無効化した場合に元に戻せるため、リポジトリ構成を即座に削除するよりも安全です。

PPA からパッケージを削除

PPA の無効化は、そこから将来のパッケージダウンロードを停止します。そこからすでにインストールされたパッケージを自動的にダウングレードするわけではありません。

PPA がライブラリ競合を引き起こした場合、パッケージを Ubuntu バージョンに戻す必要がある場合があります。

ppa-purge をインストール：

sudo apt install ppa-purge

次に PPA をパージ：

sudo ppa-purge ppa:owner/name

ppa-purge を慎重に使用し、受け入れる前に提案された変更を読んでください。関連する複数のパッケージを削除またはダウングレードする可能性があるためです。

リリースアップグレード後

Ubuntu をアップグレードした後、古い PPA はエラーの一般的な原因です。

古いコードネームを確認：

grep -R "jammy\|noble\|oracular\|plucky" /etc/apt/sources.list /etc/apt/sources.list.d/

実際のシステムに合わせてコードネームを調整します。例えば、Ubuntu 24.04 を使用している場合、コードネームは noble です。サードパーティソースが依然として古いコードネームを指している場合、そのベンダーが現在の Ubuntu リリースをサポートしているか確認してください。アップグレードの修復ではなく新しいマシンのセットアップを行っている場合、Ubuntu 24.04 インストールガイド で、ベンダーリポジトリを signed-by と共に最初から追加する方法を解説しています。

コードネームを編集して最善を願うだけでなく、ベンダーサポートを確認してください。一部のリポジトリはすべての Ubuntu バージョン向けにパッケージを公開していないため、最初にリリースに対するベンダーサポートを確認してください。

GPG および NO_PUBKEY エラーの修正

NO_PUBKEY の意味

APT リポジトリは署名付きメタデータを公開し、そのメタデータを検証するためにあなたのマシンは対応する公開鍵を必要とします。鍵が欠落している場合、APT はリポジトリを信頼することを拒否します。これは望ましい動作です。エラーを消すために署名チェックを無効にしないでください。

現代的なキーリングパターン

キーリングディレクトリを作成：

sudo install -d -m 0755 /etc/apt/keyrings

ベンダーキーをダウンロードしてデアモア：

curl -fsSL https://example.com/repository-key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

読み取り可能な権限を設定：

sudo chmod 0644 /etc/apt/keyrings/example.gpg

signed-by と共にリポジトリを追加：

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/example.list

次に更新：

sudo apt update

必要に応じて noble を Ubuntu コードネームに置き換えてください。

. /etc/os-release
echo "$VERSION_CODENAME"

なぜ apt-key は悪い習慣なのか

古いガイドでは以下がよく使用されます。

curl -fsSL https://example.com/key.gpg | sudo apt-key add -

新しいセットアップでは apt-key add を避けてください。古い apt-key スタイルは、幅広い信頼領域にキーを追加するため、どのキーがどのリポジトリのために信頼されているかを推論するのが難しくなります。一方、現代的な signed-by スタイルはキーを特定のリポジトリにスコープ限定し、基本的なサプライチェーン衛生管理となります。

従来の信頼済みキーを見つける

従来のキーが以下にある場合があります。

/etc/apt/trusted.gpg
/etc/apt/trusted.gpg.d/

ファイルをリスト表示：

ls -l /etc/apt/trusted.gpg.d/

キーをランダムに削除しないでください。最初に各キーをリポジトリにマッピングし、次に1つのリポジトリずつ /etc/apt/keyrings と signed-by へ移行してください。

一般的な GPG ミス

NO_PUBKEY エラーを修正する際に、ランダムなキーサーバーを最初の選択肢として使用しないでください。

より良い順序：

1. ベンダーの公式インストールドキュメントを使用する。
2. ベンダーの公式 HTTPS URL からキーをダウンロードする。
3. /etc/apt/keyrings に保存する。
4. signed-by でバインドする。
5. sudo apt update を実行する。

これらのショートカットを避けてください。

sudo apt update --allow-unauthenticated
sudo apt install --allow-unauthenticated package-name

これらは一時的に機能するかもしれませんが、改ざんされたリポジトリメタデータからあなたを保護する署名検証を削除します。

「リポジトリは署名されていません」の修正

このエラーは通常、以下の一を意味します。

• リポジトリが署名付きメタデータを公開していない。
• リポジトリ URL が誤っている。
• リポジトリがあなたの Ubuntu バージョンをもうサポートしていない。
• プロキシまたはミラーが誤ったコンテンツを返している。
• ベンダーが HTTPS を期待している場所で HTTP を使用している。
• ソースファイルが誤ったスイートまたはコンポーネントを持っている。

失敗したソースを見つける：

sudo apt update

APT は URL を印刷します。次にそれを探します。

grep -R "example.com" /etc/apt/sources.list /etc/apt/sources.list.d/

一時的に無効化：

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

ファイルを無効化した後に APT が再び機能するようになった場合、古い構成を再有効化するのではなく、ベンダーの現在の公式指示からそのリポジトリを再インストールしてください。

重複リポジトリ警告の修正

APT は、ターゲットが複数回構成されていることを警告することがあります。

一致するエントリをリスト表示：

grep -R "repo-url-or-domain" /etc/apt/sources.list /etc/apt/sources.list.d/

重複リポジトリは、ベンダーインストールスクリプトを複数回実行した後に頻繁に現れます。

1つのソースファイルを保持します。他を無効化：

sudo mv /etc/apt/sources.list.d/duplicate.list /etc/apt/sources.list.d/duplicate.list.disabled
sudo apt update

重複警告は常に致命的ではありませんが、それは乱雑な構成の兆候であるため、1つのソースファイルを保持し、重複を無効化してください。

誤った Ubuntu リリースからのパッケージの修正

最も悪い APT 問題の一つは、Ubuntu リリースの混在です。例えば、Ubuntu 24.04 のマシンは、Ubuntu 22.04 または Debian testing からパッケージをカジュアルに取得してはいけません。時々それはしばらく機能しますが、最終的には依存関係グラフが APT ではクリーンに解決できないパズルになります。

リリースを確認：

. /etc/os-release
echo "$VERSION_CODENAME"

ソースを検索：

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/

有効なソースに外国のコードネームを探し、次に影響を受けたパッケージを検査：

apt-cache policy package-name

インストールされたバージョンが古いか外国のリポジトリから来た場合、そのリポジトリを無効化し、Ubuntu リポジトリから影響を受けたパッケージをダウングレードまたは再インストールしてください。

保守的な修復パスは：

sudo apt update
sudo apt install --reinstall package-name

より深い競合の場合、外国のバージョンの上書きでアップグレードを強制するのではなく、パッケージを削除し、正しいソースから再インストールする必要がある場合があります。

APT キャッシュおよび未使用パッケージのクリーンアップ

APT キャッシュのクリーンアップはそれ自体で依存関係の修正ではありませんが、多くの失敗したインストール後、ディスク領域を回復し、古いパッケージファイルをクリアすることで役立つ場合があります。

自動的にインストールされ、もはや必要ないパッケージを削除：

sudo apt autoremove

ダウンロードされたパッケージファイルをクリーン：

sudo apt clean

または、古いパッケージファイルのみを削除：

sudo apt autoclean

サーバーおよび手動でインストールされたドライバースタックを持つデスクトップでは autoremove を慎重に使用し、受け入れる前に削除リストを読んでください。

実用的な APT トラブルシューティングレシピ

レシピ: パッケージが保留されている

sudo apt update
apt list --upgradable
apt-mark showhold
sudo apt full-upgrade

APT がシミュレーション後に合理的な変更を提案する場合、それを受け入れます。大規模な削除を提案する場合、停止して検査：

apt-cache policy package-name

レシピ: 保持されたパッケージがアップグレードをブロック

apt-mark showhold
apt-cache policy package-name
sudo apt-mark unhold package-name
sudo apt upgrade

保持がもはや意図的でない場合にのみ、パッケージの保持を解除してください。本番ソフトウェアを保護している保持を解除すると、破壊的なアップグレードをトリガーする可能性があるためです。

レシピ: 中断されたインストール

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt upgrade

レシピ: NO_PUBKEY エラー

1. sudo apt update からリポジトリを特定する。
2. ベンダーの現在の公式インストール指示を見つける。
3. キーを /etc/apt/keyrings にインストールする。
4. ソースファイルで signed-by を使用する。
5. sudo apt update を実行する。

例の構造：

sudo install -d -m 0755 /etc/apt/keyrings

curl -fsSL https://example.com/key.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg

sudo chmod 0644 /etc/apt/keyrings/example.gpg

echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/ubuntu noble main" \
  | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

レシピ: PPA にリリースファイルがない

sudo apt update
ls /etc/apt/sources.list.d/
grep -R "ppa.launchpadcontent.net\|launchpad" /etc/apt/sources.list.d/

PPA を無効化：

sudo mv /etc/apt/sources.list.d/example.list /etc/apt/sources.list.d/example.list.disabled
sudo apt update

次に、その PPA からパッケージを削除、置換、またはパージするかどうかを決定します。

レシピ: 手動 .deb が依存関係を壊した

dpkg -l | grep package-name
apt-cache policy package-name
sudo apt remove package-name
sudo apt --fix-broken install

依然としてソフトウェアが必要な場合、時間の経過とともに依存関係競蓄積する傾向のある反復的な手動 .deb インストールよりも、ベンダーの現在の APT リポジトリを優先してください。

必須 APT トラブルシューティングコマンド

リポジトリとメタデータ

sudo apt update
grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/
ls /etc/apt/sources.list.d/

パッケージ状態

apt list --installed
apt list --upgradable
apt-mark showhold
dpkg -l | grep package-name

パッケージポリシーと依存関係

apt-cache policy package-name
apt-cache depends package-name
apt-cache rdepends package-name

修復

sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt install --reinstall package-name
sudo apt full-upgrade

クリーンアップ

sudo apt autoremove
sudo apt autoclean
sudo apt clean

シミュレーション

apt -s install package-name
apt -s full-upgrade

してはいけないこと

/var/lib/dpkg をランダムに削除しないで

dpkg 状態ファイルを削除するアドバイスが見えた場合、懐疑的に考えてください。dpkg データベースはインストールされたパッケージの記録であり、その一部を削除すると、修復可能なパッケージ問題を完全なシステム復旧プロジェクトに変えてしまう可能性があります。

署名検証を無効にしないで

以下を避けてください。

--allow-unauthenticated

リポジトリが検証できない場合、認証をバイパスするのではなく、キーを修正するかリポジトリを無効化してください。

Ubuntu リリースをカジュアルに混在させない

APT ピン留めと依存関係の影響を理解していない限り、別の Ubuntu リリース用のリポジトリを追加しないでください。

これは特に以下に適用されます。

• デスクトップ環境
• グラフィックスドライバー
• Python スタック
• コンテナランタイム
• Kubernetes パッケージ
• データベースパッケージ

PPA を無害と扱わない

PPA は有用ですが、それでもライブラリやシステムパッケージを置換できるパッケージリポジトリです。これはあなたが望むものかもしれず、または次のアップグレードが壊れる理由かもしれません。幅広いシステム基盤ではなく、特定のアプリケーションのために PPA を優先し、メンテナーを信頼し、アップグレードパスを理解している場合にのみ使用してください。

APT トラブルシューティング決定木

このメンタルモデルを使用してください。

ほとんどの APT 問題は、1つの大きなエラーとして扱うのをやめ、リポジトリの健全性、パッケージ状態、依存関係解決、および信頼構成を分離し始めると管理可能になります。上記の決定木はその規律の略語です。

開発者マシンの推奨ベースライン

クリーンな Ubuntu 開発者ワークステーションのために、私はこのベースラインを好みます。

• Ubuntu リポジトリを標準的に保つ。
• 公式かつメンテナンスされている場合にのみベンダー APT リポジトリを使用する。
• サードパーティリポジトリのために /etc/apt/keyrings と signed-by を使用する。
• 古い apt-key 指示を避ける。
• コアシステムライブラリを置換する PPA の混在を避ける。
• 急速に動く開発者依存関係のために、コンテナ、uv、pipx、asdf、mise、または言語ネイティブツールを使用する。
• APT をオペレーティングシステム、ドライバー、サービス、および安定した CLI ツールの責任として保つ。

デスクトップソフトウェアの場合、サンドボックス化されたユニバーサルパッケージがニーズに合う場合は、PPA よりも Flatpak または Snap を優先してください。APT は基本システムを管理するときには優れていますが、急速に動く言語エコシステムのためのユニバーサル開発者依存関係マネージャーのように振る舞うことを強制されると苦痛になります。

最終 APT トラブルシューティングチェックリスト

Ubuntu で APT が壊れた場合、このチェックリストで作業してください。

[ ] sudo apt update を実行し、最初の実際のエラーを読む。
[ ] /etc/os-release で Ubuntu コードネームを確認する。
[ ] dpkg --configure -a で中断されたインストールを完了する。
[ ] apt --fix-broken install で依存関係を修復する。
[ ] apt-mark showhold で保持されたパッケージを確認する。
[ ] apt-cache policy でパッケージバージョンを検査する。
[ ] 壊れた PPA またはサードパーティリポジトリを無効化する。
[ ] apt-key スタイルのリポジトリを signed-by キーリングに置き換える。
[ ] apt -s でリスクのある操作をシミュレートする。
[ ] full-upgrade または autoremove を受け入れる前に削除対象を読む。

APT はもろいわけではありませんが、厳格です。その厳格性は機能です。署名のないリポジトリ、不可能な依存関係セット、および偶発的なパッケージ置換がシステムを静かに変更するのを防ぎます。APT を修正する落ち着いた方法は、その厳格性を維持し、競合する状態を見つけ、実際に間違っている最小のものを修復することです。