はじめに
実際に業務でも発生したのだが、/etc/fstab
の設定内容を誤って設定してしまい、EC2のインスタンスが起動しなくなった!ということがあったので、復帰の手順を忘れないように記載しておく。
環境
Windows 10 Professional
AWS EC2 (t4g.nano)
シチュエーション
下記のような状況でのシミュレーションを行う。
- AWS EC2インスタンスを作成
/etc/fstab
を誤った設定で書いてしまった!
準備
シチュエーションを再現するためにインスタンスを作成する。
EC2インスタンスの作成
項目 | 設定値 |
---|---|
名前 | web-server |
OS | AmazonLinux2023 AMI |
アーキテクチャ | 64ビット(Arm) |
インスタンスタイプ | t4g.nano |
キーペア | web-server(新規で作成) |
セキュリティグループ | ssh (自分のIPのみ) |
ストレージ | 8GB (gp3) |
SSHログイン
, #_
~\_ ####_ Amazon Linux 2023
~~ \_#####\
~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
[ec2-user@ip-172-31-43-8 ~]$
ログインできる。
swapファイルを作成する
2GBのスワップファイルを作成する。
sudo dd if=/dev/zero of=/swap bs=1M count=2048
sudo chmod 600 /swap
sudo mkswap /swap
実行結果↓
[ec2-user@ip-172-31-43-8 ~]$ sudo dd if=/dev/zero of=/swap bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 15.1352 s, 142 MB/s
[ec2-user@ip-172-31-43-8 ~]$ sudo chmod 600 /swap
[ec2-user@ip-172-31-43-8 ~]$ sudo mkswap /swap
Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=df4e1838-5778-4dc1-8c67-94fb27364000
スワップを有効にする。
sudo swapon /swap
下記で確認する。
swapon -s
[ec2-user@ip-172-31-43-8 ~]$ swapon -s
Filename Type Size Used Priority
/swap file 2097148 0 -2
[ec2-user@ip-172-31-43-8 ~]$
free -m
[ec2-user@ip-172-31-43-8 ~]$ free -m
total used free shared buff/cache available
Mem: 428 128 15 0 283 289
Swap: 2047 0 2047
誤ったエントリを作成する
/etc/fstab
に下記を追記する。
UUID=df4e1838-5778-4dc1-8c67-94fb27364000 /swapdummy swap swap defaults 0 0
再起動後、起動しないことを確認する
sudo reboot
復帰手順
下記を参考にレスキューインスタンスの作成および復帰を行う。
https://repost.aws/ja/knowledge-center/ec2-linux-emergency-mode
レスキューインスタンスを作成する
項目 | 設定値 |
---|---|
名前 | rescue-web-server |
OS | AmazonLinux2023 AMI |
アーキテクチャ | 64ビット(x86) |
インスタンスタイプ | t2.micro |
キーペア | web-server |
セキュリティグループ | テストで作成したものと同じ |
ストレージ | 8GB (gp3) |
※アベイラビリティゾーンは同一にすること
レスキュー対象のインスタンスを停止する
- EC2コンソールから、対象のインスタンスを選択する。
- インスタンスの状態 > インスタンスを停止を選択する。
レスキュー対象のボリュームをデタッチする
デタッチしたボリュームをレスキューインスタンスにアタッチする
ボリュームのアタッチを選択する
レスキューインスタンスにSSHで接続する
, #_
~\_ ####_ Amazon Linux 2023
~~ \_#####\
~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
[ec2-user@ip-172-31-41-58 ~]$
接続できた!
ボリュームのマウント
lsblk
でボリュームがアタッチされているかを確認する。
lsblk
結果↓
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
xvda 202:0 0 8G 0 disk
├─xvda1 202:1 0 8G 0 part /
├─xvda127 259:0 0 1M 0 part
└─xvda128 259:1 0 10M 0 part
xvdf 202:80 0 8G 0 disk
├─xvdf1 202:81 0 8G 0 part
└─xvdf128 259:2 0 10M 0 part
xvdf
ボリュームがアタッチされていることが確認できる。
ボリュームのマウント
レスキュー対象のボリュームをマウントするディレクトリを作成する。
sudo mkdir /mnt/rescue
レスキュー対象のボリュームをマウントする。
sudo mount /dev/xvdf1 /mnt/rescue
マウントできていることを確認する。
[ec2-user@ip-172-31-41-58 /]$ ls /mnt/rescue/
bin dev home lib64 media opt root sbin swap tmp var
boot etc lib local mnt proc run srv sys usr
対象のファイル(/etc/fstab)を編集する
/etc/fstab
を修正する。
sudo vi /mnt/rescue/etc/fstab
対象の行を修正する。
#
UUID=6bc0fdc0-ccc5-4301-89d9-b7a2cd0a2c67 / xfs defaults,noatime 1 1
UUID=23EC-AB0C /boot/efi vfat defaults,noatime,uid=0,gid=0,umask=0077,shortname=winnt,x-systemd.automount 0 2
-UUID=df4e1838-5778-4dc1-8c67-94fb27364000 /swapdummy swap swap defaults 0 0
+/swap swap swap defaults 0 0
アンマウントをして作業を終了する。
sudo umount /mnt/rescue
レスキューインスタンスからボリュームのデタッチ
※先程と同じ手順で、今度はレスキューインスタンスをもとに戻す。
rescue-web-server
の ボリュームのデタッチをする。
vol-06ad11b0a9a360d57
を選択する。
- ボリュームを選択し、アクション > ボリュームのデタッチ を選択する。
- デタッチを選択する。
対象のインスタンスにボリュームをアタッチして元に戻す
- デタッチしたボリュームを対象のインスタンス(web-server)にアタッチする。
- ボリュームのアタッチをする。(デバイス名はルートデバイス名にすること)
※デバイス名がルートデバイスでないとインスタンスの起動ができないので注意
確認
レスキュー対象のインスタンスを起動する。
SSHで接続できることを確認する。
, #_
~\_ ####_ Amazon Linux 2023
~~ \_#####\
~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
Last login: Fri Aug 18 22:01:13 2023 from XXX.XXX.XXX.XXX
- swapの確認
[ec2-user@ip-172-31-43-8 ~]$ free -m
total used free shared buff/cache available
Mem: 428 128 42 0 257 288
Swap: 2047 0 2047
/etc/fstab
が正常に機能していることが確認できる。
後始末
レスキューインスタンスを終了して削除する。
参考
EC2 Linux インスタンスが起動せず、緊急モードになるのはなぜですか?
https://repost.aws/ja/knowledge-center/ec2-linux-emergency-modeAmazon EBSマウント時の「wrong fs type, bad option, bad superblock on…」というエラーを解決する方法を教えてください
https://dev.classmethod.jp/articles/tsnote-how-to-fix-ebs-filesystem-has-duplicate-uuid/
おわりに
業務でも実際に起きたので備忘録として書き残した。
EC2のシリアルコンソールを使う方法はよく分からず、うまく直せなかったのでレスキューインスタンスを使用する方法を取った。
起動しない原因がわかっているときは、これで解決できるがわからない場合はどうするのが良いのだろうか。
→ シリアルコンソールつなてログを見るとか、システムログの取得とかをすれば良さそう?
今後はミスって起動しなくなったということは起きないようにしたい…。