一般的なパッケージ管理障害（APT/YUM）のトラブルシューティング方法

パッケージマネージャーの障害は、セキュリティアップデート、デプロイ、または普段触らないホストで「このツールをインストールするだけ」の簡単な作業中など、最悪のタイミングで発生する傾向があります。APT、YUM、DNFは通常、何が問題かを教えてくれますが、出力がノイズだらけになることがあります。重要なのは、落ち着いて、どのレイヤーで障害が発生したかを特定し、データベースをさらに悪い状態にしないことです。

APTはDebianおよびUbuntuシステムで一般的です。YUMとDNFはRed Hat系システムで一般的であり、DNFは新しいリリースの多くでYUMを置き換えています。以下の例は、管理者が実際に遭遇する障害、つまり壊れたトランザクション、リポジトリメタデータの問題、依存関係の競合、ロック、GPGエラー、パッケージデータベースの問題に焦点を当てています。

何かを変更する前に、正確なコマンドとエラーを記録してください。これが本番サーバーである場合は、別の更新プロセスが実行中でないかも確認してください。2つのパッケージマネージャーが同じデータベースをめぐって競合すると、小さな問題が長い修復作業に変わる可能性があります。

一般的なAPT障害とトラブルシューティング

APTは、その包括的な依存関係解決機能で知られています。ただし、壊れた依存関係、中断されたダウンロード、リポジトリの問題などに関連する問題が依然として発生する可能性があります。

1. 壊れたパッケージまたは未解決の依存関係

これはおそらく最も一般的なAPTエラーです。パッケージがインストールされているが、その依存関係が欠落している、壊れている、または互換性がない場合に発生します。エラーメッセージは次のようになります。

Error: dpkg was interrupted, you might need to run 'sudo dpkg --configure -a' to correct the problem.

Unpacking ... (reading database ... xxxx files and directories currently installed.)

Preparing to unpack .../some-package_version_arch.deb ...

Unpacking some-package (version) ...

dpkg: error processing archive /var/cache/apt/archives/some-package_version_arch.deb (--unpack):

 trying to overwrite '/path/to/file', which is also in package other-package:amd64

Errors were encountered while processing:

 some-package
 E: Sub-process /usr/bin/dpkg returned an error code (1)

トラブルシューティング手順:

保留中のパッケージを設定する: dpkgが中断された場合、最初のステップはそれを修正することです。
```
sudo dpkg --configure -a
```
このコマンドは、アンパックされたがまだ設定されていないすべてのパッケージを設定しようとします。
壊れた依存関係を修正する: 上記で解決しない場合は、壊れた依存関係を修正してみてください。
```
sudo apt --fix-broken install
```
このコマンドは、欠落している依存関係をダウンロードしてインストールするか、問題のあるパッケージを削除しようとします。
問題のあるパッケージを削除する: 特定のパッケージが永続的な問題を引き起こしている場合があります。それを削除してみてください。
```
sudo apt remove <package-name>
```
パッケージを通常の方法で削除できない場合は、強制的に削除する必要があるかもしれません（注意して使用してください）。
```
sudo dpkg --remove --force-remove-reinstreq <package-name>
```
APTキャッシュをクリーンアップする: 破損したキャッシュもエラーの原因となる可能性があります。
```
sudo apt clean
sudo apt update
```
apt cleanは、/var/cache/apt/archives/からダウンロードされたパッケージファイルを削除し、apt updateはパッケージリストを更新します。

2. リポジトリの問題

設定されたリポジトリからパッケージリストを取得できない場合にエラーが発生することがあります。これは、ネットワークの問題、無効なリポジトリURL、またはリポジトリが一時的に利用できないことが原因である可能性があります。

エラー例:

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Temporary failure resolving 'archive.ubuntu.com'
E: Some index files failed to download. They have been ignored, or old ones used instead.

トラブルシューティング手順:

DNSとネットワーク接続を確認する: DNS障害は、新しく構築されたサーバーや壊れたVPNパスでよく発生します。
```
getent hosts archive.ubuntu.com
curl -I http://archive.ubuntu.com/ubuntu/
```
リポジトリソースを確認する: /etc/apt/sources.listおよび/etc/apt/sources.list.d/内のファイルの内容を確認します。URLが正しく、アクセス可能であることを確認してください。
- タイプミスがないか確認します。
- 疑わしいリポジトリエントリをコメントアウトするか削除します。
別のミラーを試す: 特定のミラーがダウンしている場合、APTは自動的に別のミラーを試すことがあります。そうでない場合は、sources.listを手動で編集して別のミラーを選択します。
パッケージリストを更新する: 変更を加えた後は、必ず以下を実行してください。
```
sudo apt update
```

apt updateが署名について警告を発した場合、ショートカットとして署名チェックを無効にしないでください。リポジトリ署名は、改ざんされたパッケージのインストールからあなたを保護します。リポジトリベンダーがキーを変更したか、キーリングパッケージが古いか、古いサードパーティリポジトリがメンテナンスされていないかを確認してください。

3. 中断されたインストールまたはアップグレード

apt installまたはapt upgradeプロセスが中断された場合（停電やシステムの再起動など）、システムが一貫性のない状態のままになる可能性があります。

トラブルシューティング手順:

sudo dpkg --configure -aを実行する: 前述のように、これはdpkg設定の問題を修正するための最初のステップです。
sudo apt --fix-broken installを実行する: これにより、中断から生じた依存関係の問題を解決できます。
コマンドを再実行する: 一時的な問題であった場合、失敗したコマンドを再実行するだけで解決することがあります。

一般的なYUM/DNF障害とトラブルシューティング

YUMとDNFは、Red Hatベースのシステムでパッケージを管理するための強力なツールです。APTと同様に、障害は依存関係の問題、リポジトリの問題、またはキャッシュの破損に起因することがよくあります。

1. 依存関係エラー

YUM/DNFの依存関係エラーは、要求されたパッケージが、インストールされていない、互換性のないバージョンである、または設定されたリポジトリで見つからない別のパッケージを必要とする場合に発生します。

エラー例（YUM）:

Error: Package: some-package-1.0-1.el8.x86_64 (epel)

Requires: another-package >= 2.0

You could try: rpm -e --nodeps some-package

エラー例（DNF）:

Error: 
 Problem: cannot install the best candidate for this package (root means installing process)
  - nothing provides dependency 'another-package >= 2.0' needed by 'some-package-1.0-1.el8.x86_64'

トラブルシューティング手順:

パッケージ情報を更新する: ローカルパッケージキャッシュが最新であることを確認します。
```
sudo yum makecache # YUMの場合
sudo dnf makecache # DNFの場合
```
依存関係を手動でインストールする: 必要な依存関係がわかっている場合は、明示的にインストールしてみてください。
```
sudo yum install another-package # YUMの場合
sudo dnf install another-package # DNFの場合
```

クリーンアップツールを注意して使用する: これらのユーティリティは、重複したパッケージや古いパッケージを特定するのに役立つ場合があります。

sudo yum install yum-utils
sudo package-cleanup --cleandupes # 重複パッケージをクリーンアップ
sudo package-cleanup --orphans # 孤立したパッケージを削除

sudo dnf install dnf-plugins-core
sudo dnf clean all

ロールバック計画がない限り、rpm -e --nodepsを避ける: 依存パッケージをインストールしたままパッケージを削除できるため、コマンドは成功するかもしれませんが、システムが壊れる可能性があります。

2. リポジトリ設定の問題

YUM/DNFリポジトリの問題により、パッケージが見つからなかったり、インストールできなかったりする可能性があります。

トラブルシューティング手順:

リポジトリファイルを確認する: リポジトリ定義は通常/etc/yum.repos.d/にあります。これらの.repoファイルで以下を確認します。
- 正しいbaseurlまたはmirrorlistエントリ。
- 有効なリポジトリ（enabled=1）。
- GPGキー検証の問題（多くの場合gpgcheck=1で示されます）。
ネットワークアクセスを確認する: APTと同様に、システムがリポジトリサーバーに到達できることを確認します。
```
ping <repository-server-address>
```
GPGキーを確認する: GPGキーに関連するエラーが表示された場合は、リポジトリの公開キーをインポートまたは再インポートする必要があるかもしれません。
```
# キーをインポートする例
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-your-repo
```
本番システムでgpgcheck=0を設定することは避けてください。修復タスクをサプライチェーンリスクと交換することになります。
キャッシュをクリーンアップする: 破損したキャッシュは問題を引き起こす可能性があります。
```
sudo yum clean all
sudo dnf clean all
```
その後、メタデータを更新します。
```
sudo yum makecache
sudo dnf makecache
```

3. 不完全なトランザクションエラー

これらのエラーは、パッケージのインストール、更新、または削除プロセスが中断された場合に発生します。

トラブルシューティング手順:

トランザクションを再実行する: 多くの場合、コマンド（yum update、dnf installなど）を再実行するだけで、一時的な問題であれば解決できます。
キャッシュをクリーンアップする: 上記と同様に、キャッシュをクリアすると効果的な場合があります。
```
sudo yum clean all
sudo dnf clean all
```
保留中のパッケージを確認する: YUM/DNFではAPTほど一般的ではありませんが、一部の設定ではパッケージの更新が妨げられる場合があります。これは通常、直接の「hold」コマンドではなく、プラグイン設定によって管理されます。
ログを確認する: 詳細なエラーメッセージについては、/var/log/yum.log（YUMの場合）または/var/log/dnf.log（DNFの場合）を確認してください。

ロックとスタックしたパッケージプロセス

ロックエラーは、実際には依存関係エラーではありません。通常、別のパッケージプロセスが実行中であるか、クリーンアップされずに終了したことを意味します。

DebianまたはUbuntuでは、/var/lib/dpkg/lock-frontendまたは/var/lib/apt/lists/lockに関するメッセージが表示される場合があります。Red Hat系システムでは、RPMデータベースロックを保持している別のdnfまたはyumプロセスが表示される場合があります。

まず、アクティブなプロセスを確認します。

ps aux | grep -E 'apt|dpkg|dnf|yum|rpm' | grep -v grep

unattended-upgrades や cloud-init が実行中の場合は、待機します。実際のパッケージトランザクションを強制終了すると、パッケージが半分設定されたままになる可能性があります。プロセスがなくなっていて、古いロックのみが残っていると確信できる場合は、通常のツールを使用してパッケージデータベースを修復します。

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

RPMベースのシステムの場合:

sudo dnf clean all
sudo rpm --rebuilddb

rpm --rebuilddbは、すべてのDNF問題に対する最初の対応ではありません。リポジトリURLが間違っている場合ではなく、RPMデータベース自体が破損しているように見える場合に使用します。

サードパーティリポジトリからのバージョン競合

多くの深刻なパッケージ障害は、混合リポジトリ（ベンダーリポジトリ、EPEL、言語ランタイムリポジトリ、Kubernetesリポジトリ、古い内部ミラー）から発生します。パッケージマネージャーは指示されたことを正確に実行しているかもしれませんが、利用可能なバージョンが互いに満足できない場合があります。

APTシステムでは、ポリシーを検査します。

apt-cache policy <package-name>
apt-cache madison <package-name>

DNFシステムの場合:

dnf repoquery --show-duplicates <package-name>
dnf repolist --enabled

サードパーティのリポジトリが問題の原因である場合は、一時的に無効にしてトランザクションを再試行します。

sudo dnf --disablerepo='repo-name' update

APTの場合は、/etc/apt/sources.list.d/内の疑わしいエントリをコメントアウトし、sudo apt updateを実行して、再度テストします。システムを不明な状態のままにしないでください。どのリポジトリを無効にしたか、その理由を文書化してください。

リリースアップグレードまたはメジャーアップデートが失敗した場合

メジャーアップグレードは、通常のパッケージインストールよりも注意が必要です。再試行する前に、システムがリリース間にあるかどうか、古いリポジトリがまだ有効かどうか、設定プロンプトが中断されたかどうかを確認してください。

DebianまたはUbuntuでは、リリースファイルと保留中のパッケージを確認します。

cat /etc/os-release
apt-mark showhold
sudo dpkg --audit

DNFベースのシステムでは、有効なリポジトリとdistro-syncの動作を確認します。

cat /etc/os-release
dnf repolist --enabled
sudo dnf distro-sync

distro-syncは、有効なリポジトリに一致するようにパッケージをダウングレードまたは置き換える可能性があるため、受け入れる前に提案されたトランザクションを読んでください。重要なシステムでは、最初にスナップショットまたはバックアップを取得してください。パッケージマネージャーは依存関係の計算は得意ですが、ビジネスが依存しているローカル設定ファイル、カーネルモジュール、ベンダーエージェントを知ることはできません。

一般的なトラブルシューティングのヒント

パッケージマネージャーに関係なく、いくつかの一般的なプラクティスにより、時間と手間を節約できます。

エラーメッセージを注意深く読む: aptまたはyum/dnfからの出力には、問題に関する具体的な手がかりが含まれていることがよくあります。
システムログを確認する: APTの場合は/var/log/apt/history.logと/var/log/apt/term.log、YUM/DNFの場合は/var/log/yum.logまたは/var/log/dnf.logに、詳細なトランザクション履歴とエラー情報が含まれています。
定期的に更新する: システムとパッケージリストを最新の状態に保つことで、古い依存関係やリポジトリの問題に遭遇する可能性を最小限に抑えます。
sudoを使用する: パッケージ管理コマンドは常にスーパーユーザー権限で実行してください。
重要なデータをバックアップする: 主要なシステムアップデートやインストールを実行する前に、重要なデータをバックアップしてください。これは、何かがひどくうまくいかなかった場合のセーフティネットです。
問題を切り分ける: 複数のパッケージが失敗する場合は、それらを1つずつ更新またはインストールして、問題を引き起こしている特定のパッケージを特定します。
「yes」と入力する前に、提案されたトランザクションを読む: 削除は重要です。パッケージマネージャーがデータベースサーバー、カーネルパッケージ、SSHサーバー、またはコアランタイムを削除しようとしている場合は、停止して理由を理解してください。
forceフラグよりもリポジトリの修正を優先する: ほとんどのパッケージ障害は、メタデータ、リポジトリ、または依存関係の状態に起因します。forceフラグは症状を隠し、システムの保守を困難にする可能性があります。

最も安全なトラブルシューティングの順序は一貫しています。別の実行中のパッケージプロセスを確認し、メタデータを更新し、中断されたトランザクションを修復し、リポジトリを検査し、次に依存関係の競合に対処します。強制削除と署名バイパスは、影響範囲を理解し、ロールバックパスがある例外的な場合にのみ保存してください。