CentOS 6のスナップショットからインスタンスを起動した時にハマったこと

2016.01.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。先日、CentOS 6のスナップショットからインスタンスを起動した際に引っかかったポイントがありましたのでまとめてみます。

概要としては以下になります。

  • 対象: 「CentOS 6.3 (x86_64) - Release Media」の公式AMI
  • インスタンスからEBSのスナップショットを取得。そこからAMIを作成するパターン
  • AMI作成時にルートデバイス名を意識しないと、インスタンスステータスチェックで失敗してしまう
  • ルートデバイス名をデフォルトの /dev/sda1 ではなく、 /dev/sda または /dev/xvde に変更することで対応

centos63-snapshot-00

詳細

現象の再現

AWS MarketplaceからCentOS公式AMI「CentOS 6.3 (x86_64) - Release Media」を選択してインスタンスを立ち上げます。 このインスタンスからスナップショットを取得して、そこからAMIを作成します。 ここでルートデバイス名についてはデフォルトの /dev/sda1 のままとします。

centos63-snapshot-01

このAMIからインスタンスを立ち上げてみます。 すると、ステータスチェックが 1/2 のまま止まってしまい、 正常に起動できませんでした。インスタンスの接続性チェックが失敗となっています。

centos63-snapshot-02

原因を探る

原因を調べてみようと思いましたが、接続性で失敗しているのでsshでの接続ができません。こんな時はManagement Consoleからシステムログを取得、確認してみます。

centos63-snapshot-03

大量にログが出力されていますが、最後のほうに以下のメッセージがありました。

dracut Warning: No root device "block:/dev/xvde" found

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.

dracut Warning: Signal caught!

dracut Warning: Boot has failed. To debug this issue add "rdshell" to the kernel command line.
Kernel panic - not syncing: Attempted to kill init!

ルートデバイス "/dev/xvde"が見つからないので Kernel panicを起こしているようです。

解決策

ルートデバイスであるである /dev/xvde が見つからない、ということなので、 /dev/xvde をルートデバイスとしてみます。 スナップショットからAMIを作り直し、作成の際に以下のようにルートデバイス名を /dev/xvde に変更してみました。

centos63-snapshot-05

すると、今度は無事に起動することができました! ステータスチェックで問題となることもなく、sshでの接続も問題なく行えます。

ですが、いままで /dev/sda1 がルートデバイスとなっていたので、 いきなり /dev/xvde が出てきたことにちょっと違和感があります。 とりあえず、 /dev を確認してみると以下となっていました。

[root@ip-172-31-13-162 /]# ls -l /dev | grep sda
lrwxrwxrwx. 1 root root 4 2016-01-13 10:02 sda -> xvde
[root@ip-172-31-13-162 /]# ls -l /dev | grep xvde
lrwxrwxrwx. 1 root root 4 2016-01-13 10:02 root -> xvde
lrwxrwxrwx. 1 root root 4 2016-01-13 10:02 sda -> xvde
brw-rw----. 1 root disk 202, 64 2016-01-13 10:02 xvde

/dev/sda は存在しているけど、その実態は /dev/xvde となっています。 ということは、ルートデバイスをブロックデバイスと同じ /dev/sda としてみれば動くのでは? ということでこちらも確認して見たところ無事に起動しました。

ということで、ルートデバイス名を

  • /dev/sda
  • /dev/xvde

のどちらかに変更すればスナップショットから起動できることがわかりました!

同様パターンの確認

スナップショットからではなく直接AMIを作成した場合は?

スナップショットからAMIを起動する際のルートデバイス名がハマりどころのポイントでした。 それではインスタンスから直接AMIを作成した場合はどうなるでしょうか?

試してみたところ、この場合は今回の問題は発生せず、起動することができました。 この時、ルートデバイスは「/dev/sda1」、ブロックデバイスは「/dev/sda」となっていました。

centos63-snapshot-08

よく確認してみると、ベースとなっているCentOS公式のAMI 「CentOS 6.3 (x86_64) - Release Media」から立ち上げたときもこの状態となっていました。 (どうやらこの設定がミソっぽいですね。。)

他のバージョンのCentOSでは同じことが起こる?

他の(例えば最新の)CentOSでは同じことが起きるのでしょうか? 新たにCentOS 6を使用する場合、特段の理由がなければアップデートも含まれるAMI 「CentOS 6 (x86_64) - with Updates」 を使用するかと思います。こちらで試してみました。

AMIから起動直後に気がついた点は、ルートデバイス、ブロックデバイスともに /dev/sda となっていた点です。 このため、スナップショットからイメージを作成する際にも、 特に意識せずにルートデバイス名に /dev/sda が指定されます。 そのままデフォルトの /dev/sda のままAMIを作成すれば、今回の事象は発生しませんでした。

また /dev 配下を確認してみると、CentOS 6.3の時と少し違って、 /dev/sda は存在せず、 /dev/xdve と /dev/xdve1 が存在していました。

[root@ip-172-31-8-159 /]# ls -l /dev | grep sda
[root@ip-172-31-8-159 /]# ls -l /dev | grep xvde
lrwxrwxrwx. 1 root root 5 1月 13 10:43 2016 root -> xvde1
brw-rw----. 1 root disk 202, 64 1月 13 10:43 2016 xvde
brw-rw----. 1 root disk 202, 65 1月 13 10:43 2016 xvde1

もう一度スナップショットから起動できる?

今回のケースでは、ルートデバイス名をデフォルトから変更してしまったので、 再度同じようにインスタンスからスナップショットを取得しAMI作成、 インスタンスの複製が問題なくできるか、確認しておきたいと思います。

例えばルートデバイス名を /dev/sda として起動した場合、 同様の手順でスナップショットからイメージを作成しようとすると、 ルートデバイス名が /dev/sda1 となっていました。

これは今回の起動に失敗するパターンでしたが、、、やはり同様の症状で起動できませんでした。

しかし、先ほどと同じようにデバイス名を /dev/sda とすることで起動することができました。少々手間ですが、イメージ作成時にきちんとルートデバイス名を指定することで、通常どおりインスタンスを起動できるようです。

ルートデバイス名が /dev/xvde の場合も同様の現象となりました。

まとめ

CentOS 6で提供されている公式AMIのうちでもちょっと古めの6.3を使用した場合で、 EBSスナップショットを経由してイメージ作成、インスタンスを起動した場合に、 ルートデバイス名を意図的に指定しないとうまく起動できなかった、 という話でした。

私個人的に、スナップショットからAMIを作成するときはカーネルID、RAMディスクIDは気をつける意識があったのですが、 ルートデバイスについても注意が必要ということを実感しました。

CentOSは7がリリースされていますし、 6を使用する際も敢えてRelease Mediaで古いバージョン指定する、 ということはあまり思いますので、だいぶレアケースな問題かと思います。 が、これまで起動していたインスタンスを複製する場合などの際にご注意いただければと思います。

最後に今回の一件を通して得られたことを教訓のようにまとめて締めとさせていただきます。

  • インスタンス複製の際には直接AMIを作成したほうがトラブルは少ない
  • スナップショットからAMIを作る場合はカーネルID、RAMディスクID、ルートデバイス名に注意する
  • EC2の起動で問題が発生したらシステムログを見てみる