Linux: apt が壊れたときに dpkg を使用して修正する方法

あなたはアパートを壊したことがありますか？経験豊富な Linux プロフェッショナルにとって、意図せずに適切な機能を壊してしまうことはよくあります (約半年ごと)。 dpkg のいくつかのコマンドを知っていれば、多くの場合、より簡単に問題を解決できます。方法を見つけます。

apt と dpkg とは何ですか?

Ubuntu や Mint などの Debian ベースのディストリビューションを使用している場合、コンピュータは apt を使用してパッケージを処理します。 Apt は Advanced Packaging Tool の略で、Debian パッケージのインストール、アンインストール、パージ、管理を可能にします。

apt (コマンド ラインで使用) に加えて、コンピューターにはおそらく、バックグラウンドで apt 、またはおそらく dpkg 使用する、より高レベル/包括的なデスクトップ ベースのパッケージ マネージャーが搭載されています。

Debian dpkg のパッケージ マネージャーは、Debian ベースのインストールでパッケージを管理するための代替手段です。これは apt よりもはるかに低レベルであり、より自由度が高くなりますが、機能を壊すリスクも高くなります。

これが、(経験豊富な DevOps エンジニアでない限り) apt 常に使用し、問題が発生したらすぐに dpkg で強化することをお勧めする理由です。

この段階的なアプローチを採用すると、必要に応じて apt パッケージ マネージャーの安定性と使いやすさ、そして dpkg Debian パッケージ マネージャーの強力さと粒度の両方の利点を得ることができます。

たとえば、インストールしたばかりのパッケージがあり、何らかの理由で apt 壊れてしまったとします。あるいは、パッケージのインストールが誤って中断された可能性があります。

原因が何であれ、 apt 現在壊れているとみなされており、すでに次のようなことを試しています。

 sudo apt update --fix-missing

そして

sudo apt install --fix-broken

無駄に。もしそうなら…

dpkg へようこそ

apt が壊れてしまったら、面白くありません。本当に壊れてしまったら、さらに面白くなくなります。たとえ誰かが自分が何をしているのかを知っていたとしても、壊れたパッケージングシステムを修復するには、ある程度のレベルの芸術、そして間違いなくスキルが必要な場合があります。

「アート」という用語は非常に当てはまります。さまざまなトラブルシューティング手順を実行しているときに、特にこれを頻繁に実行している場合には、再起動中に何かがうまくいくかどうかの感覚や感覚が得られるからです。

リスクは常に、パッケージング システムがひどく壊れているため、再起動すると Linux インスタンスが再起動しなくなる可能性があり、さらに複雑なトラブルシューティングが必要になる可能性があります。

この時点では、これらすべてはいくつかの簡単なコマンドを実行することで簡単に回避できると言いたいのですが、残念ながらそうではありません。実際、知識が増えるほど修正が容易になり、システムを再起動する準備ができているかどうかを判断する自信が高まります。

ここで dpkg が登場します。 dpkg プログラムを使用すると、インストールされているすべてのパッケージをより詳細に制御できるようになり、何か問題が発生するリスクが高くなりますが、希望どおりにシステムを変更するための機能も大幅に強化されます。飛び込んでみましょう。

Linux 全般に興味がある場合は、 Bash オートメーションとスクリプトの 3 部構成シリーズ もお読みください。

基本的な dpkg の 使用法

次を実行するだけで、現在システム上にあるパッケージを確認できます。

 dpkg -l

。出力は非常に冗長になる可能性が高いため (通常はページ分割されていますが)、

 grep

結果を制限するためです。

 dpkg -l | head -n5 && dpkg -l | grep 'gnome-calculator'

dpkg -l | grep ‘gnome-calculator’

最初のコマンドは実際には 2 つのコマンドを組み合わせたものです ( && で区切られています。これは文字通り、最初のコマンドが成功した場合にのみ 2 番目のコマンドを実行することを意味します)。

これら 2 つのコマンドのうちの最初のコマンドでは、最初の 5 行を取得し (パイプ | と head -n5 を使用)、次に 2 番目のコマンドで、検索している出力をリストします。この場合、テキスト gnome-calculator を検索します。

その下の 2 番目の行/コマンドは、通常使用するバージョンを示しています。 dpkg 出力の構文に慣れると、最初の 5 行は多くの場合不要になります。最初の列は (視覚的に) Desired= を参照し、2 番目の列は Status= を参照し、3 番目の列は Err?= を参照していることに注意してください。線を視覚的にたどってみると、それらがどのように素早くつながっているかがわかります。

gnome-calculator 現在エラーなく正常にインストールされているため、 Err?= の下に 3 番目の列コードはありません。ここで、3 番目の列に関連する短い情報に uppercase=bad が書かれていることにも注意してください。前述したように、この場合は空白です。

最初の列は望ましいステータスを示し、2 番目の列は現在のステータスを示します。どちらも i (それぞれ Install[ed] と Inst[alled] と表示され、これ ( ii ) が最も一般的に表示される (表示される) シーケンスです。これは基本的に everything is fine, that the package is installed, and that there are no issues 意味します。 everything is fine, that the package is installed, and that there are no issues 。

また、括弧内の列の説明では、大文字が、表示される可能性のある文字と関連する用語との関係を示していることに注意してください。たとえば、 f halF-conf をどのように参照するかを考えてみましょう。同じ大文字の F に注目してください。

次に、比較する別の出力を見てみましょう。今回は最初の 5 行を省略します。ヘッダーなしでも出力を読むことにもう少し慣れることができます。

 dpkg -l | grep 'ミントウェルカム'

ここで、 rc の興味深い結果がわかります。ここで、 ii gnome-calculator のものでした。上で見た最初の Desired= 列の説明で r を検索すると、それが Remove[d] を表し、2 番目の列の c が Conf-files を表すことがわかります。

ああ！これ ( mintwelcome 、Mint のウェルカム パッケージ) は、ある時点でアンインストールしたパッケージですが、同じ構成ファイルはまだ残っています。粛清しましょう！

 dpkg --purge 'mintwelcome'

sudo dpkg –purge ‘mintwelcome’

dpkg -l | grep ‘ミントウェルカム’

--purge を使用する代わりに -P 短縮表現を使用することもできることに注意してください。

最初のコマンドでは、 sudo 使用せずに mintwelcome をパージしてみます。ただし、これではうまくいきません。パッケージをアンインストール (またはインストールまたはパージ) するには、スーパーユーザー/root レベルの権限が必要です。 sudo を使用して再度実行すると、パッケージがパージされます。

パージ という用語は、 apt と dpkg の両方で使用され、パッケージを単にアンインストールするのではなく、パッケージを完全にパージして構成ファイルを残しておきたいことを示すことに注意してください。

確かめる

Debian ベースのディストリビューション (Ubuntu (この場合は Mint) など) でパッケージを管理する際に、 dpkg 提供する機能、制御性、粒度の良さを理解できるようになると思います。たとえば、次のコマンドを実行するだけで、以前にアンインストールしたパッケージの残りの構成ファイルをスキャンするのは簡単です。

 dpkg -l | grep '^rc'

このような構成ファイルを削除する前に、類似した名前のパッケージがインストールされていないことを再確認してください。たとえば、この場合は次のように実行できます。

 dpkg -l | grep 'JavaScript'

'javascript' を検索するために 'javascript-common' の 2 番目の部分を削除した方法に注目してください。

削除しても安全かどうか?人生において常にそうであるように、大きな力には大きな責任が伴うことがわかります。それを削除するかどうかの決定はあなた次第です。一般に、 dpkg を使用するときに常に念頭に置いておかなければならないことが 3 つあります。

まず 、確実にチェック、ダブルチェック、トリプルチェックを行う必要があります。たとえば、上記の最初の出力では、システム上に他の JavaScript パッケージがあるかどうかを確認せずに、そのまま javascript-common を削除してしまった可能性があります。

それは最善の行動でしたか？おそらくですが、システム上に他の Javascript パッケージが存在することは間違いないため、最初のチェックを行うとすぐに確実性/信頼度は確実に下がりました。

また、実際には何も壊れていないことに注意してください。この削除されたように見えるパッケージの構成ファイルはそのままにしておいても問題ありません。 「壊れていないなら、直す必要はない」という古い格言は、このケースにも確実に当てはまります。 dpkg を使用する場合は、これを覚えておくと良いでしょう。

次に 、 apt 、パッケージをインストール、アンインストール、またはパージするときに、パッケージ間のすべての接続 (つまり、バージョンと依存関係) を 念頭に置く パッケージ マネージャーであることを覚えておくことが重要です。

これは、よりパッケージベースである dpkg には当てはまりません。粒度は高くなりますが、壊れるリスクも高くなります。パッケージが別のパッケージまたはライブラリに依存している場合、誰かが dpkg を使用してメイン パッケージをアンインストールするだけで必ず問題を壊します。

第三に 、ほとんどの Linux パッケージには 多くの 依存関係があります。したがって、単に標準のパッケージ管理に dpkg を使用することは推奨されません。デフォルトで apt を使用し、必要に応じて dpkg に切り替えるという当初のアドバイスを繰り返します。

パッケージをパージするのではなく (つまり、構成ファイルを残す) 削除/アンインストールするには、 dpkg に --remove (または -r ) オプションを使用できます。パッケージを検証するには、 --verify (または -V ) を使用します。パッケージに対する --audit (または -C ) オプションは、パッケージ (またはパッケージが指定されていない場合はすべてのパッケージ) のデータベースの健全性と整合性チェックを実行します。

その他のオプションについては、ターミナルから実行される man dpkg を参照してください。さまざまなパッケージング システムの問題に使用できる、より複雑な具体的なコマンドもあります。これらの場合、通常は、特定の問題や発生時の状況に応じたお気に入りの検索エンジンを使用するのが最善です。多くの場合、他の誰かがすでにそれに遭遇し、詳細を文書化しています。何か新しいことを発見した場合は、数分かけてフォーラムまたは関連するディスカッション スレッドに発見内容を記録してください。

まとめ

この記事では、パッケージとそのすべての依存関係を処理する apt とは異なり、 dpkg がきめ細かなパッケージ管理にどのように役立つかを検討し始めました。このような複雑なパッケージ管理問題のデバッグ状況では、大きな力には大きな責任が伴うことを忘れないでください。

また、パッケージ管理の詳細なデバッグは芸術に似ており、ペインターが優れているほど、ペインティングがより成功することを認識しながら、よりリスクを回避したアプローチに従う方法についても検討しました。ああ、リブートは成功するでしょう。