主要メッセージの手引き

"B"

Bad address

原因

システムが、プログラミング関数のパラメータへのアクセス時にハードウェア障害を検出しました。

対処方法

この不良アドレスが、誤ったデバイスまたはオプションをコマンドに提供した結果であるかどうかを調べます。それが原因でなかった場合は、プログラムのベンダまたは作成者に変更を依頼します。

テクニカルノート

このエラーは、ポインタ引数を取る関数に無効なアドレスを渡すと発生することがあります。不良アドレスの検出能力はプロセッサによって異なるため、アーキテクチャによっては、不良アドレスを渡すと未定義の動作が発生する場合があります。

このエラーの記号名は、EFAULTerrno=14 です。

BAD/DUP FILE I=i OWNER=o MODE=m SIZE=s MTIME=t CLEAR?

原因

フェーズ 4 での i ノードリンクカウントのチェック中に、fsck(1M) が、存在しないかまたは別の場所に存在するファイル (またはディレクトリ) を発見しました。

対処方法

このファイルまたはディレクトリに対する i ノードの参照をクリアするために、「YES」と答えます。-p (preen) オプションを付けると、不良または重複したファイル参照を fsck(1M) が自動的にクリアするため、この質問に「YES」と答えても通常は問題ありません。

Bad file number

原因

一般的に、このメッセージはプログラミングエラーであり、使用方法のエラーではありません。

対処方法

プログラムのベンダまたは作成者に変更を依頼します。

テクニカルノート

ファイル記述子がオープンファイル以外を参照しているか、または書き込み (または読み取り) 専用に開かれたファイルに対して read(2) - または write(2) - 要求が実行されました。

このエラーの記号名は、EBADFerrno=9 です。

block no. BAD I=inode no.

原因

範囲外のブロックを検出すると、fsck(1M) は、不良ブロック番号とそれに含まれる i ノード (I= の後) を表示します。

対処方法

fsck のフェーズ 2 とフェーズ 4 で、これらの不良ブロックをクリアするかどうかを判断します。fsck(1M) による修復を確定する前に、次のように ncheck(1M) コマンドに i ノード番号を渡すと、この i ノードが含まれるファイルを特定できます。


# ncheck -i inum filesystem

関連項目

詳細については、『Solaris のシステム管理 (第 1 巻)』のファイルシステムの整合性チェックに関する章を参照してください。

BAD_MESSAGE (error code 100) from X.400

原因

この場合、X.400 ソフトウェアは問題なく動作していました。メッセージによる通信が ma_start_delivery() で、突然エラーになりました。

900 バイトを超えるファイルを交換しようとすると、ma_start_delivery() コールは失敗します。

対処方法

X.400 は誤った umask の指定で再起動しています。umask を 0022 に設定してソフトウェアを再起動すると、問題は解決します。

bad module/chip at: position

原因

メモリー管理システムからのこのメッセージは、パリティエラー時に表示されることが多く、表示された位置のメモリーモジュールまたはチップに不良があることを示します。ブート時以外にこの障害が発生すると、データが失われる恐れがあります。

対処方法

表示された位置のメモリーモジュールまたはチップを交換します。この位置の判断については、ハードウェアのマニュアルを参照してください。

Bad request descriptor

原因

このメッセージは NIS+ でだけ表示され、テーブルが破壊されているか、または欠落していることを示します。

テクニカルノート

このエラーの記号名は、EBADRerrno=51 です。

BAD SUPER BLOCK: string

原因

fsck(1M) からのこのメッセージは、ファイルシステムのスーパーブロックが修復不可能なほど損傷しており、交換しなければならないことを示します。(-p オプションによる) ブート時、このメッセージはファイルシステムのデバイス名の前に表示されます。このメッセージが表示された場合、実際の損傷が認識されています (下記の対処方法を参照してください)。fsck(1M) は損傷したスーパーブロックの番号は表示しません。

対処方法

このエラーの原因として最も多いのは、ディスクパーティションのオーバーラップです。エラーメッセージの後に表示された行の通りにすぐに fsck(1M) を再実行しないでください。まず、ファイルシステムの最新のバックアップがあることを確認します。バックアップがない場合は、ufsdump(1M) を使用してすぐにファイルシステムのバックアップを取ります。次に、format(1M) コマンドを実行し、該当するディスクを選択してパーティション情報を出力します。


# format
: N
> partition
> print
ファイルシステムの先頭または末尾のどちらでオーバーラップが発生しているかを判断します。次に、-N オプションを付けて newfs(1M) を実行して、バックアップスーパーブロックの場所を含むファイルシステムパラメータを出力します。

# newfs -N /dev/dsk/device
オーバーラップしていないディスク領域からスーパーブロックを選択します。ただし、通常、適切な置換スーパーブロックを選択する機会は一度しかありません。このスーパーブロックは fsck(1M) によってすぐにすべてのシリンダに伝達されます。不適切な置換スーパーブロックを選択するとデータが損傷する可能性が高く、その場合はバックアップテープから復元しなければなりません。新しいスーパーブロックを選択したら、その新しいマスタスーパーブロック番号を fsck(1M) に与えます。


# fsck -o b=NNNN /dev/dsk/device

テクニカルノート

スーパーブロックの損傷原因には、次のものがあります。マジックナンバーが間違っている、シリンダグループの数 (NCG) またはグループあたりのシリンダ数 (CPG) が範囲外である、シリンダ数が間違っている、スーパーブロックのサイズが大きすぎる、スーパーブロック内の値が消されているなどです。通常、損傷したスーパーブロックは極度に破壊されているため、これらの原因が判明しても役に立つ可能性は低いです。

関連項目

不良スーパーブロックの詳細については、『Solaris のシステム管理 (第 1 巻)』の不良スーパーブロックの復元に関する節を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、superblock と入力して検索文字列として使用します。

BAD TRAP

原因

不良トラップは、ハードウェアの障害、またはハードウェアと構成情報間の不一致を示している可能性があります。ブート時以外にこの障害が発生すると、データが失われる恐れがあります。

対処方法

最近、新しいハードウェアをインストールした場合は、ソフトウェアの設定が正しいかどうかを確認します。コンソールに表示されるカーネルのトレースバックを調べて、トラップを生成したデバイスを特定します。構成ファイルが正しい場合は、デバイスを交換する必要がある場合があります。

不良トラップメッセージは、rev CPU の不良または停止を示している場合もあります。

テクニカルノート

ハードウェアプロセッサトラップが発生し、カーネルのトラップハンドラがシステムの状態を回復できません。このメッセージは、通常、パニックの前に出る重大なエラーです。システムは同期、ダンプ、リブートを実行します。不良トラップの原因になりうる状態は次のとおりです。システムテキストまたはデータのアクセス障害、システムデータ整合エラー、またはある種のユーザーソフトウェアトラップ。

/bin/sh: file: too big

原因

この Bourne シェルメッセージは、「メモリーなし」エラーを示します。最初のコロンの後に指定されたプログラムの読み込み中に、システムが仮想記憶 (スワップ空間) を使い果たしたことをシェルが検出しました。

対処方法

システムを再構成してスワップ空間を追加する方法については、「Not enough space」を参照してください。

Block device required

原因

mount(1M) コマンドの呼び出し時など、ブロック型デバイスが必要な場所で raw (文字型特殊) デバイスが指定されました。

対処方法

使用可能なブロック型デバイスを確認するには、ls -l を使用して /devices を調べます。次に、文字型デバイスの代わりにブロック型デバイスを指定します。ブロック型デバイスモードは b で始まり、raw 文字型デバイスモードは c で始まります。

テクニカルノート

このエラーの記号名は、ENOTBLKerrno=15 です。

Boot device: /iommu/sbus/directory/directory/sd@3,0

原因

このメッセージは、常にリブートの初めに表示されます。障害があると、システムはハングし、他のメッセージは表示されません。このような状態になるのは、ブートデバイス用の SCSI ターゲットが重複しているためであり、ほぼ常にターゲット 3 です。

対処方法

ブートデバイスは、通常、マシンの内部ディスクドライブであるターゲット 3 です。外部および二次ディスクドライブがターゲット 1、2、または 0 になっており、相互に重複していないことを確認します。また、テープドライブがターゲット 4 または 5、CD ドライブが 6 になっており、相互にまたはディスクドライブと重複していないことも確認します。デバイスのターゲット番号は、SCSI ケーブルの近くにある背面の押しボタンスイッチまたはダイアルを使用して設定できます。内部ディスクドライブのターゲットを調べたい場合は、マシンの電源を切り、すべての外部デバイスを外してから電源を入れ、PROM モニタから probe-scsi-all または probe-scsi コマンドを実行します。

Broadcast Message from root (pts/int) on server [date]

原因

wall(1M) コマンドからのこのメッセージは、システムにログインしたすべてのユーザーに対して送信されます。このメッセージは、rlogin(1) または telnet(1) セッション中、またはタイムシェアリングシステムに接続された端末上で表示されます。

対処方法

このブロードキャストメッセージを注意して読んでください。後にシャットダウンの警告が続いている場合があります。

システムのシャットダウンの詳細は、「The system will be shut down in int minutes」を参照してください。

関連項目

システムの停止については、『Solaris のシステム管理 (第 1 巻)』のシステムの停止に関する節を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、「halting the system」と入力して検索文字列として使用します。

Broken pipe

原因

多くの場合、(head(1) プログラムに多数の行をパイプした場合などのように) この状態は正常であり、メッセージは単に情報を表示しているだけです。パイプ上の書き込みが読み取りプロセスを発見できない場合は、この状態が発生します。その場合は、通常、実行中のプログラムに対する信号が生成されますが、プログラムが信号を無視すると、このメッセージが表示されます。

対処方法

パイプの最後でプロセスを調べ、終了した理由を判断します。

テクニカルノート

このエラーの記号名は、EPIPEerrno=32 です。

Bus Error

原因

制限されているかまたは存在しないデバイスに入出力しようとしたことを示す信号をプロセスが受け取りました。読み取り専用ファイルシステムを除き、通常、このメッセージはコアダンプを伴います。

対処方法

デバッガを使用してコアファイルを調べ、バスエラーを引き起こしたプログラム障害またはシステム障害を判断します。できれば、バスエラーの前にデータ損傷が発生していないかどうか、プログラムの出力ファイルを調べてください。

テクニカルノート

バスエラーは、プログラミングエラー、またはシステム上のデバイス損傷によって発生することがあります。バスエラーの原因として多いのは、ファイル記述子が無効、入出力要求が不当、メモリー割り当てが不良、データ構造が不整合、コンパイラにバグがある、ブートブロックが損傷しているなどです。