はじめに

実際に業務でも発生したのだが、/etc/fstabの設定内容を誤って設定してしまい、EC2のインスタンスが起動しなくなった！ということがあったので、復帰の手順を忘れないように記載しておく。

環境

1
2

Windows 10 Professional
AWS EC2 (t4g.nano)

シチュエーション

下記のような状況でのシミュレーションを行う。

  • AWS EC2インスタンスを作成
  • /etc/fstab を誤った設定で書いてしまった！

準備

シチュエーションを再現するためにインスタンスを作成する。

EC2インスタンスの作成

項目設定値
名前web-server
OSAmazonLinux2023 AMI
アーキテクチャ64ビット(Arm)
インスタンスタイプt4g.nano
キーペアweb-server(新規で作成)
セキュリティグループssh (自分のIPのみ)
ストレージ8GB (gp3)
create-test-instance-1

SSHログイン

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-172-31-43-8 ~]$

ログインできる。

swapファイルを作成する

2GBのスワップファイルを作成する。

1
2
3

sudo dd if=/dev/zero of=/swap bs=1M count=2048
sudo chmod 600 /swap
sudo mkswap /swap

実行結果↓

1
2
3
4
5
6
7
8

[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

スワップを有効にする。

1

sudo swapon /swap

下記で確認する。

1

swapon -s

1
2
3
4

[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 ~]$ 

1

free -m

1
2
3
4

[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 に下記を追記する。

1

UUID=df4e1838-5778-4dc1-8c67-94fb27364000 /swapdummy swap swap defaults 0 0

再起動後、起動しないことを確認する

1

sudo reboot

SSHで接続をする。
接続できないことを確認。
cannot-connected-instance

復帰手順

下記を参考にレスキューインスタンスの作成および復帰を行う。
https://repost.aws/ja/knowledge-center/ec2-linux-emergency-mode

レスキューインスタンスを作成する

項目設定値
名前rescue-web-server
OSAmazonLinux2023 AMI
アーキテクチャ64ビット(x86)
インスタンスタイプt2.micro
キーペアweb-server
セキュリティグループテストで作成したものと同じ
ストレージ8GB (gp3)

※アベイラビリティゾーンは同一にすること

create-rescue-instance

レスキュー対象のインスタンスを停止する

  1. EC2コンソールから、対象のインスタンスを選択する。
  2. インスタンスの状態 > インスタンスを停止を選択する。

下記の状態になっていること。
create-rescue-instance-2

レスキュー対象のボリュームをデタッチする

  1. 対象のインスタンスを選択し、「ストレージ」タブを確認する。
    detach-volume-1

  2. ブロックデバイスのボリュームを選択し、アクション > ボリュームのデタッチを選択する。
    detach-volume-2

  3. ボリュームのデタッチ > デタッチを選択する。 detach-volume-3

デタッチしたボリュームをレスキューインスタンスにアタッチする

  1. 「使用可能」となっているボリュームを選択する。 attach-volume-1

  2. アクション > ボリュームのアタッチを選択する。 attach-volume-2

  3. ボリュームのアタッチでインスタンスにレスキューインスタンス(rescue-web-server)を選択する attach-volume-3

  4. ボリュームのアタッチを選択する

レスキューインスタンスにSSHで接続する

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-172-31-41-58 ~]$

接続できた！

ボリュームのマウント

lsblk でボリュームがアタッチされているかを確認する。

1

lsblk

結果↓

1
2
3
4
5
6
7
8
9

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 ボリュームがアタッチされていることが確認できる。

ボリュームのマウント

レスキュー対象のボリュームをマウントするディレクトリを作成する。

1

sudo mkdir /mnt/rescue

レスキュー対象のボリュームをマウントする。

1

sudo mount /dev/xvdf1 /mnt/rescue

マウントできていることを確認する。

1
2
3

[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を修正する。

1

sudo vi /mnt/rescue/etc/fstab

対象の行を修正する。

1
2
3
4
5

#
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

アンマウントをして作業を終了する。

1

sudo umount /mnt/rescue

レスキューインスタンスからボリュームのデタッチ

※先程と同じ手順で、今度はレスキューインスタンスをもとに戻す。

  1. rescue-web-server の ボリュームのデタッチをする。
detach-rescue-volume-1

vol-06ad11b0a9a360d57 を選択する。

  1. ボリュームを選択し、アクション > ボリュームのデタッチ を選択する。
detach-rescue-volume-2
  1. デタッチを選択する。

対象のインスタンスにボリュームをアタッチして元に戻す

  1. デタッチしたボリュームを対象のインスタンス(web-server)にアタッチする。
attach-web-server-volume-1
  1. ボリュームのアタッチをする。(デバイス名はルートデバイス名にすること)
attach-web-server-volume-2

※デバイス名がルートデバイスでないとインスタンスの起動ができないので注意

確認

  1. レスキュー対象のインスタンスを起動する。

  2. SSHで接続できることを確認する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

   ,     #_
   ~\_  ####_        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
  1. swapの確認
1
2
3
4

[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のシリアルコンソールを使う方法はよく分からず、うまく直せなかったのでレスキューインスタンスを使用する方法を取った。
起動しない原因がわかっているときは、これで解決できるがわからない場合はどうするのが良いのだろうか。 → シリアルコンソールつなてログを見るとか、システムログの取得とかをすれば良さそう？

今後はミスって起動しなくなったということは起きないようにしたい…。