Linuxで壊れたパッケージを修復する方法【Ubuntu・Fedora・Arch対応】

APTやDNFといったLinuxのパッケージマネージャーは非常に強力で直感的に使えますが、だからといって問題が起きないわけではありません。時にはパッケージのインストールが失敗し、後処理に悩まされることもあるでしょう。幸い、パッケージマネージャーには壊れたパッケージを修復したり、問題のあるアップデートをスキップしてシステムを正常な状態に戻す機能が備わっています。この記事では、Linuxで壊れたパッケージを修復する方法を解説します。

ここで紹介するテクニックは、ほとんどの場面で役立つはずです。いずれも汎用的なものですが、状況はそれぞれ異なるため、自分の環境をデバッグする際にはその点を念頭に置いてください。

Ubuntu/Mint/Debianで壊れたパッケージを修復する

APTには、依存関係の欠落やインストール中に何らかの理由で壊れてしまったパッケージを修復するためのオプションがいくつか用意されています。よくあるケースとしては、サードパーティ製の.debファイルをインストールした際に、存在を知らなかった依存パッケージが必要になるというものです。こうした依存関係は自動では解決されず、dpkgが「パッケージが見つからない」とエラーを出します。そんなときは、以下の手順を試してみてください。

まず、必要なパッケージの新しいバージョンがないか確認するためにアップデートを実行します。

sudo apt --fix-missing update

次に、問題のあるパッケージを再度インストールしようとした際に、APTに対して不足している依存関係や壊れたパッケージを検索して修正させます。これにより、足りない依存パッケージが実際にインストールされ、既存のインストールも修復されます。

sudo apt install -f

パッケージインストールでエラーが発生するもう一つの場所が、設定（コンフィギュレーション）プロセスです。この部分は裏側でdpkgが担当しており、APTではありません。したがって、パッケージが設定段階で失敗した場合は、修復にはdpkgを使うのが理にかなっています。

まず、壊れている、または途中までしか設定されていないパッケージをdpkgに再設定させてみましょう。

sudo dpkg --configure -a

それでも問題が解決しない場合は、より強制的なアプローチを取ります。まず、dpkgが「再インストールが必要」とマークしたパッケージを一覧表示します。

sudo dpkg -l | grep ^..r

そこに問題のパッケージが表示されるはずです。明らかにおかしなものが含まれていないことを確認した上で、壊れたパッケージを強制的に削除できます。

sudo dpkg --remove --force-remove-reinstreq [パッケージ名]

dpkgの処理が終わったら、APTでクリーンアップを行います。

sudo apt clean
sudo apt update

うまくいけば、元の状態に戻せるはずです。インストールしようとしていた壊れたパッケージそのものは手に入りませんが、少なくともAPTは再び使えるようになり、改めてパッケージとその依存関係のインストールに挑戦できます。

DPKGのロックが解除されない場合

あまり一般的ではありませんが、dpkgのロックによって何も操作できなくなる問題もあります。APTやdpkgを使おうとするたびに「別のアプリケーションが使用中です」というエラーが出るのに、実際には何も動いていないという状態です。

実は、ロックファイルを削除すれば簡単に解決できます。インストールエラーや停電の後など、処理が中断されるとロックファイルが残ったままになり、自動的に削除されないことがあります。その場合は、自分で削除する必要があります。

sudo rm /var/lib/apt/lists/lock

ついでに、キャッシュ内のロックも削除しておきましょう。

sudo rm /var/cache/apt/archives/lock

Fedora/CentOS/RHELで壊れたパッケージを修復する

Fedora/CentOS/RHEL系で壊れたパッケージに遭遇することは比較的少ないです。yumやdnfはパッケージが正しくインストールされるよう細心の注意を払って動作するためです。しかし、それでもパッケージの管理中に不整合が起こることはあります。RPMベースのシステムで整合性をチェックするコマンドは以下の通りです。

sudo rpm -Va

-Vオプションは「verify（検証）」を意味し、インストール済みファイルの情報をrpmデータベースに保存されている情報と照合します。出力されるのは通常長いファイルリストなので少し扱いづらいですが、特定のアプリケーションで問題が発生している場合の出発点にはなります。リストの中で怪しいパッケージが見つかったら、dnf reinstallで再インストールしましょう。

sudo dnf --refresh reinstall パッケージ名

--refreshを付けるとすべてのメタデータが期限切れとして扱われ、有効化されている全リポジトリを走査してそのパッケージの新しいバージョンを探します。壊れた依存関係が見つかった場合、DNFは警告を表示し、--skip-brokenフラグの使用を促してくるかもしれません。これは、依存関係を取得するためのリポジトリが有効になっていないことを意味する場合もあるので、その点も調べてみてください。

Arch Linuxで壊れたパッケージを修復する

ArchのパッケージマネージャーはDebianのものと多くの共通点がありますが、まったく別の存在です。トラブルシューティングの第一歩は、リポジトリを最新の状態にしてフルアップグレードを試みることです。

sudo pacman -Syu

それでもパッケージのインストールやシステムアップグレードが失敗する場合は、ターミナルに表示されたメッセージに応じて原因を切り分けていきます。

「無効または破損したパッケージ」エラー

「pacman.conf」への変更は、pacmanがパッケージを誤って破損と判定する原因になることがあります。最も可能性が高い犯人は、パッケージマネージャーのキャッシュに残った部分ダウンロードファイル（「.part」ファイル）です。解決策は、これを削除することです。

sudo find /var/cache/pacman/pkg/ -iname "*.part" -delete

インストールしようとしているパッケージ自体が本当に破損しており、Archに有効なメタデータを提供できていない可能性もあります。その場合は、パッケージメンテナーによる更新を待つしかありません。すでにシステムにインストール済みで、アップグレード時に問題を引き起こしているパッケージであれば、以下のコマンドで削除できます。

sudo pacman -Rns [パッケージ名]

「データベースをロックできません」エラー

Debianのaptと同様に、Archのパッケージマネージャーも操作中にロックファイルを作成します。停電や、pacmanがロックを解除できないままハード割り込みを受けた場合、ロックファイルが残ってしまう可能性が高いです。

まず、そのファイルをまだ使用中のプロセスがコンピューター上に存在するかどうかを確認します。

sudo fuser /var/lib/pacman/db.lck

上の画像では、ID 121497のプロセスがロックファイルを使用しています。プロセスの詳細を知りたい場合は、psコマンドを使います。

ps -p [PID番号]

筆者の場合、別のpacmanインスタンスがロックファイルを保持していました。ロックを安全に解除するには、まずそのプロセスを終了させます。

sudo kill [PID番号]

プロセスが終了したら、ロックファイルを削除します。

sudo rm /var/lib/pacman/db.lck

これで作業を続行できるはずです。

「ファイルが競合しています／ファイルシステムにファイルが存在します」エラー

このエラーは、アップグレード中にpacmanが競合を検出した際に発生します。修正を始める前に、パッケージマネージャーが指摘しているファイルのパスを必ず確認してください。

最初に調べるべきは、そのファイルの所有者が誰かということです。

pacman -Qo [ファイルのパス]

所有者がユーザーであって別のパッケージではない場合は、単純に削除して構いません。

sudo rm [ファイルのパス]

別のパッケージが所有している場合は、最も安全な対応は、パッケージのメンテナーが競合を自ら修正するのを待つことです。しかし、それが待ちきれないこともあるでしょう。

最も手っ取り早い方法は、pacmanの--overwriteフラグを使うことです。ただし、これは一般的に安全とは言えず、一部のアプリケーションが正しく動作しなくなる可能性がある点に注意してください。実行前にバックアップを作成することをおすすめします。

--overwriteフラグを使うと、Archのパッケージマネージャーは特定のファイルの所有権ルールを無視し、強引にアップデートを進めます。例：

pacman -Syu --overwrite [ファイル名]

上記のコマンドがうまく動作しない場合は、ファイル名を絶対パスに置き換えてください。パス先頭のスラッシュ（「/」）を外すとコマンドが通るようになった、という報告もあります。

よくある質問

1. Arch向けの修復方法はAURヘルパーでも使えますか？

基本的には使えます。ガイド内のコマンドの「pacman」を、お使いのAURヘルパーに置き換えるだけです。例：

yay -Qo /path/to/file

2. これらの手順は安全ですか？

ほとんどの場合、ここで紹介している手順は、他のパッケージ管理操作と同程度に安全です。大きな例外は、ロックファイルを削除する場合です。可能であれば、ロックファイルを削除する前に、それを使用している可能性のあるプロセスを必ず終了させてください。常にシステムの状態を把握しておきましょう。どこかでaptやpacmanのインスタンスが動いたままになっていることに気づいていないかもしれません！

ベストプラクティスとしては、アップグレードの前に必ずシステムのバックアップを取ることです。

3. アップデートを中断してしまった場合はどうすればいいですか？

Ctrl + Cの入力、パッケージマネージャーのプロセスの強制終了、ターミナルの早期終了などでアップデート処理を中断すると、パッケージデータベースに何らかの破損が生じ、後で別のものをインストールしようとしたときに問題が複雑化することがあります。これを修復するには、キャッシュをクリアしてアップデートをやり直します。

Debian/Ubuntu/Mint/Pop!_OSなどの場合：

sudo apt-get clean

Fedora/CentOS/RHELの場合：

sudo dnf clean all

Archの場合：

sudo pacman -Scc

まとめ

ここで紹介した修復方法のどれかが役に立ち、Linuxシステムを通常通り使えるようになっていれば幸いです。完全に手に負えなくなった状況に対処する最善の方法は、元の状態に戻そうとすることだと覚えておいてください。何をしているのか正確に理解していない限り、さらに要素を追加して問題を解決しようと無理に進めるのは避けましょう。そうすると、壊れたものが絡み合った泥沼に陥り、かえって整理が難しくなる可能性が高いです。

また、不要になったパッケージや壊れたパッケージを取り除くために、Linuxシステムのクリーンアップが必要になることもあります。原因が古いPCで新しいソフトウェアをサポートできないことにあるなら、「古いPCを有効活用する3つの方法」も参考にしてみてください。