rpm データベースが破損する理由
rpm データベースの破損につながる可能性がある複数の理由が考えられます。制限があるため、単一の RCA を正確に特定することはできません。rpm データベースの破損を監視するメカニズムはありません。
– 管理者/一部のプロセスが rpm コマンドを実行するたびに、rpm データベースが照会されます。
– yum トランザクション中でも、rpm データベースは大幅に変更されます。
– 小さなポインタもこのような破損を引き起こす可能性があります。
– LD_LIBRARY_PATH が何らかの値に設定されている場合、rpm データベースでさえ破損します。
– rpm データベースに不要な変更を引き起こすサードパーティ製パッケージがインストールされている場合。
– 不完全なトランザクションもこのような破損につながる可能性があります。
– SAN ボリュームにある /var パーティションの場合。
したがって、合計すると、このような rpm データベースの破損には多くの要因が考えられます。 rpm データベースが頻繁に破損する場合は、cron を使用して RPM データベースを頻繁にバックアップすることをお勧めします。
RPM データベースを修復する
RPM ツールは、独自のカスタム データベース実装を使用して情報を格納します。場合によっては、そのデータベースが破損することがあります。症状には、インストールされている RPM パッケージが見つからないという主張が含まれます。または、RPM を更新しようとするとハングアップします。一部のパッケージを照会 (rpm -q) しようとすると、以下のエラーで失敗する場合があります。
rpmdb: /var/lib/rpm/Packages: unexpected file type or format error: cannot open Packages index using db3 - Invalid argument (22)
RPM データベースがハングまたは破損している場合は、これらのコマンドを使用して修復を試みることができます。注意:このプロセスは動作を保証するものではありません。これらの手順では、スーパーユーザー権限 (別名「root」) でログインする必要があります。コマンドはルート ターミナル ウィンドウに直接コピー アンド ペーストできます。
1. システムで実行中の RPM プロセスが残っていないことを確認します。それらを識別するには、ps コマンドを使用します。 kill コマンドを使用して、見つけた「rpm」プロセスをすべて終了します。 「kill -9」が必要な場合があります。
# ps -ef | grep-i rpm
2. RPM が使用するロック ファイルを削除します。
# rm -f /var/lib/rpm/__db*
# /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages
3. 「rpm」コマンドがハングする場合は、もう一度試してください。それが機能する場合は、終了です。そうでない場合は、手順 1 と 2 をもう一度実行します。次に、次のステップに進みます。
4. RPM データベースのバックアップを作成します:
# cd /var/lib # mkdir rpm-backup # rsync -av ./rpm/. ./rpm-backup/.
5. RPM データベースを再構築します:
# rpm -vv --rebuilddb > /tmp/rpmrebuilddb.log 2>&1
6. rpm データベースをもう一度検証してみてください。
# cd /var/lib/rpm # /usr/lib/rpm/rpmdb_verify Packages注意 :上記の回復手順が失敗するか、エラーがスローされる場合は、最新のシステム バックアップから /var/lib/rpm ディレクトリを復元することが最善の選択肢である可能性があります。 tar バックアップはまだ価値がある可能性があるため、上書きしないことを忘れないでください。
6. 失敗した RPM コマンドを再試行してください。
パッケージを照会、インストール、削除、およびアップグレードするための RPM コマンドの例