Amazon EC2 インスタンスが更新によって正常に再起動しなくなった場合に既知の安定したカーネルに戻す方法を教えてください。

最終更新日: 2021 年 2 月 4 日

EC2 Linux インスタンスに対してカーネルの更新を実行してカーネルが破損してしまった場合、インスタンスは再起動しません。SSH を使用してその障害が発生したインスタンスに接続することもできません。しかし、一時的なレスキューインスタンスを作成し、レスキューインスタンスで Amazon Elastic Block Store (Amazon EBS) ボリュームを再マウントしてから、GRUB でカーネルパラメータを変更して破損したカーネルを取り除くことができます。

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

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

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

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

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

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

5.    [ ストレージ ] タブの [ ブロックデバイス ] で、/dev/sda1 のボリューム ID を選択します。

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

6.    [アクション]、[ボリュームのデタッチ]、[デタッチする] の順に選択します。アベイラビリティーゾーンを書き留めます。

7.    レスキュー EC2 インスタンスを同じアベイラビリティーゾーンで起動します。

注意: 製品コードによっては、同じ OS タイプの EC2 インスタンスを起動する必要がある場合があります。たとえば、障害が発生した EC2 インスタンスが有料の RHEL AMI である場合、同じ製品コードを使用して AMI を起動する必要があります。詳細については、インスタンスの製品コードを取得するを参照してください。

8.    レスキューインスタンスが起動したら、ナビゲーションペインで [ボリューム] を選択してから、障害が発生したインスタンスのデタッチ済みルートボリュームを選択します。

9.    [アクション]、[ボリュームのアタッチ] の順に選択します。

10.    レスキューインスタンスの ID (id-xxxxx) を選択してから、未使用のデバイスを設定します。この例では、/dev/xvdb とします。

1.    SSH を使用してレスキューインスタンスに接続します。

2.    lsblk コマンドを実行して利用可能なディスクデバイスを表示させます。

lsblk

以下に出力の例を示します。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0     0   15G  0 disk
└─xvda1 202:1     0   15G  0 part /
xvdb    202:0     0   15G  0 disk
    └─xvdb1 202:1 0   15G  0 part

注意: Nitro ベースのインスタンスは、EBS ボリュームを NVMe ブロックデバイスとして公開します。Nitro ベースのインスタンスで lsblk コマンドによって生成される出力は、ディスク名を nvme[0-26]n1 と表示します。詳細については、Linux インスタンスでの Amazon EBS および NVMe を参照してください。

3.    マウントディレクトリを作成し、マウントされたボリュームのルートパーティションをこの新しいディレクトリにマウントします。前の例では、/dev/xvdb1 はマウントされたボリュームのルートパーティションです。詳細については、Linux で Amazon EBS ボリュームを使用できるようにするを参照してください。

sudo mkdir /mount
sudo mount /dev/xvdb1 /mount

これで、障害が発生したインスタンスのデータにマウントディレクトリを通じてアクセスできるようになりました。

4.    レスキューインスタンスの /dev、/run、/proc、/sys を、新しくマウントしたボリュームと同じパスにマウントします。

sudo mount -o bind /dev /mount/dev
sudo mount -o bind /run /mount/run
sudo mount -o bind /proc /mount/proc 
sudo mount -o bind /sys /mount/sys

5.    chroot 関数を呼び出してルートディレクトリをこのマウントディレクトリに変更します。

sudo chroot /mount

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

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

Ubuntu 14 LTS および 16.04 用 GRUB2

RHEL 7.5 および Amazon Linux 2 用 GRUB2

RHEL 8 および CentOS 8 用の GRUB2

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

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

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

Ubuntu 14 LTS および 16.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.    grub を更新して変更を認識させます。

sudo update-grub

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

sudo grub-set-default 1

RHEL 7.5 および 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 ファイルを再生成します。

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

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

sudo 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-10-10-1-111 ~]# grubby --info=ALL
index=0
kernel="/boot/vmlinuz-4.18.0-147.3.1.el8_1.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto $tuned_params"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/boot/initramfs-4.18.0-147.3.1.el8_1.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-147.3.1.el8_1.x86_64) 8.1 (Ootpa)"
id="2bb67fbca2394ed494dc348993fb9b94-4.18.0-147.3.1.el8_1.x86_64"
index=1
kernel="/vmlinuz-0-rescue-2bb67fbca2394ed494dc348993fb9b94"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/initramfs-0-rescue-2bb67fbca2394ed494dc348993fb9b94.img"
title="Red Hat Enterprise Linux (0-rescue-2bb67fbca2394ed494dc348993fb9b94) 8.1 (Ootpa)"
id="2bb67fbca2394ed494dc348993fb9b94-0-rescue"
index=2
kernel="/boot/vmlinuz-4.18.0-80.4.2.el8_0.x86_64"
args="ro console=ttyS0,115200n8 console=tty0 net.ifnames=0 rd.blacklist=nouveau crashkernel=auto $tuned_params"
root="UUID=a727b695-0c21-404a-b42b-3075c8deb6ab"
initrd="/boot/initramfs-4.18.0-80.4.2.el8_0.x86_64.img $tuned_initrd"
title="Red Hat Enterprise Linux (4.18.0-80.4.2.el8_0.x86_64) 8.0 (Ootpa)"
id="c74bc11fb3d6436bb2716196dd0e7a47-4.18.0-80.4.2.el8_0.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-0-rescue-4.18.0-80.4.2.el8_1.x86_64

注意: 4.18.0-80.4.2.el8_1.x86_64 をカーネルのバージョン番号に置き換えます。

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

grubby --default-kernel

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

exit
sudo umount /mount/dev
sudo umount /mount/run
sudo umount /mount/proc
sudo umount /mount/sys
sudo umount /mount

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

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

4.    ルートボリューム vol-xxx をレスキューインスタンスからデタッチします。

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

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

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