ConoHa の VPS で Kernel Panic に陥った際の対処方法

突然 VPS に繋がらなくなった。

Web サイトも表示されないし、SSH でも繋がらない。

現象の確認
対応
- 原因
結論
参考にしたサイト

現象の確認

ConoHa の管理画面にログインし、サーバーからネームタグを選択し、コンソールを開いたところ Kernel Panic の画面で止まっていた。

対応

別窓のコンソールはそのまま開いた状態で、管理画面のボタンから再起動をかけます。

再びコンソールのウインドウに戻り、右上の再読み込みボタンを連打してブートメニューの画面が表示されるのを待ちます。（因みにこのときは 2 分程度かかりました）

一定時間が経つと最新版（3.10.0-1160.21.1.el7.x86_64）で起動して再び Kernel Panic に陥るので、素早くカーソルキーの↑↓でメニューを動かし自動起動を防ぎます。

一つ前のカーネル（3.10.0-1160.6.1.el7.x86_64）を選択したところ、無事起動できました。

原因

調べてみると、新しいカーネル（3.10.0-1160.21.1.el7.x86_64）の initramfs が生成されていないのが原因とのこと。

初期化RAMファイルシステムイメ－ジの確認

# ls -l /boot | grep initramfs
-rw-------. 1 root root 48118041 Sep 14  2017 initramfs-0-rescue-1465583130754f4bac91f9e81331de6f.img
-rw-------  1 root root 53892320 Apr 20  2018 initramfs-0-rescue-edcd0866b25f4f2eac0cdd46c5507c2c.img
-rw-------  1 root root 18397103 Dec  1 17:28 initramfs-3.10.0-1160.2.2.el7.x86_64.img
-rw-------  1 root root 18396904 Feb 28 04:53 initramfs-3.10.0-1160.6.1.el7.x86_64.img

# ls -l /boot | grep initramfs

-rw-------. 1 root root 48118041 Sep 14 2017 initramfs-0-rescue-1465583130754f4bac91f9e81331de6f.img

-rw------- 1 root root 53892320 Apr 20 2018 initramfs-0-rescue-edcd0866b25f4f2eac0cdd46c5507c2c.img

-rw------- 1 root root 18397103 Dec 1 17:28 initramfs-3.10.0-1160.2.2.el7.x86_64.img

-rw------- 1 root root 18396904 Feb 28 04:53 initramfs-3.10.0-1160.6.1.el7.x86_64.img

initramfs-3.10.0-1160.21.1.el7.x86_64.img が存在しなかった。

また、grub.cfg の該当カーネルのセクションにも initrd16 の項目が記載されていなかった。

initramfs のイメージファイルを作成

以下のコマンドで 3.10.0-1160.21.1.el7.x86_64 のイメージファイルを作成します。

# depmod 3.10.0-1160.21.1.el7.x86_64
# mkinitrd /boot/initramfs-3.10.0-1160.21.1.el7.x86_64.img 3.10.0-1160.21.1.el7.x86_64

1 2	# depmod 3.10.0-1160.21.1.el7.x86_64 # mkinitrd /boot/initramfs-3.10.0-1160.21.1.el7.x86_64.img 3.10.0-1160.21.1.el7.x86_64

grub.cfg の修正

3.10.0-1160.21.1.el7.x86_64 のセクションの最終行に initrd16 の項目を追記。

# vi /boot/grub2/grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry 'CentOS Linux (3.10.0-1160.21.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-693.2.2.el7.x86_64-advanced-06a4f571-f4f2-49a6-ba13-e249701956f0' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpthttps://psychoco.net/wp-admin/post-new.php#
        insmod ext2
        set root='hd0,gpt2'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2'  06a4f571-f4f2-49a6-ba13-e249701956f0
        else
          search --no-floppy --fs-uuid --set=root 06a4f571-f4f2-49a6-ba13-e249701956f0
        fi
        linux16 /boot/vmlinuz-3.10.0-1160.21.1.el7.x86_64 root=UUID=06a4f571-f4f2-49a6-ba13-e249701956f0 ro crashkernel=auto rhgb quiet net.ifnames=0 console=tty0 console=ttyS0,115200n8r LANG=en_US.UTF-8
        initrd16 /boot/initramfs-3.10.0-1160.21.1.el7.x86_64.img　←追記
}

# vi /boot/grub2/grub.cfg

### BEGIN /etc/grub.d/10_linux ###

menuentry 'CentOS Linux (3.10.0-1160.21.1.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-693.2.2.el7.x86_64-advanced-06a4f571-f4f2-49a6-ba13-e249701956f0' {

load_video

set gfxpayload=keep

insmod gzio

insmod part_gpthttps://psychoco.net/wp-admin/post-new.php#

insmod ext2

set root='hd0,gpt2'

if [ x$feature_platform_search_hint = xy ]; then

search --no-floppy --fs-uuid --set=root --hint='hd0,gpt2' 06a4f571-f4f2-49a6-ba13-e249701956f0

else

search --no-floppy --fs-uuid --set=root 06a4f571-f4f2-49a6-ba13-e249701956f0

linux16 /boot/vmlinuz-3.10.0-1160.21.1.el7.x86_64 root=UUID=06a4f571-f4f2-49a6-ba13-e249701956f0 ro crashkernel=auto rhgb quiet net.ifnames=0 console=tty0 console=ttyS0,115200n8r LANG=en_US.UTF-8

initrd16 /boot/initramfs-3.10.0-1160.21.1.el7.x86_64.img　←追記

}

再起動したところ、最新のカーネル（3.10.0-1160.21.1.el7.x86_64）で問題なく起動することができた。

結論

yum-cron で自動アップデートするのは便利だが、カーネルアップデートも自動化するのは危険かもしれない。

現象の確認

対応

原因

initramfs のイメージファイルを作成

grub.cfg の修正

結論

参考にしたサイト

コメント