t1.microを起動できない

0

いつもお世話になっております。
本日からt1タイプなどの旧タイプインスタンスが起動しません。

ec2の状態を見ると
・システムステータスのチェック ・・・成功
・インスタンスステータスのチェック ・・・失敗

AWS WEBコンソールからシステムのログも見ることもできません。

i-0f0827595d6130bd2
i-01c8c6ef5ecdf977a
i-02718c7021d60b92a

STOP/START、再起動、インスタンスタイプを変更したりゾーンを変更したり
AMIからEC2を作成し直ししたりしても結果は同じです。
このような場合どのような対応を取ればいいでしょうか。

よろしくお願いします。

ふるせ

質問済み 6年前251ビュー
11回答
0

私も同様の現象です
Amazon EC2 Instance Reboot Maintenance
でrebootしたところ、インスタンスステータスのチェックでエラーとなり起動できません。

同じように対象インスタンスが10台ぐらいあるので、何か回避策はありませんでしょうか?

よろしくお願いいたします。

4suta
回答済み 6年前
0

こちらは既に実施済みでしょうか?

ステータスチェックに失敗したインスタンスのトラブルシューティング - システムログの取得
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstances.html#troubleshooting-retrieve-system-logs

インスタンスステータスのチェックの失敗という事ですので、システムログから何か原因が分かる可能性があると考えます。

semnil
回答済み 6年前
0

ご確認ありがとうございます。

システムログですが、
私の場合、「インスタンスの設定=>システムログの取得」で見ても、まっさらで、何も表示されていない状態です。

別インスタンスに、該当rootボリュームをマウントして、/var/log/messageを確認してみましたが、これといってエラーはありませんでした。何も情報がない状態で、恐縮ですが、他にどこをあたらればよさそうかお分かりになれば、ご教授いただければ幸いです。

よろしくお願いいたします。

4suta
回答済み 6年前
0

ここから先は私も経験がなく、不確かな情報になってしまう可能性が高いですがご容赦ください。
何か解決のヒントになればと考えております。

起動できなくなっているインスタンスの詳細がわからないので予想になってしまいますが、PV-GRUB を使用してカスタムカーネルを起動しているのであれば、以下の手順で PV-GRUB のバージョン確認、更新を試してみても良いかもしれません。

ユーザー提供カーネル - PV-GRUB の更新
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/UserProvidedKernels.html#UpdatingPV-GRUB

今回調べて痛感しましたが、全体的に PV 方式はもう情報を見つけることも困難になってきていますので、早急に HVM への移行を検討された方が良いと思います。
状況によっては、既存のインスタンスの起動を諦めて新しいインスタンスに EBS からデータコピーで移行してしまうことも現実的な選択になるかと考えます。
解決が難しい場合は、サポートへの問い合わせも検討された方が良いかもしれません。

semnil
回答済み 6年前
0

お世話になっております。

アドバイスありがとうございます。
アドバイスを元に、カーネルを「aki-f975a998」へ更新を試してみたところ、相変わらず起動はできなく同じ状態なのですが、システムログは出力されるようになりました。

ログを確認すると、以下が当てはまるようなのですが、、、
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstances.html?icmpid=docs_ec2_console#OpSystemGrub

上記ページの「推薦する処置」の「5.GRUB 設定ファイルを作成します。」のところでつまずいております。
情報もあまりなく、どのように作ればよいか、アドバイス頂けますでしょうか

おっしゃるとおり、HVMの移行を検討しておりますが、メンテナンスリブートまで日数もないため、なんとか、解決策がないかお力添えいただければ助かります。

よろしくお願いいたします。

4suta
回答済み 6年前
0

GRUB 設定ファイルが存在しないということなので、PV-GRUB を使用していないのかもしれません。
インスタンス初回作成時に使用した AMI の詳細 (パブリックで検索可能であれば ami-id、OS、i386/x64、EBS/S3 など) を伺ってもよろしいでしょうか。
また、更新前のインスタンスで、以下を実行した結果を教えていただけないでしょうか。

aws ec2 describe-instance-attribute --instance-id <instance_id> --attribute kernel --region ap-northeast-1
aws ec2 describe-images --image-ids <KernelId> --region ap-northeast-1

一から作成するのではなく、同様の構成で PV-GRUB を使用している AMI を探して /boot の中身 (GRUB 設定ファイル、カーネルイメージ) をコピーする方法を考えています。

semnil
回答済み 6年前
0

お世話になっております。ご返信ありがとうございます。

すみません、PV-GRUB を使用していないのかもしれません。

更新前のですと、以下となっております。
aws ec2 describe-instance-attribute --instance-id i-5c32425d --attribute kernel --region ap-northeast-1
{
"InstanceId": "i-5c32425d",
"KernelId": {
"Value": "aki-a209a2a3"
}
}

aws ec2 describe-images --image-ids aki-a209a2a3 --region ap-northeast-1
{
"Images": [
{
"VirtualizationType": "paravirtual",
"Hypervisor": "xen",
"ImageOwnerAlias": "amazon",
"ImageId": "aki-a209a2a3",
"State": "available",
"BlockDeviceMappings": [],
"Architecture": "i386",
"ImageLocation": "ec2-public-images-ap-northeast-1/ec2-vmlinuz-2.6.21.7-2.fc8xen.i386.manifest.xml",
"RootDeviceType": "instance-store",
"OwnerId": "206029621532",
"CreationDate": "2010-12-06T14:17:50.000Z",
"Public": true,
"ImageType": "kernel"
}
]
}

これを、最新のカーネル「aki-f975a998」へ更新してみたところ、上記のエラーが出る様になりました。

よろしくお願いいたします。

4suta
回答済み 6年前
0

情報ありがとうございます。
aki-a209a2a3 を使用している以下の AMI を見つけて今回の現象 (ステータスチェック 1/2) を再現することができました。
RightImage_CentOS_5.4_i386_v5.6.28_EBS (ami-f0e842f1) ※1

最近同様の問題を報告している方を他にも見つけましたので、これまで通りに aki-a209a2a3 が利用できない状況が発生していると考えられます (AWS による何らかの変更が原因と思われます)。
https://forums.aws.amazon.com/thread.jspa?messageID=819499

一から作成するのではなく、同様の構成で PV-GRUB を使用している AMI を探して /boot の中身 (GRUB 設定ファイル、カーネルイメージ) をコピーする方法を考えています。
実際に近い構成と思われる以下の AMI を使用して試してみました。
RightImage_CentOS_5.6_i386_v5.7.14_EBS (ami-7a41f47b) ※2

(1) ※1 のインスタンスを停止、ボリュームをデタッチして ※2 のインスタンスにアタッチ (/dev/sdf)
(2) ※2 のインスタンスで ※1 のボリュームをマウント (mkdir /mnt/data ; mount /dev/sdf /mnt/data)
(3) ※1 の /boot を退避 (mv /mnt/data/boot /mnt/data/boot.old)
(4) ※2 の /boot を ※1 の / にコピー (cp -r /boot /mnt/data/.)
(5) ※2 のインスタンスを停止、※1 のボリューム を ※2 からデタッチ、※1 のインスタンスにアタッチ (/dev/sda1)
(6) ※1 のカーネル ID を変更 (aki-a209a2a3 -> aki-f975a998)
(7) ※1 のインスタンスを開始

上記の手順でとりあえずステータスチェック 2/2、ssh 可能な状態にすることができました (それ以上の動作確認はしていません)。
もしお手元の環境で試される際は、元の環境を破壊する可能性がありますので、試す場合は事前に snapshot 取得するなど十分にご注意ください。
ディストリビューション、カーネルのバージョンが上記と異なる場合は他の AMI を探す事になると思います。
また、この手順である程度動いたとしてもパッケージ管理などを無視した暫定処置のため、本運用には耐えないと考えています。

semnil
回答済み 6年前
0

お世話になっております。
アドバイスありがとうございます。

教えて頂いた手順で、なんとか起動できました。

まさに、こういった事が出来ないかと思っていたのですが、具体的な手順が見つからず暗礁に乗り上げておりました。

さらに、的確でわかりやすい内容でご説明頂き大変助かりました。

一時的なしのぎにはなると思いますが、これで、なんとか年は越せそうです。。

いろいろと、ありがとうございました。

4suta
回答済み 6年前
0

教えていただいた手順で私の方も起動できるようになりました。

回答済み 6年前
0

他のスレッドで再び起動できるようになったとの報告がありました。
おそらく AWS 側で何かを直したのではないかとの事です。

https://forums.aws.amazon.com/message.jspa?messageID=820898#820898

semnil
回答済み 6年前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

質問に答えるためのガイドライン

関連するコンテンツ