次の場合には、ファイルシステムを対話式でチェックする必要があります。
マウントできない場合
使用中に不整合が発生する場合
使用中のファイルシステムの整合性が失われると、コンソールウィンドウやシステムメッセージファイルにエラーメッセージが出力されたり、システムがクラッシュしたりすることがあります。たとえば、システムメッセージファイル /var/adm/messages に次のようなメッセージが出力されることがあります。
Sep 5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected free inode 630916, run fsck(1M) |
hostname は、エラーを報告したシステムです。
fsck コマンドを使用する前に、fsck のエラーメッセージの解決方法について、fsck コマンドの構文とオプションおよび『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
fsck コマンドを実行して UFS ファイルシステムをチェックするときには、次の点を考慮してください。
fsck を使用してチェックするファイルシステムは、非アクティブでなければならない。ディスクにまだフラッシュされていないファイルシステムの変更がある場合、または fsck によるチェックが進行中にファイルシステムを変更した場合、それらの変更はファイルシステムの破壊と解釈されることがあり、検出された問題の信頼性が低下する可能性がある。
fsck を使用して修復するファイルシステムは、非アクティブでなければならない。ディスクにまだフラッシュされていないファイルシステムの変更がある場合、または fsck による修復が進行中にファイルシステムを変更した場合、ファイルシステムが破壊したり、システムがクラッシュすることがある。
fsck を使用する前に対象のファイルシステムをマウント解除して非アクティブにすること。これは、ファイルシステムのすべてのデータ構造について、できるだけ整合性を確保するためである。ただし、ルート (/) ファイルシステムと /usr ファイルシステムだけは、アクティブにする。これらのファイルシステムは、fsck を実行するためにマウントする必要がある。
ルート (/) ファイルシステムまたは /usr ファイルシステムを修復する必要がある場合には、可能であれば代替デバイスからシステムをブートすると、マウント解除されて非アクティブになる。
ルート (/) ファイルシステムまたは /usr ファイルシステムに対して fsck を実行する手順については、代替ブートデバイスからルート (/) ファイルシステムまたは /usr ファイルシステムをチェックする方法を参照。
この手順では、ローカル CD またはネットワークブートサーバーを利用でき、代替デバイスからシステムをブートできることを前提とします。
不正なスーパーブロックの復元については、不正なスーパーブロックを復元する方法を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
ルート (/) ファイルシステムがミラー化されているシステムの場合は、まずルート (/) ミラーを切り離して、その後で代替デバイスからブートしてください。接続した状態で操作すると、ファイルシステムが破壊する可能性があります。
ルート (/) ミラーの切り離しについては、『Solaris ボリュームマネージャの管理』の「サブミラーに関する作業」を参照してください。
チェックの必要なルート (/) ファイルシステムまたは /usr ファイルシステムのデバイス (/dev/dsk/c0t0d0s0 など) を特定します。
このデバイス名は、代替デバイスからブートした後で指定する必要があります。代替デバイスからブートした後でデバイスを特定するのは簡単ではありません。
チェックの必要なルート (/) ファイルシステムまたは /usr ファイルシステムのあるシステムを、ローカル CD またはネットワークなどの代替デバイスからブートします。このとき、これらのファイルシステム上でほかの動作が存在しないように、シングルユーザーモードでブートしてください。
たとえば、次のように入力します。
# init 0 ok boot net -s . . . # |
手順 3 で特定したルート (/) ファイルシステムまたは /usr ファイルシステムが含まれるデバイスをチェックします。
チェックまたは修復するファイルシステムのハードウェアが変更されている場合には、そのデバイス名も変更されている可能性があります。 fsck -n メッセージの「Last Mounted on ...」を利用して、そのファイルシステムのデバイスが予期したデバイスであることを確認してください。
たとえば、チェックするルートファイルシステムが /dev/dsk/c0t0d0s0 の場合は、次のように出力されます。
# fsck -n /dev/rdsk/c0t0d0s0 ** /dev/rdsk/c0t0d0s0 (NO WRITE) ** Last Mounted on / . . . fsck /dev/rdsk/c0t0d0s0 ** /dev/rdsk/c0t0d0s0 ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames . . . |
報告された fsck エラーをすべて修正します。
1 つまたは複数の UFS ファイルシステムを対話式でチェックしながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
「FILE SYSTEM STATE NOT SET TO OKAY」や「FILE SYSTEM MODIFIED」などのメッセージが表示される場合は、必要に応じて fsck コマンドをもう一度実行してください。
fsck コマンドは、一度の実行ではすべてのエラーを修正できないことがあります。
fsck コマンドを何度か実行してもすべての問題を修復できない場合は、fsck コマンドで修復できない UFS ファイルシステムの修正を参照してください。
修復したファイルシステムをマウントして、 lost+found ディレクトリにファイルが存在するかどうかを確認します。
fsck コマンドによって lost+found ディレクトリに入れられた各ファイルの名前は、その i ノード番号を使用して変更されます。可能であれば、ファイル名を変更し、ファイルが含まれるべきディレクトリに移動してください。grep コマンドを使用して各ファイル内の語句を探したり、file コマンドを使用してファイルタイプを識別できる場合もあります。
どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。
システムをマルチユーザーモードに戻します。
# init 6 |
代替デバイスからシングルユーザーモードでブートしている場合には、Control + D を押すと、Solaris のインストール処理が開始されます。
ルート (/) ファイルシステムがミラー化されているシステムの場合のみ、ルート (/) ミラーを再接続します。
この手順では、チェックするファイルシステムがマウント解除されていることを前提としています。
不正なスーパーブロックの復元については、不正なスーパーブロックを復元する方法を参照してください。
スーパーユーザーになるか、同等の役割を引き受けます。
最初にローカルファイルシステムをマウント解除し、ファイルシステム上でほかの動作が存在しないようにします。
fsck コマンドの引数として、マウントポイントディレクトリや /dev/dsk/ device-name を指定します。整合性が失われている場合には、そのことを示すメッセージが表示されます。
たとえば、次のように入力します。
# umount /export/home # fsck /dev/rdsk/c0t0d0s7 ** /dev/dsk/c0t0d0s7 ** Last Mounted on /export/home . . . |
報告された fsck エラーをすべて修正します。
1 つまたは複数の UFS ファイルシステムを対話式でチェックしながら、エラーメッセージのプロンプトに応答する方法については、『Solaris のシステム管理 (上級編)』の「UFS ファイルシステムの不整合解決 (手順)」を参照してください。
「FILE SYSTEM STATE NOT SET TO OKAY」や「FILE SYSTEM MODIFIED」というメッセージが表示される場合は、必要に応じて fsck コマンドをもう一度実行してください。
fsck コマンドは、一度の実行ではすべてのエラーを修正できないことがあります。
fsck コマンドを何度か実行してもすべての問題を修復できない場合は、fsck コマンドで修復できない UFS ファイルシステムの修正を参照してください。
修復したファイルシステムをマウントして、 lost+found ディレクトリにファイルが存在するかどうかを確認します。
fsck コマンドによって lost+found ディレクトリに入れられた各ファイルの名前は、その i ノード番号を使用して変更されます。可能であれば、ファイル名を変更し、ファイルが含まれるべきディレクトリに移動してください。grep コマンドを使用して各ファイル内の語句を探したり、file コマンドを使用してファイルタイプを識別できる場合もあります。
どうしても特定できないファイルまたはディレクトリについては、 lost+found ディレクトリからそれらを削除して、不要な領域を解放してください。
lost+found ディレクトリに保存されているファイルの名前を変更して移動します。
次の例は、/dev/rdsk/c0t0d0s6 ファイルシステムをチェックし、不正なブロック数を訂正する方法を示しています。この例では、ファイルシステムがマウント解除されていることを前提としています。
# fsck /dev/rdsk/c0t0d0s6 ** Phase 1 - Check Block and Sizes INCORRECT BLOCK COUNT I=2529 (6 should be 2) CORRECT? y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Cylinder Groups 929 files, 8928 used, 2851 free (75 frags, 347 blocks, 0.6% fragmentation) /dev/rdsk/c0t0d0s6 FILE SYSTEM STATE SET TO OKAY ***** FILE SYSTEM WAS MODIFIED ***** |
fsck -o p コマンド (p は修復用) は、UFS ファイルシステムをチェックし、通常は予期しないシステムのシャットダウンによって発生する問題を自動的に修正します。オペレータの介入が必要な問題が発見されると、このコマンドは即座に終了します。このコマンドによって、ファイルシステムを並列にチェックすることも可能です。
システムがクリーンな状態でシャットダウンしなかった後のファイルシステムの修復にも、fsck -o p コマンドを実行することができます。このモードでは、fsck コマンドはクリーンフラグを調べずに完全チェックを実行します。これらの処理は、fsck コマンドを対話式で実行した場合の処理のサブセットです。
この手順では、ファイルシステムがマウント解除されているか、非アクティブであることを前提としています。
UFS ファイルシステムをマウント解除します。
# umount /mount-point |
修復オプションを指定して UFS ファイルシステムをチェックします。
# fsck -o p /dev/rdsk/device-name |
fsck コマンドの引数として /mount-point または /dev/rdsk/device-name を使用すると、個々のファイルシステムを修復できます。
次の例は、/export/home ファイルシステムの修復方法を示します。
# fsck -o p /export/home |
fsck コマンドを何度か実行しているとき、問題の修正を進めていく過程で、以前の実行で検出されていた問題が再度発生することがあります。このような場合には、問題が報告されなくなるまで fsck コマンドを繰り返し実行して、すべてのエラーを検出および修正する必要があります。fsck コマンドはすべての問題を修正するまで動作を続けるわけではないので、手作業で再実行しなければなりません。
fsck コマンドで表示される情報に注目してください。問題を解決する上で参考になります。たとえば、メッセージは損傷したディレクトリを指している場合があります。そのディレクトリを削除すると、fsck コマンドが問題なく実行されるようになる場合もあります。
それでも fsck コマンドでファイルシステムを修復できない場合は、ff、clri、および ncheck コマンドを使用し、間違いを指定して修正します。これらのコマンドの使用方法については、fsdb(1M)、ff(1M)、clri(1M)、ncheck(1M) の各マニュアルページを参照してください。最終的には、ファイルシステムを作成し直し、その内容をバックアップメディアから復元せざるを得ない場合があります。
ファイルシステム全体を復元する方法については、第 49 章「ファイルとファイルシステムの復元 (手順)」を参照してください。
ファイルシステムを完全に修復できないが、読み取り専用としてマウントできる場合は、cp、tar、または cpio コマンドを使用して、データのすべてまたは一部をファイルシステムから取り出してください。
問題の原因がハードウェア上のディスクエラーであれば、ファイルシステムを作成し直して復元する前に、ディスクをフォーマットし直して再びスライスに分割しなければならない場合があります。ディスクデバイスを交換する前に、デバイスのケーブルおよびコネクタが正常に機能するかどうかをチェックしてください。一般に、ハードウェアエラーが発生すると、さまざまなコマンドで同じエラーが繰り返し表示されます。format コマンドはディスク上の不良ブロックを使用しないようにします。ただし、ディスクの損傷が致命的な場合、フォーマットし直した後も問題が解決されないことがあります。format コマンドの使用方法については、format(1M) のマニュアルページを参照してください。新しいディスクのインストール方法については、第 34 章「SPARC: ディスクの追加 (手順)」または第 35 章「x86: ディスクの追加 (手順)」を参照してください。