起動障害からの回復

Solaris ボリュームマネージャではルート (/)、swap、および /usr ディレクトリをミラー化できるため、システムの起動時に、ハードウェア障害やオペレータの操作ミスによって特殊な障害が発生することがあります。 この節の作業は、そのような障害に対処するためのものです。

次の表に、そのような障害の原因と適切な解決方法を示します。

起動障害の背景情報

• エラーのためにボリュームが Solaris ボリュームマネージャによってオフラインにされた場合は、障害が発生したディスクにあるすべてのファイルシステムのマウントを解除する必要があります。 個々のディスクスライスは独立しているため、 同じディスクに複数のファイルシステムがマウントされていることがあります。 ドライバソフトウェアに障害が発生した場合には、同じディスクの他のスライスでもまもなく障害が発生するはずです。 ディスクスライスに直接マウントされているファイルシステムは Solaris ボリュームマネージャのエラー処理対象ではないため、そのようなファイルシステムをマウントしたままにしておくと、システムのクラッシュによってデータを失う恐れがあります。

• サブミラーを無効な状態やオフラインのままにしておく時間を最小限に抑えます。 再同期やオンラインバックアップの処理中は、ミラー化による保護は不完全になります。

/etc/vfstab 内の不適切なエントリを修正するには

たとえば、ルート (/) をミラー化するときに、/etc/vfstab ファイルに不適切なエントリを設定した場合、システムは最初は正しく起動しているように見えますが、やがて起動に失敗します。 この問題を解決するためには、シングルユーザーモードで /etc/vfstab ファイルを編集する必要があります。

/etc/vfstab ファイル内の不適切なエントリを修正するおおよその手順は次のとおりです。

1. シングルユーザーモードでシステムを起動します。

2. ミラーボリュームに対して fsck コマンドを実行します。

3. ファイルシステムを読み取り/書き込みモードでマウントし直します。

4. (省略可能) ルート (/) ミラーに対して metaroot コマンドを実行します。

5. /etc/vfstab ファイル内のファイルシステムエントリがこのボリュームを参照していることを確認します。

6. 再起動します。

ルート (/) RAID 1 (ミラー) ボリュームを回復する

次の例では、ルート (/) が 2 面ミラー d0 でミラー化されています。 /etc/vfstab ファイルのルート (/) エントリが何らかの理由でこのファイルシステムの元のスライスに戻されていますが、/etc/system ファイルの情報は、起動がミラー d0 から行われるようになっています。 最も一般的な原因としては、metaroot コマンドを使わずに /etc/system や /etc/vfstab ファイルを変更したか、/etc/vfstab ファイルの古いコピーを復元したことが考えられます。

間違った /etc/vfstab ファイルの例を以下に示します。

#device        device          mount          FS      fsck   mount    mount
#to mount      to fsck         point          type    pass   at boot  options
#
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0  /       ufs      1     no       -
/dev/dsk/c0t3d0s1 -                   -       swap     -     no       -
/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6  /usr    ufs      2     no       -
#
/proc             -                  /proc    proc     -     no       -
swap              -                  /tmp     tmpfs    -     yes      -

エラーがあるために、システムは、起動時に自動的にシングルユーザーモードになります。

ok boot
...
configuring network interfaces: hme0.
Hostname: lexicon
mount: /dev/dsk/c0t3d0s0 is not this fstype.
setmnt: Cannot open /etc/mnttab for writing

INIT: Cannot create /var/adm/utmp or /var/adm/utmpx

INIT: failed write of utmpx entry:"  "

INIT: failed write of utmpx entry:"  "

INIT: SINGLE USER MODE

Type Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): root-password>

この時点では、ルート (/) と /usr は読み取り専用でマウントされています。 次の手順を実行します。

手順

1. ルート (/) ミラーに対して fsck コマンドを実行します。

   ---

   注

   ルートのボリューム名を間違えないでください。

   ---

   # fsck /dev/md/rdsk/d0 ** /dev/md/rdsk/d0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2274 files, 11815 used, 10302 free (158 frags, 1268 blocks, 0.7% fragmentation)

2. /etc/vfstab ファイルを編集できるように、ルート (/) を読み取り/書き込みモードでマウントし直します。

   # mount -o rw,remount /dev/md/dsk/d0 / mount: warning: cannot lock temp file /etc/.mnt.lock>

3. metaroot コマンドを実行します。

   # metaroot d0

   このコマンドを実行すると、/etc/system と /etc/vfstab ファイルが編集され、ルート (/) ファイルシステムのエントリがボリューム d0 を参照します。

4. /etc/vfstab ファイルに正しいボリュームのエントリが含まれていることを確認します。

   /etc/vfstab ファイルのルート (/) エントリは次のようになっているはずです。これによって、ファイルシステムのエントリは RAID 1 ボリュームを正しく参照します。

   #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no - /dev/dsk/c0t3d0s1 - - swap - no - /dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no - # /proc - /proc proc - no - swap - /tmp tmpfs - yes -

5. システムを再起動します。

   システムは正常な動作に戻ります。

起動デバイスの障害から回復するには

ルート (/) がミラー化されているシステムの起動デバイスに障害がある場合は、代替起動デバイスを設定する必要があります。

この手順の概要は次のとおりです。

• 代替ルート (/) サブミラーからシステムを起動します。

• エラーのある状態データベースの複製とボリュームを特定します。

• 不良ディスクを修復します。

• 状態データベースの複製とボリュームを元の状態に復元します。

次の例では、6 つの状態データベースの複製のうち 2 つが起動デバイスにあり、ルート (/)、swap、および /usr の各サブミラーが使用不能になっています。

起動デバイスに障害が発生すると、最初に次のようなメッセージが表示されます。 このメッセージは、アーキテクチャによってこれとは異なる場合があります。

Rebooting with command:
Boot device: /iommu/sbus/dma@f,81000/esp@f,80000/sd@3,0   
The selected SCSI device is not responding
Can't open boot device
...

このメッセージが表示された場合は、このデバイス名を書き留めておき、 次の手順を実行します。

手順

1. ルート (/) の別のサブミラーからシステムを起動します。

   この例では 2 つの状態データベースの複製だけが異常であるため、システムを起動することができます。 起動できない場合は、アクセスできない状態データベースの複製をシングルユーザーモードで削除する必要があります。 この手順については、「状態データベースの複製数の不足から回復するには」を参照してください。

   ルート (/) ファイルシステムのミラーを作成したときに、その手順の中で代替起動デバイスを書き留めてあるはずです。 この例では、disk2 が代替起動デバイスになります。

   ok boot disk2 SunOS Release 5.9 Version s81_51 64-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Hostname: demo ... demo console login: root Password: root-password> Dec 16 12:22:09 lexicon login: ROOT LOGIN /dev/console Last login: Wed Dec 12 10:55:16 on console Sun Microsystems Inc. SunOS 5.9 s81_51 May 2002 ...

2. metadb コマンドを使って、2 つの状態データベースの複製が使用不能であることを確認します。

   # metadb flags first blk block count M p unknown unknown /dev/dsk/c0t3d0s3 M p unknown unknown /dev/dsk/c0t3d0s3 a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3

   不良ディスクの一部であるスライス /dev/dsk/c0t3d0s3 上の状態データベースの複製は、システムから認識されません。

3. metastat コマンドを使って、ルート (/)、swap、および /usr の各ミラーの半分が使用不能であることを確認します。

   # metastat d0: Mirror Submirror 0: d10 State: Needs maintenance Submirror 1: d20 State: Okay ... d10: Submirror of d0 State: Needs maintenance Invoke: "metareplace d0 /dev/dsk/c0t3d0s0 new device>" Size: 47628 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s0 0 No Maintenance d20: Submirror of d0 State: Okay Size: 47628 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s0 0 No Okay d1: Mirror Submirror 0: d11 State: Needs maintenance Submirror 1: d21 State: Okay ... d11: Submirror of d1 State: Needs maintenance Invoke: "metareplace d1 /dev/dsk/c0t3d0s1 new device>" Size: 69660 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s1 0 No Maintenance d21: Submirror of d1 State: Okay Size: 69660 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s1 0 No Okay d2: Mirror Submirror 0: d12 State: Needs maintenance Submirror 1: d22 State: Okay ... d2: Mirror Submirror 0: d12 State: Needs maintenance Submirror 1: d22 State: Okay ... d12: Submirror of d2 State: Needs maintenance Invoke: "metareplace d2 /dev/dsk/c0t3d0s6 new device>" Size: 286740 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s6 0 No Maintenance d22: Submirror of d2 State: Okay Size: 286740 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s6 0 No Okay

   この例では、次のサブミラーの保守が必要であることがわかります。

   • サブミラー d10、デバイス c0t3d0s0

   • サブミラー d11、デバイス c0t3d0s1

   • サブミラー d12、デバイス c0t3d0s6

4. システムを停止し、ディスクを交換し、format コマンドまたは fmthard コマンドを使用して、障害の発生前と同じようにディスクをパーティション分割します。

   ---

   ヒント

   新しいディスクが他方のディスク (つまり、ミラーの別の半分があるディスク) と同じ構成であれば、prtvtoc /dev/rdsk/c0t2d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2 を使って、新しいディスク (c0t3d0) を短時間でフォーマットできます。

   ---

   # halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0

5. システムを再起動します。

   ここでは、ルート (/) ミラーの他方の半分から起動する必要があります。 この代替起動デバイスは、ミラーを作成したときに書き留めておいたものです。

   # halt ... ok boot disk2

6. metadb コマンドを使って、使用不能な状態データベースの複製を削除してから、新しい複製を追加します。

   # metadb flags first blk block count M p unknown unknown /dev/dsk/c0t3d0s3 M p unknown unknown /dev/dsk/c0t3d0s3 a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3 # metadb -d c0t3d0s3 # metadb -c 2 -a c0t3d0s3 # metadb flags first blk block count a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3 a u 16 1034 /dev/dsk/c0t3d0s3 a u 1050 1034 /dev/dsk/c0t3d0s3

7. metareplace コマンドを使用して、サブミラーを再び有効にします。

   # metareplace -e d0 c0t3d0s0 Device /dev/dsk/c0t3d0s0 is enabled # metareplace -e d1 c0t3d0s1 Device /dev/dsk/c0t3d0s1 is enabled # metareplace -e d2 c0t3d0s6 Device /dev/dsk/c0t3d0s6 is enabled

   しばらくすると、再同期処理が終了します。 これで、また元のデバイスから起動できるようになります。