到達不可能またはアクセス不能な Linux インスタンスの EC2 シリアルコンソールへのアクセスを設定するにはどうすればよいですか?
Amazon Elastic Compute Cloud (Amazon EC2) Linux インスタンスが到達不可能またはアクセス不能です。EC2 シリアルコンソールへのアクセスを OS レベルで設定しませんでした。
簡単な説明
シリアルコンソールへのアクセスを設定するには、以下の手順を実行します。
1. インスタンスのルートボリュームにアクセスします。
2. ルートユーザーまたはその他の OS ユーザーのパスワードを設定します。
3. シリアルコンソールの GRUB 設定を確認して更新します。
注: 影響を受けるインスタンスで EC2 シリアルコンソールが正常に動作していて、OS ユーザーのパスワードを設定するだけでよい場合は、ステップ 3 をスキップできます。
前提条件
シリアルコンソールを使用するには、OS のユーザーパスワードを設定すること以外の前提条件を満たしていることを確認します。パスワードの設定については、次の解決策で説明します。
解決策
レスキューインスタンスを使用してインスタンスのルートボリュームにアクセスする
一時的なレスキューインスタンスを作成して、そのレスキューインスタンスに Amazon Elastic Block Store (Amazon EBS) ボリュームを再マウントします。レスキューインスタンスから、シリアルコンソールの GRUB 設定を確認および変更できます。ルートユーザーやその他の OS ユーザーのパスワードを設定することもできます。
**重要:**インスタンスストアでバックアップされるインスタンスではこの手順を実行しないでください。復旧手順ではインスタンスの停止と起動が必要となり、そのインスタンス上のデータが失われるためです。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。
1. ルートボリュームの EBS スナップショットを作成します。詳細については、「Amazon EBS スナップショットの作成」を参照してください。
2. Amazon EC2 コンソールを開きます。
注: 正しいリージョンに設定されていることを確認してください。
3. ナビゲーションペインから [インスタンス] を選択し、障害が発生したインスタンスを選択します。
4. [インスタンスの状態]、[インスタンスの停止] を順に選択してから、[停止] を選択します。
5. [ストレージ] タブの [ブロックデバイス] で、/dev/sda1 または /dev/xvda の [ボリューム ID] を選択します。
注: ルートデバイスは AMI によって異なりますが、/dev/xvda または /dev/sda1 はルートデバイス用に予約されています。例えば、Amazon Linux 1 と 2 は /dev/xvda を使用します。Ubuntu 16、18、CentOS 7、RHEL 7.5 などのその他のディストリビューションは、/dev/sda1 を使用します。
6. [アクション]、[ボリュームのデタッチ]、[デタッチする] の順に選択します。アベイラビリティーゾーンを書き留めます。
注: デタッチする前に EBS ボリュームにタグを付けることで、後の手順で識別しやすくなります。
7. 同じアベイラビリティーゾーンで、レスキュー EC2 インスタンスを起動します。
注: 製品コードによっては、同じ OS の種類の EC2 インスタンスを起動する必要がある場合があります。例えば、障害が発生した EC2 インスタンスが有料の RHEL AMI である場合は、同じ製品コードを使用して AMI を起動する必要があります。詳細については、「インスタンスの製品コードの取得」を参照してください。
元のインスタンスで SELinux (RHEL、CentOS 7、8 など) を実行している場合は、SELinux を使用する AMI からレスキューインスタンスを起動します。Amazon Linux 2 などの別の OS を実行している AMI を選択すると、元のインスタンスで変更されたすべてのファイルで、SELinux のラベルが壊れています。
8. レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] を選択してから、障害が発生したインスタンスのデタッチ済みルートボリュームを選択します。
9. ** [アクション]、[ボリュームのアタッチ]** の順に選択します。
10. レスキューインスタンスの ID (id-xxxxx) を選択し、未使用のデバイスを設定します。この例では、/dev/sdf です。
11. SSH を使用してレスキューインスタンスに接続します。
12. lsblk コマンドを実行して使用可能なディスクデバイスを表示します。
lsblk
出力の例は以下のとおりです。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 15G 0 disk └─xvda1 202:1 0 15G 0 part / xvdf 202:0 0 15G 0 disk └─xvdf1 202:1 0 15G 0 part
注: Nitro ベースのインスタンスは EBS ボリュームを NVMe ブロックデバイスとして公開します。Nitro ベースのインスタンスで lsblk コマンドによって生成される出力では、ディスク名が nvme[0-26]n1 と表示されます。詳細については、「Linux インスタンスの Amazon EBS および NVMe」を参照してください。Nitro ベースのインスタンスでの lsblk コマンド出力の例は以下のとおりです。
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 8G 0 disk └─nvme0n1p1 259:1 0 8G 0 part / └─nvme0n1p128 259:2 0 1M 0 part nvme1n1 259:3 0 100G 0 disk └─nvme1n1p1 259:4 0 100G 0 part /
13. ルートにするために、次のコマンドを実行します。
sudo -i
14. マウント済みのボリュームのルートパーティションを /mnt にマウントします。前述の例においては、/dev/xvdf1 または /dev/nvme2n1p2 がマウント済みのボリュームのルートパーティションとなります。詳細については、「Linux で Amazon EBS ボリュームを使用できるようにする」を参照してください。
注: 次の例では、/dev/xvdf1 をボリュームの正しいルートパーティションに置き換えてください。
mount -o nouuid /dev/xvdf1 /mnt
注:****/mnt が設定に存在しない場合は、マウントディレクトリを作成し、マウント済みのボリュームのルートパーティションをこの新しいディレクトリにマウントします。
mkdir /mnt mount -o nouuid /dev/xvdf1 /mnt
これで、マウントディレクトリを介して、障害が発生したインスタンスのデータへアクセスできるようになりました。
15. レスキューインスタンスの /dev、/run、/proc、/sys を、新しくマウントしたボリュームと同じパスにマウントします。
for m in dev proc run sys; do mount -o bind {,/mnt}/$m; done
マウントディレクトリに変更するために、chroot 関数を呼び出します。
注: /boot パーティションと /etc パーティションが別々に存在する場合は、次のコマンドを実行する前にそれらを /mnt/boot と /mnt/etc にマウントしてください。
chroot /mnt
ルートユーザーまたはその他の OS ユーザーのパスワードを設定します。
passwd コマンドを使用して OS ユーザーのパスワードを設定します。次の例では、ユーザーは root です。
passwd root
シリアルコンソールの GRUB 設定を確認して更新します。
注: 影響を受けるインスタンスで EC2 シリアルコンソールが正常に動作していて、OS ユーザーのパスワードを設定するだけでよい場合は、このステップをスキップできます。
Linux でサポートされているシリアルコンソールポートは ttyS0 です。EC2 シリアルコンソールへの接続時に何も出力されずに画面が黒いままの場合は、GRUB 設定でコンソールエントリが正しく設定されていることを確認してください。以下に示す例は、シリアルコンソールが正常に動作しているさまざまなディストリビューションの AWS Marketplace AMI から抜粋したものです。
Amazon Linux 2、RHEL、および CentOS 7 の GRUB2
1. ttyS0 のコンソールエントリが、/etc/default/grub ファイルの GRUB_CMDLINE_LINUX_DEFAULT 行に正しく設定されていることを確認します。
Amazon Linux 2
GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"
RHEL 7
GRUB_CMDLINE_LINUX="console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"
CentOS 7
GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto net.ifnames=0 console=ttyS0"
2. ttyS0 のコンソールエントリが設定されていない場合は、エントリを GRUB_CMDLINE_LINUX_DEFAULT 行に追加します。次に、GRUB を更新して /boot/grub2/grub.cfg ファイルを再生成します。
grub2-mkconfig -o /boot/grub2/grub.cfg
Red Hat 6 および Amazon Linux 1 の GRUB1 (レガシー GRUB)
1. ttyS0 のコンソールエントリが、/boot/grub/grub.conf ファイルのカーネル行に正しく設定されていることを確認します。
Amazon Linux 1
kernel /boot/vmlinuz-4.14.252-131.483.amzn1.x86_64 root=LABEL=/ console=tty1 console=ttyS0 selinux=0 nvme_core.io_timeout=4294967295
Red Hat 6
kernel /boot/vmlinuz-2.6.32-573.el6.x86_64 console=ttyS0 console=ttyS0,115200n8 ro root=UUID=0e6b1614-7bbe-4d6e-bc78-a5556a123ba8 rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=us LANG=en_US.UTF-8 xen_blkfront.sda_is_xvda=1 console=tty0 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_NO_LVM rd_NO_DM
2. ttyS0 のコンソールエントリが設定されていない場合は、前述の例に従ってエントリを /boot/grub/grub.conf ファイルに追加します。
Ubuntu 16.04、18.04、および 20.04 の GRUB2
1. ttyS0 のコンソールエントリが、/etc/default/grub.d/50-cloudimg-settings.cfg ファイルの GRUB_CMDLINE_LINUX_DEFAULT 行に正しく設定されていることを確認します。
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 nvme_core.io_timeout=4294967295"
2. console=ttyS0 のコンソールエントリが存在しない場合は**、**エントリを GRUB_CMDLINE_LINUX_DEFAULT 行に追加します。次に、以下のコマンドを使用して GRUB 設定を更新します。
update-grub
**RHEL 8、CentOS 8、および Amazon Linux 2023 の GRUB2
**
1. grubby --default-kernel コマンドを実行して、現在のデフォルトカーネルを確認します。
grubby --default-kernel
2. grubby --info=ALL コマンドを実行して、使用可能なすべてのカーネル、そのインデックス、および引数を確認します。
grubby --info=ALL
3. ttyS0 のコンソールエントリが、ステップ 1 で説明したデフォルトカーネルの args 行に正しく設定されていることを確認します。
RHEL 8
index=0 kernel="/boot/vmlinuz-4.18.0-305.el8.x86_64" args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto $tuned_params" root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421" initrd="/boot/initramfs-4.18.0-305.el8.x86_64.img $tuned_initrd" title="Red Hat Enterprise Linux (4.18.0-305.el8.x86_64) 8.4 (Ootpa)" id="0c75beb2b6ca4d78b335e92f0002b619-4.18.0-305.el8.x86_64"
CentOS 8
index=2 kernel="/boot/vmlinuz-4.18.0-193.19.1.el8_2.x86_64" args="ro console=ttyS0,115200n8 no_timer_check net.ifnames=0 nvme_core.io_timeout=4294967295 nvme_core.max_retries=10 crashkernel=auto $tuned_params" root="UUID=b437cbaa-8fe5-49e4-8537-0895c219037a" initrd="/boot/initramfs-4.18.0-193.19.1.el8_2.x86_64.img $tuned_initrd" title="CentOS Linux (4.18.0-193.19.1.el8_2.x86_64) 8 (Core)" id="dc49529e359897df0b9664481b009b1f-4.18.0-193.19.1.el8_2.x86_64"
Amazon Linux 2023
[root@ip-172-31-92-173 ~]# grubby --info DEFAULTindex=0 kernel="/boot/vmlinuz-6.1.15-28.43.amzn2023.x86_64" Acessing serial console on Amazon Linux 2023 root="UUID=7efef47b-a4f8-4b90-9504-8196067a31b6" initrd="/boot/initramfs-6.1.15-28.43.amzn2023.x86_64.img" title="Amazon Linux (6.1.15-28.43.amzn2023.x86_64) 2023" id="02c860b8daad4861b87f9b3603834c8f-6.1.15-28.43.amzn2023.x86_64"
4. ttyS0 のコンソールエントリが設定されていない場合は、次の grubby コマンドを使用してエントリをデフォルトカーネルの args に追加します。
grubby --args "console=tty0 console=ttyS0,115200n8" --update-kernel DEFAULT
レスキューインスタンスからルートボリュームをアンマウントしてデタッチし、障害が発生したインスタンスにボリュームをアタッチします
1. chroot を終了し、/dev、/run、/proc、および /sys をアンマウントします。
exit umount /mnt/{dev,proc,run,sys,}
2. Amazon EC2 コンソールで [インスタンス] を選択し、レスキューインスタンスを選択します。
3. [インスタンスの状態]、[インスタンスの停止] を順に選択してから、[停止する] を選択します。
4. ルートボリューム id-xxxxx (障害が発生したインスタンスのボリューム) をレスキューインスタンスからデタッチします。
5. ステップ 4 でデタッチしたルートボリュームを、障害が発生したインスタンスにルートボリューム (/dev/sda1) としてアタッチし、インスタンスを起動します。
注: ルートデバイスは AMI ごとに異なります。/dev/xvda や /dev/sda1 という名前はルートデバイス用に予約されています。例えば、Amazon Linux 1 と 2 は /dev/xvda を使用します。Ubuntu 16、18、CentOS 7、RHEL 7.5 などのその他のディストリビューションは、/dev/sda1 を使用します。
これで、前述のステップでルートユーザーまたはその他の OS ユーザーに対して定義したパスワードを使用して、EC2 シリアルコンソールから障害が発生したインスタンスの OS にアクセスできるようになりました。
関連情報
関連するコンテンツ
- 質問済み 2ヶ月前
- AWS公式更新しました 1年前
- AWS公式更新しました 5年前
- AWS公式更新しました 7ヶ月前
