Amazon EC2 インスタンスが更新によって正常に再起動しなくなった後で、既知の安定したカーネルに戻すにはどうすればよいですか。

最終更新日: 2021 年 8 月 30 日

カーネルの更新により Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが正常に再起動しなくなった後で、安定したカーネルに戻すにはどうすればよいですか

簡単な説明

EC2 Linux インスタンスに対してカーネルの更新を実行してカーネルが破損してしまった場合、インスタンスは再起動しません。SSH を使用してその障害が発生したインスタンスに接続することもできません。

以前のバージョンに戻すには、次の操作を行います。

1. インスタンスのルートボリュームにアクセスします。

2. GRUB ブートローダーでデフォルトのカーネルを更新します。

解決方法

インスタンスのルートボリュームにアクセスする

ルートボリュームには、次の2つの方法でアクセスできます。

方法 1: EC2 シリアルコンソールを使用する

Linux 用 EC2 シリアルコンソールを有効にした場合は、それを使用して、サポートされている Nitro ベースのインスタンスタイプのトラブルシューティングを行うことができます。シリアルコンソールは、起動の問題、ネットワーク設定、および SSH 設定の問題のトラブルシューティングに役立ちます。シリアルコンソールは、正常に動作するネットワーク接続を必要とすることなく、インスタンスに接続します。シリアルコンソールには、Amazon EC2 コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用してアクセスできます。

シリアルコンソールを使用する前に、アカウントレベルでコンソールにアクセス権を付与します。その後、IAM ユーザーにアクセス権を付与する AWS Identity and Access Management (IAM) ポリシーを作成します。また、シリアルコンソールを使用するすべてのインスタンスには、少なくとも 1 名のパスワードベースユーザーを含める必要があります。インスタンスが到達不能で、シリアルコンソールへのアクセスを設定していない場合は、方法 2 の手順に従います。Linux 用の EC2 シリアルコンソールの設定の詳細については、「EC2 シリアルコンソールへのアクセスを設定する」を参照してください。

注意: AWS CLI コマンドの実行時にエラーが表示される場合は、AWS CLI の最新バージョンを使用していることを確認してください。

方法 2: レスキューインスタンスを使用する

一時的なレスキューインスタンスを作成し、レスキューインスタンスで Amazon Elastic Block Store (Amazon EBS) ボリュームを再マウントしてから、GRUB でカーネルパラメータを変更して、破損したカーネルを取り除くことができます。

重要: インスタンスが Instance Store-Backed インスタンスである場合は、以下の手順を実行しないください。この復旧手順ではインスタンスの停止と起動が必要であり、そのインスタンス上のデータが失われるためです。詳細については、「インスタンスのルートデバイスタイプの判別」を参照してください。

1. ルートボリュームの EBS スナップショットを作成します。詳細については、Amazon EBS スナップショットの作成を参照してください。

2. Amazon EC2 コンソールを開きます。

注意: 正しいリージョンが選択されていることを確認してください。

3. ナビゲーションペインで [インスタンス] を選択してから、障害が発生したインスタンスを選択します。

4. [インスタンスの状態 ]、[インスタンスを停止] の順に選択してから、[停止] を選択します。

5. [Storage] (ストレージ) タブの [Block devices] (ブロックデバイス) で、/dev/sda1 または /dev/xvda の [Volume ID] (ボリューム ID) を選択します。

注: ルートデバイスは AMI により異なりますが、/dev/xvda または /dev/sda1 はルートデバイス用に予約されています。例えば、Amazon Linux 1 および 2 は /dev/xvda を使用します。Ubuntu 14、16、18、CentOS7、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 と表示します。詳細については、Amazon EBS および Linux インスタンス上の 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/nvme1n1p1 はマウントされたボリュームのルートパーティションです。詳細については、「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 パーティションがある場合は、次のコマンドを実行する前に /mnt/boot にマウントしてください。

chroot /mnt

GRUB ブートローダーでデフォルトのカーネルを更新する

現在の破損したカーネルはリストの 0 (ゼロ) の位置にあります。1つ前の安定したカーネルは 1 の位置にあります。破損したカーネルを安定したカーネルに置き換えるには、お使いのディストリビューションに応じて、以下のいずれかの手順を使用します。

Red Hat 6 および Amazon Linux 用 GRUB1 (レガシー GRUB)
Ubuntu 14 LTS、16.04、および 18.04 用 GRUB2
RHEL 7 および Amazon Linux 2 用 GRUB2
RHEL 8 および CentOS 8 用の GRUB2

Red Hat 6 および Amazon Linux 1 用 GRUB1 (レガシー GRUB)

sed コマンドを使用して、/boot/grub/grub.conf ファイル内の破損したカーネルを安定したカーネルに置き換えます。

sed -i '/^default/ s/0/1/' /boot/grub/grub.conf

Ubuntu 14 LTS、16.04、および 18.04 用 GRUB2

1. /etc/default/grub 内の破損した GRUB_DEFAULT=0 デフォルトメニューエントリを、安定した GRUB_DEFAULT=saved 値に置き換えます。

sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. update-grub コマンドを実行して、GRUB が変更を認識できるようにします。

update-grub

3. grub-set-default コマンドを実行して、次回の再起動時に安定したカーネルがロードされるようにします。この例では、grub-set-default が位置 0 で 1 に設定されています。

grub-set-default 1

RHEL 7 および Amazon Linux 2 用 GRUB2

1. 破損した GRUB_DEFAULT=0 のデフォルトメニューエントリを、/etc/default/grub ファイルに保存されている安定した GRUB_DEFAULT-saved 値に置き換えます。

sed -i 's/GRUB_DEFAULT=0/GRUB_DEFAULT=saved/g' /etc/default/grub

2. GRUB を更新して、/boot/grub2/grub.cfg ファイルを再生成します。

grub2-mkconfig -o /boot/grub2/grub.cfg

3. grub2-set-default コマンドを実行して、次回の再起動時に安定したカーネルがロードされるようにします。この例では、grub2-set-default が位置 0 で 1 に設定されています。

grub2-set-default 1

RHEL 8 および CentOS 8 用の GRUB2

RHEL 8 および CentOS 8 の GRUB2 は、以前の grub.cfg 形式の代わりに、blscfg ファイルと /boot/loader のエントリをブート設定に使用します。blscfg ファイルを管理し、/boot/loader/entries/ から情報を取得するには、grubby ツールを使用するのがベストプラクティスです。blscfg ファイルがこの場所に見つからないか、破損している場合、grubby は結果を表示しません。機能を回復するには、ファイルを再生成する必要があります。したがって、カーネルのインデックス作成は /boot/loader/entries の下にある .conf ファイルとカーネルバージョンによって異なります。インデックス作成は、最も低いインデックスで最新のカーネルを維持するように設定されています。BLS 設定ファイルを再生成する方法については、Grub2 BLS 設定ファイルの問題が原因で起動に失敗する Red Hat 8 または CentOS 8 インスタンスを復旧する方法を教えてください。を参照してください。

1. grubby --default-kernel コマンドを実行して、現在のデフォルトカーネルを表示します。

grubby --default-kernel

2. grubby --info=ALL コマンドを実行して、使用可能なすべてのカーネルとそのインデックスを確認します。

grubby --info=ALL

--info=ALL コマンドの出力例を次に示します。

root@ip-172-31-29-221 /]# grubby --info=ALL
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"
index=1
kernel="/boot/vmlinuz-0-rescue-0c75beb2b6ca4d78b335e92f0002b619"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau nvme_core.io_timeout=4294967295 crashkernel=auto"
root="UUID=d35fe619-1d06-4ace-9fe3-169baad3e421"
initrd="/boot/initramfs-0-rescue-0c75beb2b6ca4d78b335e92f0002b619.img"
title="Red Hat Enterprise Linux (0-rescue-0c75beb2b6ca4d78b335e92f0002b619) 8.4 (Ootpa)"
id="0c75beb2b6ca4d78b335e92f0002b619-0-rescue"
index=2
kernel="/boot/vmlinuz-4.18.0-305.3.1.el8_4.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.3.1.el8_4.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-305.3.1.el8_4.x86_64) 8.4 (Ootpa)"
id="ec2fa869f66b627b3c98f33dfa6bc44d-4.18.0-305.3.1.el8_4.x86_64"

インスタンスのデフォルトとして設定するカーネルのパスを書き留めます。前の例では、インデックス 2 のカーネルのパスは /boot/vmlinuz-0-4.18.0-80.4.2.el8_1.x86_64 です。

3. grubby --set-default コマンドを実行して、インスタンスのデフォルトカーネルを変更します。

grubby --set-default=/boot/vmlinuz-4.18.0-305.3.1.el8_4.x86_64

注: 4.18.0-305.3.1.el8_4.x86_64 を実際のカーネルのバージョン番号に置き換えます。

4. grubby --default-kernel コマンドを実行して、前のコマンドが機能したことを確認します。

grubby --default-kernel

EC2 シリアルコンソールを使用してインスタンスにアクセスしている場合、安定したカーネルがロードされるようになり、インスタンスを再起動できます。

レスキューインスタンスを使用している場合は、次のセクションの手順を完了します。

ボリュームをアンマウントし、ルートボリュームをレスキューインスタンスからデタッチして、障害の発生したインスタンスにアタッチします。

注意: 「方法 2: レスキューインスタンスを使用する」を使用してルートボリュームにアクセスした場合は、以下の手順を完了してください。

1. chroot を終了し、/dev、/run、/proc、および /sys マウントをアンマウントします。

exit
umount /mnt/{dev,proc,run,sys,}

2. Amazon EC2 コンソールで [Instances] を選択し、レスキューインスタンスを選択します。

3. [インスタンスの状態 ]、[インスタンスを停止] の順に選択してから、[停止する] を選択します。

4. ルートボリューム id-xxxxx (障害のあるインスタンスからのボリューム) をレスキューインスタンスからデタッチします。

5. ステップ 4 でデタッチしたルートボリュームを障害の発生したインスタンスにルートボリューム (/dev/sda1) としてアタッチし、インスタンスを起動します。

注: ルートデバイスは AMI ごとに異なります。/dev/xvda または /dev/sda1 という名前は、常にルートデバイス用に予約されています。例えば、Amazon Linux 1 および 2 は /dev/xvda を使用します。Ubuntu 14、16、18、CentOS 7、RHEL 7.5 などのその他のディストリビューションは、/dev/sda1 を使用します。

安定したカーネルがロードされ、インスタンスが再起動します。

この記事はお役に立ちましたか?

フィードバックを送信

請求に関するサポートまたは技術サポートが必要ですか?

AWS Support へのお問い合わせ