ヘッドレスサーバーを考えてみましょう。つまり、ストック（Ubuntuイメージなど）を使用してリモートで初期化するリモートロケーションの一般的なx86システムです。初期化後は、SSH経由でのみログインまたはリモートでリセットできます。つまり、BIOSまたはブートマネージャのプロンプト（Grub 1など）にアクセスできません。
任意の種類のKVMを使用できますが、KVMは使用コストが非常に高く、時間単位で予約する必要があります。
状況を考えると、スタートアップの問題について妄想的な人がいるかもしれません。たとえば、
- カーネルのアップグレードが失敗した場合はどうなりますか？
- 初期起動中のfsckプロンプトはどうですか？まだSSHが利用できない可能性があります。
注意が必要な他の問題はありますか？
menu.lstカーネルアップグレードの場合は、序文に次のものを含めるようにgrub（レガシー）を設定します。
default saved
fallback 2 # counts from 0
最初の項目は次に終了します。
savedefault fallback
最初の grub エントリはアップグレードされたカーネルであり、3 番目のエントリは既知の動作カーネルです。また見てください代替ブートの grub マニュアルセクション。
成功した起動時にデフォルトの項目設定をリセットするために、起動スクリプト/etc/rc.local（Debianなどのシステム上）を変更しました。
grub-set-default 0
このグラブ設定は機能しますが、たとえばUbuntuではデフォルトではなく、menu.lstすべてのカーネル更新後に手動で調整する必要があります。
私は供給する
panic=60
カーネルパラメータとして、たとえば、パラメータが誤ってroot=いるかカーネルが破損している場合、エラーが発生したときにシステムが自動的に再起動されます。
fsckの問題に関して、最善のアプローチが何であるかよくわかりません。 Debian に似たシステムでは、以下を設定できます。
FSCKFIX=yes
in /etc/default/rcS、デフォルトではfsckに自動的に回復するように指示します。
しかし、自動回復が失敗した場合、リモートアクセスが不可能であるというメッセージが表示されることはありますか？
または、6番目の列のゼロを使用してfsckチェックを無効にできますか？/etc/fstabfsエラーが発生した場合は、システムを再初期化してバックアップを復元すると、すべてのfsckの問題を回避できますか？
ベストアンサー1
真剣に言えば、プロバイダが極端なケースに対して無料（または少なくとも安価な）手動サポートを提供していない場合は、切り替える必要があります。そうでなければ、設定に非常に満足しているようです。
システムがfsckの回復以上に破損した場合、完全に再インストールする以外にできることはあまりありません。致命的なハードウェア障害を除いて、実際にこのようなことが起こっているのを見たことはありません。
注意すべき点が1つあります。これらのマシンでは、安定したディストリビューション（Debian、RHEL、SLES）を選択してアップグレードする前に、適切な時間を待つ必要があります（新しいバージョンは少なくとも6ヶ月間安定しています）。