更新後、Amazon EC2 インスタンスの再起動に失敗します。既知の安定したカーネルに戻すにはどうすればよいですか。

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

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

レスキュー EC2 インスタンスにルートボリュームをアタッチする

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

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

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

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

4.    [Actions] (アクション)、[Instance State] (インスタンス状態)、[Stop] (停止) の順に選択します。

5.    [Description] (説明) タブで、[Root device] (ルートデバイス) に [/dev/sda1] を選択してから、[EBS ID] を選択します。

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

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

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

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

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

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

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

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

現在の破損したカーネルはリストの 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.    /etc/default/grub 内の破損した GRUB_DEFAULT=0 デフォルトメニューエントリを、安定した 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

4.    exit を入力して、chroot 環境を抜けます。

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

5.    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

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

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

2.    [Actions] (アクション)、[Instance State] (インスタンス状態)、[Stop] (停止)、[Yes, Stop] (停止する) の順に選択します。

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

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

注意: ディストリビューションによりルートボリュームは異なります。Amazon Linux 1 および 2 では、ルートボリュームを /dev/xvda とする必要があります。そうなっていない場合はエラーが発生します。同様に、ディストリビューションが RHEL、CentOS、Ubuntu の場合、ルートボリュームは /dev/sda1 とする必要があります。

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