次のようなヘッドレスサーバーについて考えてみます。リモートの場所にある典型的なx86ボックスで、ストック(たとえばUbuntuイメージ)を使用してリモートで初期化できます。初期化後は、ssh経由でのみログインできます。または、リモートでリセットできます。つまり、BIOSまたはブートマネージャーのプロンプト(Grub 1など)にアクセスできません。
おそらく、ある種のKVMが利用可能ですが、KVMの使用は非常に高価であり、1時間ごとに予約する必要があります。
このシナリオを考えると、ブートの問題について妄想を抱く可能性があります。例えば:
注意すべき他の落とし穴はありますか?
カーネルのアップグレードでは、menu.lst
プリアンブルに含まれるようにgrub(レガシーのもの)を構成します
default saved
fallback 2 # counts from 0
最初のエントリは次で終わります:
savedefault fallback
最初のgrubエントリはアップグレードされたカーネルであり、3番目は既知の動作しているカーネルです。 フォールバックブートのgrubマニュアルセクション も参照してください。
起動スクリプト/etc/rc.local
(Debianのようなシステム上)を変更して、起動が成功した場合にデフォルトのエントリ設定がリセットされるようにしました。
grub-set-default 0
このgrub-setupは機能しますが、たとえばUbuntuでは、これはデフォルトではなく、カーネルを更新するたびにmenu.lst
を手動で調整する必要があります。
私は供給します
panic=60
カーネルパラメータとして、例えばroot=
パラメータが間違っていたり、カーネルが壊れていたりすると、エラーが発生した場合にシステムが自動的に再起動します。
Fsckの問題について私は最善の方法が何であるかわかりません。 Debianのようなシステムでは設定できます
FSCKFIX=yes
/etc/default/rcS
内。これは、デフォルトでfsckに自動修復するように指示します。
しかし、自動修復が失敗した場合でも、リモートでアクセスできないプロンプトが表示される可能性がありますか?
あるいは、/etc/fstab
の6番目の列のゼロを介してfsckチェックを無効にすることもできます-fs-errorの場合、システムを再初期化してバックアップを復元するだけです-したがって、すべてのfsckトラブルを回避できますか?
真剣に、あなたのプロバイダーが極端な場合のために無料の(または少なくとも安い)手動支援を提供しないならば、それは切り替える時です。それ以外の場合は、セットアップはほぼ問題ないと思います。
システムが非常に壊れていてfsckで修正できない場合は、完全に再インストールする以外に行うことはほとんどありません。致命的なハードウェア障害が発生しない限り、これが実際に発生するのを見たことがありません。
注意すべきことが1つあります。このようなマシンの場合は、安定したディストリビューション(Debian、RHEL、SLES)を選択し、適切な期間が経過した後にのみ確実にアップグレードします(新しいバージョンは少なくとも6か月間安定します)。
Serial-over-sshアクセスを提供し、(関連する)シリアルポートをコンソールとして使用するようにLinuxインストールを構成するホスティングプロバイダーを探す必要があります(これを行う方法 依存 システムはupstartまたはsysVタイプの初期化を使用します)。 [〜#〜] bios [〜#〜] が利用可能であり、組み込みの画面デバイスではなくシリアルポートと通信することに注意してください。しかし、通常、それらは高価なハードウェアでのみ提供されます。
また、DTEを介してシリアルポートを制御する場合は、シリアルポートを使用するように grub に指示する必要があります。
調べることができるのは、dropbear(もちろん、別のポートで実行)、ネットワークを稼働させるのに十分なロジック、および必要に応じていくつかの回復ツールをロードする方法を含むカスタムinitrdを作成することです。これに基づいて、ネットワーク機能をロードし、SSHで接続できるようにする回復カーネル構成を作成して、システムに戻って回復を試みることができます。