fstabの記述を間違えてEC2に接続できなくなったのでトラブルシューティングしてみた

EC2にEBSを追加でマウントしたときにfstabの設定を行いました。
その際に記述方法を間違えて接続できなくなってしまったのでトラブルシューティングをしてみました。

異変に気が付く前にやっていたこと

EC2が接続できなくなる前にやっていたのはEBSの追加マウント検証でした。
EBSの追加については以下のドキュメントの手順で行っていました。
インスタンスへの Amazon EBS ボリュームのアタッチ
Linux で Amazon EBS ボリュームを使用できるようにする

上記のドキュメントに/etc/fstabの設定についても記載されていたのでコピーしてペーストを行い、必要な部分を書き換えていたのですが、何かの拍子に必要のない部分まで書き換えてしまったので再起動後に接続できなくなりました。

再起動後にいつも通りSession Managerで接続しようと思ったのですが、中々接続できるようにならなかったので異変に気が付きました。

異変に気が付いた後にやったこと

異変に気が付く前に行っていた作業が作業なので原因的にはマウント周りだろうなと当たりは付けていました。
具体的に何が悪かったのかまでは把握していなかったので、まずはそこを把握することから始めました。
/etc/fstabに記載された内容は起動時にマウントされるので、システムログを確認すれば何かしらわかると思い以下のドキュメントの手順でマネジメントコンソールからログを確認しました。
インスタンスコンソール出力

確認すると以下のログが出ていました。
どうやらパラメータの部分にミスが発生しているようです。

[    5.766219] xfs: Unknown parameter 'defaults/nofail'
[[0;1;31mFAILED[0m] Failed to mount [0;1;39mdata.mount[0m - /data.
[[0;1;38;5;185mDEPEND[0m] Dependency failed for [0;1;39mloca…s.target[0m - Local File Systems.
[[0;1;38;5;185mDEPEND[0m] Dependency failed for [0;1;39mseli… the need to relabel after reboot.

問題が分かったので直してみる

どこが問題になっているのか分かったので修正を行います。
現状のEC2には接続が出来ないのでEBSをデタッチして他のEC2からマウントして/etc/fstabを修正してみました。
この方法以外にもトラブルシューティング方法はいくつかあるので以下のドキュメントを確認してみてください。
EC2 Linux インスタンスが起動せず、緊急モードになるのはなぜですか?

EBSをデタッチする

まずはルートボリュームになっているEBSをデタッチします。
デタッチは以下のドキュメントの方法で行いました。
Linux インスタンスから Amazon EBS ボリュームをデタッチします。

問題が発生しているEC2を停止して以下のAWS CLIコマンドを実行します。

aws ec2 detach-volume --volume-id ルートボリュームのID

コマンドの実行が成功すると以下のレスポンスが確認できます。

{
    "AttachTime": "2023-06-20T11:40:36+00:00",
    "Device": "/dev/xvda",
    "InstanceId": "デタッチしたインスタンスID",
    "State": "detaching",
    "VolumeId": "デタッチしたボリューム ID"
}

レスキュー用EC2にEBSをアタッチ

このレスキュー用のEC2は問題が発生しているEC2と同じアベイラビリティゾーンで起動している必要があります。

EBSのアタッチは以下のコマンドを実行します。

aws ec2 attach-volume --device /dev/sdh --instance-id インスタンスID --volume-id ボリュームID

コマンドの実行に成功すると以下のレスポンスが確認できます。

{
    "AttachTime": "2023-06-20T13:38:33.477000+00:00",
    "Device": "/dev/sdh",
    "InstanceId": "アタッチしたインスタンスID",
    "State": "attaching",
    "VolumeId": "アタッチしたボリュームID"
}

レスキュー用EC2でEBSをマウント

EBSはアタッチしただけではマウントされないので自分でマウントを行います。
EC2にSSHもしくはSession Managerなどを使用して接続してください。
接続したら以下のコマンドを実行してマウントポイントを作成します。

sudo mkdir /mnt/rescue

次に以下のコマンドでEBSのデバイス名を確認します。

sudo lsblk -f

以下のNAME列がデバイス名です。

NAME      FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
xvda
├─xvda1   xfs          /     0e39c519-1802-45f1-9bf8-61f5bbd358bd    6.4G    19% /
├─xvda127
└─xvda128 vfat   FAT16       ECFE-5555
xvdh
├─xvdh1   xfs          /     0e39c519-1802-45f1-9bf8-61f5bbd358bd
├─xvdh127
└─xvdh128 vfat   FAT16       ECFE-5555

デバイス名が確認できたら以下のコマンドでマウントを行います。
オプションで「-o nouuid」を付けているのはUUIDが同じものになっているからです。
UUIDが一緒の場合マウント時にエラーが発生するので無視するようにしています。

sudo mount /dev/xvdh1 /mnt/rescue -o nouuid

マウントが出来たら/etc/fstabを修正します。
以下のコマンドでファイルを開いて問題個所を編集してください。

sudo vi /mnt/rescue/etc/fstab

修正が完了したら以下のコマンドでアンマウントします。

sudo umount /mnt/rescue

レスキュー用EC2からEBSをデタッチする

ファイルの修正が完了したらレスキュー用EC2からEBSをデタッチします。
デタッチは「EBSをデタッチする」で実行したコマンドと同じようにdetach-volumeコマンドを使用します。
ボリュームIDは「EBSをデタッチする」で指定したIDと同じものになります。

aws ec2 detach-volume --volume-id ボリュームID

EBSをアタッチする

EBSをデタッチ出来たら元のEC2にアタッチします。
EBSのアタッチは「レスキュー用EC2にEBSをアタッチ」で使用したattach-volumeコマンドを使用します。
インスタンスIDは元のEC2のIDを指定してください。

aws ec2 attach-volume --device /dev/xvda --instance-id インスタンスID --volume-id ボリュームID

EC2の接続確認

EC2にEBSがアタッチ出来たら起動させます。
以下のコマンドを実行してください。

aws ec2 start-instances --instance-ids インスタンスID

起動後、しばらくしたらSSHやSession Managerで接続できることが確認できます。

さいごに

今回の手順はfstabのミスだけでなく接続できなくなったEC2の調査に使用できるのでやり方を覚えておくと緊急時に焦らないでスムーズに作業が行えると思います。