ドライバのバグにより、システムがブートできなくなる場合があります。このセクションで説明するように、予防策を実施しておくことで、このようなイベントが発生した場合でもシステムの再インストールを回避できます。
多数のドライバ関連システムファイルを再構築することは、不可能でないにしても非常に困難です。インストール中にドライバが原因でシステムがクラッシュすると、/etc/name_to_major、/etc/driver_aliases、/etc/driver_classes、/etc/minor_perm などのファイルが破壊する可能性があります。add_drv(1M) のマニュアルページを参照してください。
念のため、テストシステムが適切な構成になってから、beadm(1M) コマンドを使用して、ルートファイルシステムのバックアップコピーを作成してください。/etc/system ファイルの変更を予定している場合には、変更を実施する前にこのファイルのバックアップコピーを作成します。
詳細は、Oracle Solaris 11.3 ブート環境の作成と管理 の 第 4 章, ブート環境の管理およびOracle Solaris 11.3 での ZFS ファイルシステムの管理 の ZFS ルートファイルシステムからのブートを参照してください。
システムがネットワークに接続されている場合、テストシステムをサーバーのクライアントとして追加できます。問題が発生した場合には、ネットワークからシステムをブートできます。その後、ローカルディスクをマウントして任意の修正を行えます。Oracle Solaris システムの CD-ROM から直接システムをブートすることもできます。
障害から復旧するためのもう 1 つの方法は、別のブート可能なルートファイルシステムを用意することです。format(1M) を使用して、元のパーティションとまったく同じサイズのパーティションを作成します。次に、dd(1M) を使用して、そのブート可能なルートファイルシステムをコピーします。コピーの完了後、新しいファイルシステムに対して fsck(1M) を実行し、その整合性を確認します。
その後、元のルートパーティションからシステムをブートできなくなったら、バックアップパーティションをブートします。dd(1M) を使用してバックアップパーティションを元のパーティションにコピーします。ルートファイルシステムが破損していないにもかかわらず、システムをブートできないような状況が発生する可能性もあります。たとえば、破損箇所がブートブロックやブートプログラムに限定されていることがあります。そのような場合は、ask (–a) オプションを使用してバックアップパーティションからブートできます。その後、元のファイルシステムをルートファイルシステムとして指定できます。
システムがパニック状態になると、システムはカーネルメモリーのイメージをダンプデバイスに書き込みます。デフォルトでは、もっとも適したスワップデバイスがダンプデバイスになります。このダンプはシステムのクラッシュダンプであり、アプリケーションによって生成されるコアダンプに似ています。パニックが発生したあとのリブート時に、savecore(1M) はダンプデバイス内でクラッシュダンプの存在の有無をチェックします。ダンプが見つかった場合、savecore は、unix.n という名前のカーネルシンボルテーブルのコピーを作成します。次に savecore ユーティリティーは、vmcore.n という名前のコアファイルをコアイメージディレクトリ内にダンプします。デフォルトでは、コアイメージディレクトリは /var/crash/machine_name になります。/var/crash の容量不足によりコアダンプを格納できない場合には、システムによって必要な容量が表示されるものの、実際のダンプの保存が行われません。その後、コアダンプや保存済みカーネルに対して mdb(1) デバッガを使用できます。
Oracle Solaris オペレーティングシステムでは、クラッシュダンプはデフォルトで有効になっています。dumpadm(1M) コマンドは、システムクラッシュダンプを構成するために使用されます。dumpadm コマンドを使用すると、クラッシュダンプが有効になっていることを確認したり、保存されたコアファイルの場所を特定したりできます。