web-dev-qa-db-ja.com

不正な更新の後に、yumパッケージを安全に修復するにはどうすればよいですか？

EC2マイクロボックスでAmazon linuxを実行しています。最近、Heartbleedにパッチが当てられることを期待してSudo yum update --securityを実行しました。残念ながら、アップデートプロセス中にメモリが足りなくなり、一部のパッケージは正常にパッチされませんでした。以下のペーストビンに示すように、再起動してSudo yum clean、次にSudo yum updateを実行することでこれを修正しようとしましたが、依存関係の問題がまだ残っています。

これ以上何も壊さずにこれを修正するにはどうすればよいですか？

以下は、yumの出力からの抜粋です。

Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.i686
Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.x86_64
Error: Package: glibc-devel-2.12-1.107.43.amzn1.x86_64 (@amzn-main)
           Requires: glibc-headers = 2.12-1.107.43.amzn1
           Removing: glibc-headers-2.12-1.107.43.amzn1.x86_64 (@amzn-main)
               glibc-headers = 2.12-1.107.43.amzn1
           Updated By: glibc-headers-2.17-36.81.amzn1.x86_64 (amzn-updates)
               glibc-headers = 2.17-36.81.amzn1
           Available: glibc-headers-2.17-36.80.amzn1.x86_64 (amzn-main)
               glibc-headers = 2.17-36.80.amzn1

次に、完全なコンソールログを示します。 http://sebsauvage.net/paste/?e0f7235450f97bae#qq6QKe/Co+jR2T4FXfGo4w2H8aw7xZkE4z+iZXdMpQ8=

amazon-ec2yumdependencies
5
Plato

失敗したRPMSを再インストール

この問題は、RPMトランザクション中に何かが失敗したときに発生することを確認しました。 RPMデータベースがシステムと同期しなくなる可能性があります。その結果、システムが実際に持っているものとRPMがインストールされていると考えているものは異なります。

ヒント：これを実行する前に、AMIイメージを作成してください。完全に障害が発生した場合に簡単に回復できます。

rpm -qa --lastを使用して、最近インストールされたRPMのリストを取得できます。

次に、rpmデータベースrpm --rebuilddbを再構築します。

次に、yum reinstallを使用して、失敗したトランザクションの一部であったパッケージを再インストールできます。

これにより、依存関係の問題も検出され、修正が試みられます。

場合によっては、rpmをダウンロードしてyum downloadをインストールし、rpmを使用してインストールを実行することで、競合を手動で解決する必要がありました。

rpmを使用して手動インストールに戻す必要がある場合は、特にglibcが関係している場合は、詳細なメモを残してください。

推奨

新しいEC2インスタンスを簡単に起動でき、そのような問題を心配しない方法でAWSにオペレーションをデプロイすることを強くお勧めします。データに専用のEBSボリュームを使用し、構成ファイルを別の場所に保存すると、新しいインスタンスを起動して、このようなRPMの問題をデバッグするよりも早く操作に戻ることができます。このようなEC2の問題が発生した場合、通常はカスタムAMIから新しいインスタンスをデプロイし、IPを再マッピングしてそれで完了します。必要に応じて、本番運用に影響を与えることなく、障害/破損したシステムの根本原因分析を行うことができます。

3
jeffatrackaid