"P"

Package not installed

原因

このエラーは、ユーザーがインストールされていないパッケージからシステムコールを使用すると発生します。

テクニカルノート

このエラーのシンボルの名前は、ENOPKG、errno=65 です。

panic -boot: Could not mount filesystem

原因

第 1 の問題は、jumpstart が次のエラーを出したことです。

2ec00 RPC: Can't decode result.
whoami RPC call failed with rpc status: 2
panic - boot: Could not mount filesystem.
program terminated
ok

第 2 の問題は、他のユーザーが、同じエラーメッセージを次の追加メッセージと共に受け取ったことです。

'Timeout waiting for ARP/RARP packet...'

対処方法

第 1 の問題の解決策は次のとおりです。

1. dfstab(4) (インストールイメージの NFS サーバ上の /etc/dfs/dfstab) の内容を確認します。

share -F nfs -o ro,anon=o /jumpstart-dir

2. インストールイメージの NFS サーバ上で share(1M) コマンドを実行し、正しく共有されていることを確認します。

3. ネットインストールサーバ上で /etc/bootparams ファイルを確認します。誤った起動パスを持っているエントリを探します。

4. /usr/sbin/rpc.bootparamd がブートサーバ上で実行されていることを確認します。必要に応じて、このプロセスを終了して起動し直します。

5. ブートサーバ上で /etc/ethers を確認し、重複したり競合したりしているエントリを探します。

6. ok プロンプトで、テストネット /test-net およびウォッチネット /watch-net を実行して、ネットワークの接続性をテストします。

第 2 の問題の回避策として、nsswitch.conf(4) ファイルを確認します。次のような NIS を指しているエントリがある場合があります。

rpc		nis	files
hosts		nis	files
ethers		nis	files
bootparams	files   nis

rpc		files 	nis
hosts		files 	nis
ethers		files	nis
bootparams	files	nis

rm_install_client(1M) でクライアントを削除し、tftpboot の内容を削除してから、クライアントを以下のように追加し直します。

add_install_client -c /jumpstart-dir/profiles  'client name'  'arch'

panic: mutex_adaptive_exit

原因

CD-ROM からブートすると、「panic: mutex_adaptive_exit」のエラーが発生します。

Panic

原因

プログラムがでオペレーティングシステムのバグを引き起こすと、システムはパニックになりクラッシュします。クラッシュはユーザーには不親切であるように感じられるかもしれませんが、突然の停止は実際には、システムとそのデータがそれ以上損傷するのを防止します。

オペレーティングシステムが停止するのに伴い、パニックルーチンは、使用中のメモリーの内容をダンプデバイスにコピーすることによって、パニックルーチンの呼び出し元である CPU の現在の状態に関する重要情報を記録します。

通常は一次スワップデバイスがデフォルトのダンプデバイスであるため、一次スワップデバイスは、メモリー全体のイメージを収容できるだけの大きさがなければなりません。メモリーイメージが保存されると、システムはリブートしようとします。

システムが正常にリブートしない場合は、次の可能性を検討してください。

1. メモリー障害やディスククラッシュなどの、致命的なハードウェア障害

2. デバイスドライバのバグなどの、カーネル構成の重大障害

3. maxusers の値が大きすぎるなどの、カーネルチューニングの重大エラー

4. オペレーティングシステムファイルの損傷を含む、データ損傷

5. fsck(1M) が自らの照会に対する回答を求めている場合など、人間の介入が必要な場合

対処方法

システムクラッシュが発生した理由を特定するために、次のいずれかの操作を実行できます。

1. /var/adm/message* ログファイルを調べます。

2. クラッシュ時にコンソールに表示された情報を紙に記録します (クラッシュ時にコンソールの前に座っていた場合)。

3. savecore(1M) プログラムを使用します。

上記の方法の中では、savecore(1M) プログラムを使用すると最も多くの情報を得られます。savecore(1M) コマンドは、パニックルーチンによって生成されたシステムクラッシュのダンプイメージを、ダンプデバイスからファイルシステムに転送します。このイメージを adb(1) などのデバッガを使用して分析できます。

関連項目

savecore(1M) を正しく設定し結果を解釈するのは、場合によっては難しい作業です。システムパニックのデバッグについて詳細は、Chris Drake と Kimberley Brown 著『Panic! UNIX Sytem Crash Dump Analysis』(ISBN: 0-13-149386-8) を参照してください。

PARTIALLY ALLOCATED INODE I=int CLEAR?

原因

フェーズ 1 の間に、fsck(1M) が、指定された i ノード が割り当てられている状態と割り当てられていない状態のいずれでもないことを発見しました。sync(2) または write(2) 操作の途中でシステムがクラッシュした可能性があります。

対処方法

この質問に YES と答えた場合、この i ノードを指しているディレクトリエントリがあると、フェーズ 2 の間に「UNALLOCATED」メッセージが表示されることがあります。このメッセージが表示された場合は、fsck(1M) を終了して、(-i オプションの後に i ノード番号を指定して) ncheck(1M) を実行し、該当するファイルまたはディレクトリを特定します。別のシステムからこのファイルまたはディレクトリを復元できる場合もあります。また、後のフェーズで fsck がこのファイルを lost+found ディレクトリにコピーすることもできます。

関連項目

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

passwd: Changing password for string

原因

次の 2 行を /etc/nsswitch.conf に入れます。

 passwd:     compat
 passwd_compat:     nis  

server1% passwd
passwd:  Changing password for khh
server1%

対処方法

passwd のマニュアルページには、次の記述があります。

すべての条件が満たされると、passwd コマンドは /etc/nsswitch.conf を参考にして、パスワードの更新を行うレポジトリをデフォルトで決定します。passwd コマンドは、passwd(4) および passwd_compat のエントリを検索します。これらのエントリに関連するソース (レポジトリ) が更新されます。しかし、サポートされているパスワード更新の設定は、次の 5 つの場合に限られています。設定に従わない場合、ユーザーはシステムにログオンすることができなくなります。

   o passwd: files
   o passwd: files nis
   o passwd: files nisplus
   o passwd: compat (==> files nis)
   o passwd: compat (==> files nisplus)
      passwd_compat: nisplus

注: ここには、passwd_compat: nis の行が使用できるという記述はありません。しかし、マニュアルページの記述に従って正確に使用すると、passwd(1) は機能します。

passwd.org_dir: NIS+ servers unreachable

原因

これは、NIS+ クライアントがネットワーク上で NIS+ サーバを発見できない場合に出力する 3 つのメッセージの内の 1 番目のメッセージです。

対処方法

詳細については、「hosts.org_dir: NIS+ servers unreachable」メッセージを参照してください。

Password does not decrypt secret key for unix.uid@string

原因

このメッセージは、ログイン時に、ユーザーのパスワードがそのユーザーの keylogin(1) ネットワークパスワードと一致しなかった場合に表示されます。システムで NIS+ が実行されている場合、ログインプログラムは、secure RPC 認証のために、まず UNIX 認証を行なってから keylogin(1) を実行しようとします。

対処方法

secure RPC の資格を得るには、ユーザーは (ログイン後に) keylogin(1) を実行し、自分の秘密鍵を入力します。ログイン時にこのメッセージを表示しないようにするには、chkey -p コマンドを実行して、NIS+ パスワードと同じになるようにネットワークパスワードを設定します。ユーザーがネットワークパスワードを忘れた場合、システム管理者は、ユーザーの資格テーブルのエントリを削除して作り直し、ユーザーが chkey(1) を使用して新しいネットワークパスワードを設定できるようにしてください。

Permission denied

原因

保護システムによって禁止されている方法でファイルにアクセスしようとしました。

対処方法

(ls -l コマンドによって表示される長いリストを参照して) ファイルの所有権と保護モードを調べ、誰がファイルへのアクセスが許されているかを確認します。次に、必要に応じてファイルまたはディレクトリへのアクセス権を変更してください。

テクニカルノート

このエラーのシンボルの名前は、EACCES、errno=13 です。

Please specify a recipient.

原因

このメッセージは、mailtool(1) の使用時に、To: フィールドにアドレスを入力せずにメッセージを配信しようとすると、ダイアログボックスに表示されます。

対処方法

詳細については、「Recipient names must be specified」メッセージを参照してください。

Protocol error

原因

何らかのプロトコルエラーが発生しました。このエラーはデバイス特有ですが、通常、ハードウェア障害には関係ありません。

テクニカルノート

このエラーのシンボルの名前は、EPROTO、errno=71 です。

protocol error, string closed connection

原因

SunOS マシン上で rlogin(1) が失敗します。

対処方法

1. 接続を行うマシン上の in.rlogind のアクセス権を確認します。アクセス権は、次のようになっています。

-rwxr-xr-x  1 root     staff       16384 Jan 20  1994 /usr/etc/in.rlogind

2. /etc/inetd.conf ファイルでログイン行を確認します。次のようになっています。

login	stream	tcp	nowait	root	/usr/etc/in.rlogind	in.rlogind

3. /etc/passwd を調べて、ログイン ID のエントリに無効なログインシェルが設定されていないかを確認します。

Protocol family not supported

原因

インターネットプロトコル群として使用するプロトコルファミリがシステムに設定も実装もされていません。

テクニカルノート

このエラーのシンボルの名前は、EPFNOSUPPORT、errno=123 です。

Protocol not supported

原因

要求されたネットワークプロトコルがシステム内に構成されていないか、またはこのプロトコルの実装が存在しません (プロトコルとは、交換されるメッセージと、システムが情報を交換する際に従うべきルールの形式を記述したものです)。

対処方法

プロトコルが /etc/inet/protocols ファイルと (使用している場合は) NIS プロトコルマップに存在することを確認します。プロトコルが存在しないが使用できるようにしたい場合は、記述に従ってまたは必要に応じてプロトコルを構成します。

テクニカルノート

このエラーのシンボルの名前は、EPROTONOSUPPORT、errno=120 です。

Protocol wrong type for socket

原因

このメッセージは、アプリケーションのプログラミングエラーまたは不正に構成されているプロトコルを示します。

対処方法

/etc/protocols ファイルが NIS protocols(4) マップと数値ごとに一致していることを確認します。両者が一致している場合は、アプリケーションのベンダまたは作成者にアップデートについて問い合わせてください。

テクニカルノート

要求されたソケットタイプの意味論をサポートしていないプロトコルが指定されました。結果的に、サポートされていないソケットタイプを要求することになります。このソケットを要求したソースコードを調べて、要求しているタイプが /usr/include/sys/socket.h で指定されたタイプに含まれていることを確認します。

このエラーのシンボルの名前は、EPROTOTYPE、errno=98 です。