背景#
- オペレーティングシステム：Amazon Linux 2023
- インスタンスタイプ：t2.micro
EC2 に新しいボリュームをマウントしようとしましたが、インスタンスを再起動するとマウントしたボリュームが見つからないことに気づきました。その後、自動マウントの方法をインターネットで検索しました。/etc/fstabファイルを変更して再起動してみましたが、SSH 接続ができなくなり、ログを確認したところ、緊急モードに入っていることがわかりました... 対話画面にも入ることができませんでした。「最初の試みで壊してしまいました」
最初はプロキシの問題だと思っていましたが、閉じても接続できませんでした
システムログを開く
しかし、AWS には起動に失敗した場合の解決策が用意されており、小さな文字が表示されています
結果
最初はドキュメントを見て、どのタイプがサポートされているかを調べて、インスタンスタイプを変更しましたが、なぜかまだ接続できませんでした... 最終的には、壊れたファイルを修正するために、復旧用のインスタンスを一時的に起動する方法を見つけました。
復旧方法#
基本的には以下の手順に分かれます
- 起動に失敗したインスタンスを停止する
- 起動に失敗したインスタンスからルートボリュームを分離する
- 同じリージョン内で新しい EC2 インスタンスを作成する
- ルートボリュームを新しいインスタンスにマウントする
/etc/fstabファイルを変更する
インスタンスの停止#
停止が完了するまで待ちます。目的はボリュームを分離するためです
ボリュームの分離#
ルート「/」ディレクトリにマウントされているボリュームを見つけ、分離をクリックします
新しいインスタンスの起動#
設定は最も基本的なもので十分です。目的は、先ほど分離したボリュームをマウントすることです
サブネットを指定することを忘れないでください。「ボリュームと同じアベイラビリティーゾーンを選択するためです。私の場合は us-west-1b です」
ボリュームのマウント#
AWS 管理コンソールで、先ほど分離したボリュームを新しいインスタンスにマウントし、新しいインスタンスに SSH で接続します
ここで、先ほど修正した内容が表示されます
vim を使用して fstab ファイルを直接変更し、修正が完了したらボリュームを分離し、起動できなかったインスタンスにマウントします。マウントする際には、名前に xvda を入力することに注意してください。「以前と同じで、私が見ている AWS のデフォルトのルートボリュームはこの名前です」
最後に、古いインスタンスを起動し、新しく作成したインスタンスは削除できます
成功！