web-dev-qa-db-ja.com

Amazon EC2インスタンスが起動しない：カーネルパニック-同期しない：VFS：ルートブロックをunknown-block（0,0）にマウントできません

私のインスタンスは何年も実行されていて、突然6月1日に応答を停止しました。再起動しようとしたが起動しない。システムログにエラーが発生しました： https://Pastebin.com/rSxr1kLs

Linuxバージョン2.6.32-642.11.1.el6.x86_64（[email protected]）（gccバージョン4.4.7 20120313（Red Hat 4.4.7-17）（GCC））＃1 SMP金11月18日19:25:05 2016年UTC
カーネルコマンドライン：root =/dev/xvde ro LANG = en_US.UTF-8 KEYTABLE = us
VFS：ルートデバイス「xvde」またはunknown-block（0,0）を開けません
正しい「root =」ブートオプションを追加してください。利用可能なパーティションは次のとおりです。
カーネルパニック-同期していません：VFS：ルートfsをunknown-block（0,0）にマウントできません

ドキュメントに従って、EBSボリュームをデタッチして_/dev/sda1_として再アタッチしようとしました： https://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#FilesystemKernel

ただし、エラー_Error attaching volume: Invalid value '/dev/sda1' for unixDevice. Attachment point /dev/sda1 is already in use_が発生し、添付できませんでした。 _/dev/sda_として再接続しましたが、まだ起動せず、システムログにエラーが表示されます。

新しいインスタンスをまったく同じアベイラビリティーゾーンで起動し、EBSボリュームを_/dev/sdf_としてアタッチできました。インスタンス内では_/dev/xvdj_として表示されます。 _mount /dev/xvdj /xvdj_でマウントしました。 _grub.conf_ファイルを見ることができます：

_[root@ip-172-31-4-249 grub]# cat /xvdj/boot/grub/grub.conf
default=0
timeout=1

title CentOS (2.6.32-642.11.1.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-642.11.1.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
title CentOS (2.6.32-504.30.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.30.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.30.3.el6.x86_64.img
title CentOS (2.6.32-504.3.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.3.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.3.3.el6.x86_64.img
title CentOS (2.6.32-504.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-504.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-504.el6.x86_64.img
title CentOS (2.6.32-431.29.2.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.29.2.el6.x86_64.img
title CentOS (2.6.32-431.23.3.el6.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-431.23.3.el6.x86_64 root=/dev/xvde ro crashkernel=auto LANG=en_US.UTF-8 KEYTABLE=us
        initrd /boot/initramfs-2.6.32-431.23.3.el6.x86_64.img
_

これは、実行中のインスタンスの_grub.conf_と比較します。

_[root@ip-172-31-4-249 grub]# cat /boot/grub/grub.conf
default=0
timeout=1

title CentOS-6-x86_64-20130527-03 2.6.32-358.6.2.el6.x86_64
        root (hd0)
        kernel /boot/vmlinuz-2.6.32-358.6.2.el6.x86_64 root=/dev/xvde ro
        initrd /boot/initramfs-2.6.32-358.6.2.el6.x86_64.img
_

最初のオプションにinitrd行がないことは重要ですか？

_/dev/sda_を使用してEBSボリュームを新しいインスタンスにマウントしようとしましたが、同じエラーKernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)でまだ起動しません。

CentOS 6

centosamazon-ec2centos6bootamazon-ebs
3
Chloe

[イメージ]> [AMI]> [プライベートイメージ]> [インスタンスが開始されたイメージを選択]> [起動]に移動して、新しいインスタンスを作成しました。私は米国または地域だけでなく、まったく同じアベイラビリティーゾーンで起動しましたが、2a、2b、2cも一致する必要があります。新しいインスタンスを停止しました。 EBSボリュームを古いインスタンスから切断しました。 EBSボリュームを/dev/sdfの新しいインスタンスに再接続しました。新しいインスタンスを開始しました。 EBSボリュームは/dev/xvdjとしてインスタンス内に表示されるため、mkdir /xvdj; mount /dev/xvdj /xvdjでマウントしました。 /xvdj/boot/grub/grub.confを編集し、default=0をdefault=1に変更しました。ファイルを保存し、新しいインスタンスを停止し、EBSボリュームを古いインスタンスに再接続して起動しました。古いインスタンスでyum updateを実行し、/boot/grub/grub.confを再確認し、再起動することを再確認しました。

また、CentOSカーネルの更新に関する次の情報も確認しました。 カーネル更新後にgrub.confにinitrdパスがない

yum updateを実行した後、initrdなしでgrub.confに2エントリがあったことに気付きました。 # yum reinstall kernel.x86_64を実行すると、これを修正できます。

5
Chloe

これと同じ問題が何度かあり、EBSスナップショットバックアップからインスタンスを復元することで解決する必要がありました。今日、私は同じ問題を抱えていて、バックアップから復元する必要なくそれを解決することにしました。私は次のことをしました：

  1. 失敗したインスタンス/ dev/sda1からルートボリュームを切り離します。
  2. ボリュームを動作中のインスタンスに接続し、ボリュームをマウントします（例：mount /dev/xvdh /xvdhmount）
  3. ブートフォルダをバックアップします：mv /xvdhmount/boot /xvdhmount/boot-backup
  4. 私の場合、同じバージョンのOSを使用して動作しているインスタンスから、RHEL 7.4はSCPまたはWinScpを介して/ bootフォルダーの内容全体を/ xvdhmount /にコピーします。
  5. 作業インスタンスからボリュームを切り離し、障害が発生したインスタンスに再度接続します。
  6. 失敗したインスタンスを起動します....インスタンスは起動しましたが、ログインできます。

これが役に立てば幸いです！

1
YohannesM

私も！

根本的な原因は、中断されたyum upgradeと仕事をしている部下のスタッフが再接続し、yum-complete-transactionsを実行してすべてを完了したことです。

ただし、何かが/boot/initrd....newver....にファイルを書き込まなかったため、grub2.cfgの最新のカーネルエントリにinitrd=/....行が完全に欠落している可能性があります。

クイックフィックスは、ブートディスクボリュームを別のインスタンスに再接続してマウントし、/mountpoint/etc/grub2.cfgを編集して、インスタンスが古いバージョンのカーネルを起動するようにすることでした。次に、再接続を解除して、元のインスタンスの/dev/sda1に再接続します。

注最近、centosブートボリュームを別のcentosマシンに接続するのは困難です。これは、UUIDがルートボリュームで同じであるためです。回避策は、CentOSディスクフィックスアップ用のDebianなど、別のOSを一時マシンとして使用することです。

再起動したら、yum reinstall kernel*を実行して不足している手順を繰り返し、完了時に再度再起動して、今回が正しく再起動し、最新のカーネル上にあることを確認します。

0
Criggie

同様の問題に遭遇しましたが、インスタンスの起動とAMIの作成ではAWS EC2のデフォルトが異なります。最初のケースではハードウェア仮想化（HVM）がデフォルトの選択ですが、イメージ作成のデフォルトは準仮想化（PV）です。

EBSボリュームのスナップショットを作成して新しいAMIを作成することにより、アベイラビリティーゾーン間でEC2インスタンスを移動しようとしたときに私はこれに遭遇しました。

tl; dr：カスタマイズされたAMIから起動するときにHVMを選択するだけで、インスタンスは正常に起動します。

0
Benny K

CentOSインスタンスでも同様の問題がありました。 このAWSサポート記事 は、かなり良い概要を提供します。これが私と私の問題を解決する方法です。

  • 元のEC2インスタンスをシャットダウンしてから、_/dev/sda1_ディスクを切り離します
  • 新しい一時的なEC2インスタンスを起動し、ディスクを_/dev/sdp_として新しいEC2インスタンスに接続します
  • 新しいEC2インスタンスにSSHで接続し、_/dev/sdp_を_/data_にマウントします。

次に、以前のカーネルに戻りたいと思いました。 CentOS wiki の指示は役に立ちました：

  • _grep "^menuentry" /data/boot/grub2/grub.cfg | cut -d "'" -f2_ですべてのGrubエントリを一覧表示します
  • 上から2番目を選択しました。私の場合、これはCentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)でした。
  • grub2-set-default --boot-directory /data/boot/ 'CentOS Linux (3.10.0-957.12.1.el7.x86_64) 7 (Core)'でブートのデフォルトを設定します

次に、新しいEC2インスタンスをシャットダウンし、ボリュームをデタッチして、元のインスタンスに（_/dev/sda1_に）接続し、初期インスタンスを起動します。

0
Benedikt Köppel

カーネルがアップグレードされて、ルートファイルシステムを理解できなくなったようです。あなたの最善の策は、新しいノードを作成し、古いものからEBSボリュームをマウントすることです非ルート/非ブートとしてデバイスで、重要なデータを転送します。

0
Jason Martin