92410
EC2インスタンスのルートボリュームを縮小作業して接続し直すとファイルシステムエラーが発生します。  
作業手順はこの記事  
<https://qiita.com/miyasakura_/items/22d3601e06b583551301>  
を参考に作業を行いました。

この作業で、ボリュームをルートボリュームとして付け直してEC2インスタンスを再起動することでステータスチェックが2/2で成功するインスタンスもあるのですが、失敗するものもあります。

この失敗をなくすため、縮小に成功したインスタンス毎、AMIにイメージ化し、  
そのAMIを使用し、インスタンスを立ち上げなおすのですが、  
そうするとどうしてもステータスチェックが1/2で失敗してしまいます。

ステータスチェックが失敗するとsshも出来ず、システムログも取得できないため、原因特定が難しいです。

この症状の原因と対策に何が考えられるでしょうか？
CC BY-SA 4.0
2022-11-24T05:24:36.007
92398
2022-11-24T11:20:54.270
2022-11-24T08:32:39.523
36855
36855
question
aws amazon-ec2
EC2インスタンスのルートボリュームを縮小作業して接続し直すとファイルシステムエラーが発生します。
参照された記事の冒頭には

> 使用しているLinuxやパーティションの構成により方法は異なります。  
>  本記事では以下の環境の場合の手順例をご紹介します。
>
>   * LVMを使用している
>   * ブートローダーはGRUB2(Stage1.5を使用している)
>   * OSはLinux (本記事では RedHatEnterpriseLinux 7.5)
>   * 作業用のEC2はt2インスタンス
>

と書かれています。grubでエラーが出ているとのことですが、「ブートローダーはGRUB2(Stage1.5を使用している)」と条件は一致していますでしょうか？
質問文には環境に関する情報がないのでわかりませんが、一致していないのであれば別の手順が必要かと思います。

* * *

> どうしてもステータスチェックが1/2で失敗してしまいます。

ステータスチェックをブラックボックスと思われているかもしれませんが、[インスタンスのステータスチェック](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-
system-instance-status-check.html)である程度説明されています。ステータスチェックには2種類あり、

  * システムステータスのチェック  
主にAWSの責任となるハードウェアの正常性チェック。

  * インスタンスステータスのチェック  
ネットワークインターフェースがARP応答するかのチェック。OSがネットワークインターフェースを初期化しIPアドレスを与えないとARP応答できないため、OSが初期化できているかのチェックとして機能する。

厳密にはインスタンスのメトリクスを見る必要がありますが、質問の背景からほぼ確実にインスタンスステータスのチェックに失敗したために **1/2**
なのだと思います。  
原因も明快で、OSがネットワークインターフェースを初期化するところまで起動できていないからです。  
ネットワークインターフェースを初期化できていない以上、sshできないのも当然と思われます。
CC BY-SA 4.0
2022-11-24T07:17:29.463
92402
2022-11-24T09:19:23.573
2022-11-24T09:19:23.573
4236
4236
92398
answer
<作業手順はこの記事>の手順でxfsをext4でフォーマットしてるのでファイルシステムが壊れていることが考えられます。
CC BY-SA 4.0
2022-11-24T11:20:54.270
92410
2022-11-24T11:20:54.270
39754
92398
answer