ConoHaVPSでkernel panicを起きたのを復旧した話

# はじめに
この記事は「ConoHaVPSを再起動したらkernel panicのエラーで起動できなくなった」のを調べつつ自力で復旧した話です。  
なお私はエンジニアではないので、この手の知識は全くありません。
**間違った情報を書いている可能性がありますので、この記事を鵜呑みにせず、様々なサイトの情報を総合的に見て判断してください。
この記事を鵜呑みにして何かしら問題があっても責任はおえません。**

# 再起動してから異変に気づく
Webmin経由で再起動させるもなかなか起動せず、コンパネからコンソールを開くとこのようなエラーが...
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201995/e40a34b1-d506-9701-488f-a99b73f04489.png)

ここで２つの案が浮かびます。  
1つはOSを入れ直しまっさらに生まれ変わる案。
1つは調べつつ気合で復旧させる案。  

サポートの力を借りるは浮かびませんでした。  
土曜日なのでチャットも電話も対応外でメールで問い合わせてもすぐに返ってこないと判断しました。  

バックアップを取っていれば前者で楽にできたのですが、サーバー上にあるデータはバックアップが存在せず、またデータベースのバックアップは全く存在しないため、後者の案を採用します。

# Google検索してみる
まずは「カーネルパニックとは...?」ということで検索をかけます。
内部の致命的なエラーで有ることがわかりました。
自分的に一番わかりやすかったのはWindowsのブルースクリーンでした。

次にConoHaVPSをつけて検索をかけて解決方法を探しました。
ちょうど1年ほど前に kiyocy24 氏が投稿した[【Conoha VPS】Karnel Panicの復旧に手こずった話](https://qiita.com/kiyocy24/items/5897d58bdd04f2e2a65c)がヒットしました。  

# レスキューモードに入る
レスキューモードに入るのに必要なものが次の３つです。  
1.ConoHaコンパネにあるコンソール
2.問題のVPSのConoHaコンパネページ(起動,再起動などのボタンが並んでいるページ)
3.根気強さ

## 手順1:コンソールに接続
コンパネからコンソールを選び接続します。  
接続するとおそらく上にある画像の文字が表示されるはずです。(文章の細部は違うと思いますが)  

## 手順2:再起動ボタンを押す
コンソールを開いたままの状態で、コンパネにある再起動ボタンを押します。  
確認のウィンドウが出るので「はい」をクリックします。

## 手順3:コンソールの再読み込みボタンを押す
コンソールの右上にある再起動ボタンを、タイミングよく押します。  
左下に接続など出ていると思うのでそこが「切断されました」と出てから数秒以内に読み込みボタンを押して、キーボードの十字キーを連打します。  
早すぎると接続できず、遅すぎるとエラーの文字がでます。  
エラーが出る場合、根気強く手順2からやり直しましょう。  
## 手順4:一つ前のやつを選ぶ。
うまく行けばカーネルの選択画面が出ますので、上から二番目を選んで起動します。  
ログインの画面になれば起動は成功です。

# 新しいカーネルの initramfs を生成する
SSHで接続することができたので、ここからSSHから作業します。  

```
$ ls -l /boot | grep initramfs
-rw-------  1 root root 60086709  7月 18  2018 initramfs-0-rescue-40f3b4e7707e4ace88aa7780ac5851a2.img
-rw-------. 1 root root 45201576  2月  9  2017 initramfs-0-rescue-55a201f65e044fb291c90c84936d9385.img
-rw-------  1 root root 18712107  2月  3  2019 initramfs-3.10.0-514.6.2.el7.x86_64.img
-rw-------  1 root root 18921747  2月  3  2019 initramfs-3.10.0-862.14.4.el7.x86_64.img
-rw-------  1 root root 18887984  2月  3  2019 initramfs-3.10.0-862.9.1.el7.x86_64.img
-rw-------  1 root root 18304491 10月 10 16:28 initramfs-3.10.0-957.5.1.el7.x86_64.img
```

から、initramfs-3.10.0-1127.19.1.el7.x86_64.img がない(上の画像のerror: file '/boot/initramfs-3.10.0-1127.19.1.el7.x86_64.img' notfound.に書いてある)がないので次のコマンドで生成します。  

```
$ sudo depmod 3.10.0-1127.19.1.el7.x86_64
$ sudo mkinitrd initramfs-3.10.0-1127.19.1.el7.x86_64.img 3.10.0-1127.19.1.el7.x86_64

$ ls -l /boot | grep initramfs
-rw-------  1 root root 60086709  7月 18  2018 initramfs-0-rescue-40f3b4e7707e4ace88aa7780ac5851a2.img
-rw-------. 1 root root 45201576  2月  9  2017 initramfs-0-rescue-55a201f65e044fb291c90c84936d9385.img
-rw-------  1 root root 18689133 10月 17 11:23 initramfs-3.10.0-1127.19.1.el7.x86_64.img
-rw-------  1 root root 18712107  2月  3  2019 initramfs-3.10.0-514.6.2.el7.x86_64.img
-rw-------  1 root root 18921747  2月  3  2019 initramfs-3.10.0-862.14.4.el7.x86_64.img
-rw-------  1 root root 18887984  2月  3  2019 initramfs-3.10.0-862.9.1.el7.x86_64.img
-rw-------  1 root root 18304491 10月 10 16:28 initramfs-3.10.0-957.5.1.el7.x86_64.img
```

ちゃんとinitramfs-3.10.0-1127.19.1.el7.x86_64.imgがあれば生成は完了です。  
なければ、/boot に移動した上でコマンドを再度実行します。

grub.cfgでカーネルのセクションを確認してみると、initramfs-3.10.0-1127.19.1.el7.x86_64.imgがすでに書いてあったため、編集はせずそのまま再起動しました。
おそらく何らかのエラーでinitramfs-3.10.0-1127.19.1.el7.x86_64.imgが消えてしまったと思われます。

これで無事に起動できるようになりました。  
そのあと、nginxが起動できなくなったり、SSL周りで問題が起きたりしましたが、これはまた別の話。。。

# 参考 & スペシャルサンクス
[【Conoha VPS】Karnel Panicの復旧に手こずった話](https://qiita.com/kiyocy24/items/5897d58bdd04f2e2a65c) kiyocy24様
[ConoHaのVPSでKernel panic発生時に前のカーネルに戻す手順](https://linux-svr.com/tips/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB/31.php) 初めてのVPS構築様
[yum updateしたらkernel panicで起動しなくなった](https://vild.hatenablog.com/entry/2016/08/19/233547) vild様