この起動プロンプトで立ち往生しているインスタンスがあります（管理コンソールからインスタンスログを見てください）。
The disk drive for /mydisk is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery
EBSボリュームを追加してマウントしてから、EBSボリュームを削除し、/ etc / fstabからエントリを削除するのを忘れて、マシンを再起動しました。起動時にプロンプトが表示され、インスタンスにSSHで接続できません。
この問題を解決するにはどうすればよいですか？
回答:
私はあなたの問題の「簡単な」解決策を知りませんが、（ルートデバイスの種類によっては）多少複雑な解決策があります。
インスタンスにEBSルートがある場合、ソリューションは非常に簡単です。インスタンスを停止し、EBSドライブを切り離し、別のインスタンスを起動して、それにEBSボリュームを接続します。必要に応じてfstabファイルを編集し、EBSボリュームを切り離して、元のインスタンスに再接続します。
インスタンスにS3ベースのルート（つまり、インスタンスストア）がある場合、ソリューションは少し難しくなります。AMIからデータをダウンロードし（ec2-download-bundleを使用）、そのデータを単一のファイルに抽出します（ec2-unbundleを使用）。次に、イメージをマウントし、必要な変更を加えて、イメージを再バンドルします（ec2-bundle-volを使用して、-vフラグでバンドルするデフォルトのボリュームを上書きします）。これにより、行った変更を除いて、古いものと同じ新しい実行可能なAMIが得られます。または、ddを使用してイメージファイルのコンテンツをEBSボリュームにコピーしてから、EBSルートバックアップインスタンスに変換することもできます。
nofailを/etc/fstabした場合に備えて追加することは賢明でしょうか？おそらく、「エラー」（で説明fstab(5)）が起動プロセスを妨げることはありません。
nobootwait-試したnofailことはありません-それらの間には微妙な違いがあると思います。
ubuntuにがある場合、最後の2行をsystemd編集/lib/systemd/system/local-fs.targetしてコメント化できます。
#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly
私はこれを広範囲にテストしておらず、リスクや副作用が含まれているかどうかはわかりませんが、今のところそれは魅力的なように機能します。ルートボリュームと他のすべてのボリューム（明らかに構成が正しくないボリュームを除く）をマウントし、SSHが起動するまでブートプロセスを続行するため、インスタンスに接続して誤ったfstabエントリを修正できます。