スナップショットによる修復後、EC2 AmznLinux2 インスタンスにアクセスできない

スナップショットによる修復後、EC2 AmznLinux2 インスタンスにアクセスできない

EC2 の経験がある人がいたらいいのですが。困っています。

誤って Amazon Linux 2 インスタンスから glibc を削除してしまいました。まったくの偶然というわけではなく、持っていたものを公式の Amzn2 リポジトリ パッケージに置き換えようとしていたのです (以前、rpm 経由で手動でアップグレードしようとしていました)。

以前にもやったことがありますが、次のガイドに従いました:https://www.rootusers.com/how-to-repair-an-aws-ec2-instance-without-console/

新しい Amazon Linux 2 インスタンスを作成し、作成したスナップショットから新しいボリュームをマウントし、dev/nvme1n1p1 をマウントして chroot しました。glibc と yum を修復しました。yum distro-sync を実行しました (現在は問題は残っていません)。すべてを慎重にアンマウントしました。インスタンスをシャットダウンしました。新しいスナップショットを作成しました。そのスナップショットから新しいボリュームを作成しました。そのボリュームを最初の (壊れた) インスタンスに dev/xvda としてマウントしました。そして、動作しません。1/2 のシステム チェックに合格しましたが (非常に長い時間が経過した後のように)、アクセスできません。カーネル ログを調べましたが、異常は見つかりませんでした。Elastic IP の再接続を試みました。

修復後、固定ボリュームを一時インスタンスに直接ルートとしてマウントしようとしました。それでもうまくいきませんでした。スナップショットから AMI を作成しようとしました。どうしたらよいか分からないので、ご協力いただければ幸いです。

答え1

さて、ホストも Amazon Linux 2 インスタンス (つまり同じアーキテクチャ) であるにもかかわらず、Amazon Linux 2 インスタンスに chroot する際に問題が発生する場合は、不足しているライブラリを /mnt/lib64 にコピーするだけです。修復にそのディレクトリが必要な場合は、マウントしないことが重要です。

例えば# cp -n /lib64/* /mountpoint/lib64/

関連情報