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