このエラーは、ユーザーがインストールされていないパッケージからシステムコールを使用しようとすると発生します。
このエラーの記号名は、ENOPKG、errno=65 です。
このエラーは vxvm のアップグレード後に発生します。この場合、Solaris 2.5.1 ソフトウェア用のドライバ (vxio と vxspec) を持っており、Solaris 2.6 ソフトウェア用のドライバを持っていません。この状況は、ls -l /kernel/drv/*vx* で確認されます。
pkgrm を実行するか、VXVM 2.4 を再インストールしてルートを再カプセル化します。
プログラムがでオペレーティングシステムのバグを引き起こすと、システムはパニックになりクラッシュします。クラッシュはユーザーには不親切であるように感じられるかもしれませんが、突然の停止は実際には、システムとそのデータがそれ以上損傷するのを防止します。
オペレーティングシステムが停止するだけでなく、パニックルーチンでは使用中のメモリの内容がダンプデバイスにコピーされ、パニックルーチンの呼び出し元の CPU の現在の状態に関する重要情報が記録されます。
通常は一次スワップデバイスがデフォルトのダンプデバイスであるため、一次スワップデバイスは、メモリー全体のイメージを収容できるだけの大きさがなければなりません。メモリーイメージが保存されると、システムはリブートしようとします。
システムが正常にリブートしない場合は、次の可能性を検討してください。
メモリー障害やディスククラッシュなどの、致命的なハードウェア障害
不安定なデバイスドライバなどの、カーネル構成の重大障害
MAXUSERS の値が大きすぎるなどの、カーネルチューニングの重大エラー
オペレーティングシステムファイルの損傷を含む、データ損傷
fsck(1M) が照会に対する回答を求めている場合など、手動での作業が必要な場合
システムクラッシュが発生した理由を特定するために、/var/adm/message* ログファイルを調べます。
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) を参照してください。
最初の問題は、次のジャンプスタートエラーによるものです。
2ec00 RPC: Can't decode result. whoami RPC call failed with rpc status: 2 panic - boot: Could not mount filesystem. program terminated ok |
また、他のユーザーにも次の追加メッセージとともに同じエラーメッセージが表示されます。
'Timeout waiting for ARP/RARP packet...' |
第 1 の問題の解決策は次のとおりです。
dfstab(4) (インストールイメージの NFS サーバー上の /etc/dfs/dfstab) の内容を確認します。
share -F nfs -o ro,anon=o /jumpstart-dir |
インストールイメージの NFS サーバー上で share(1M) コマンドを実行し、正しく共用されていることを確認します。
ネットインストールサーバー上で /etc/bootparams ファイルを確認します。誤った起動パスを持っているエントリを探します。
/usr/sbin/rpc.bootparamd がブートサーバー上で実行されていることを確認します。必要に応じて、このプロセスを終了して起動し直します。
ブートサーバー上で /etc/ethers を確認し、重複したり競合したりしているエントリを探します。
プロンプトで、test net /test-net および watch 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 |
jumpstart を行うクライアントマシンに関する情報が含まれていない場合は、これらのファイルを手動で更新しなければならないことがあります。
rm_install_client(1M) でクライアントを削除し、tftpboot の内容を削除してから、クライアントを以下のように追加し直します。
add_install_client -c /jumpstart-dir/profiles 'client name' 'arch' |
マシンは 250 M バイト RAM、FDDI インタフェース、シングル CPU の SS20 です。ミラーリングとストライピング用の Online DiskSuite を実行中です。次に示す推奨カーネルパッチがインストールされています。
102517-03 102436-02 102394-02 102516-06 |
新しい MAXUSERS 値 96 でカーネルを再構築します。このカーネルであればマシンは正しく起動します。
この状態に直接関係のある情報は得られませんでしたが、seg_u に関する別の種類のパニックに関する記述がありました。その場合、MAXUSERS 値の設定が大きすぎて、テーブルスペースに対してカーネルがオーバーランしたことがわかりました。また、MAXUSERS の値はアーキテクチャと OS のバージョンによって異なり、システムの物理的な RAM 容量に反比例するという直接関係があります。さらに調べたところ、MAXUSERS の値が 128 に設定されていたことがわかりました。関連情報によれば、パニックの原因は、tmpptes の値を超えてメモリスペースを定義しようとした valloc にあるようです。
おそらく sync(2) または write(2) の途中でシステムがクラッシュし、フェーズ 1 で、fsck(1M) により指定した i ノードが割り当てられていず、割り当て解除もされていないことがわかりました。
ディレクトリエントリがこの i ノードを参照していて、この質問に「yes」と回答すると、フェーズ 2 で UNALLOCATED メッセージが表示されます。fsck(1M) を慎重に終了し、ncheck(1M) を実行し、-i オプションの後に i ノード番号を指定して関係のあるファイルやディレクトリを特定してください。このファイルやディレクトリは別のシステムから復元することもできます。後のフェーズでは、fsck(1M) によりこのファイルが lost+found ディレクトリにコピーされることもあります。
詳細については、『Solaris のシステム管理 (第 1 巻)』のファイルシステムの完全性チェックに関する章を参照してください。
次の 2 行を /etc/nsswitch.conf に入れます。
passwd: compat passwd_compat: nis |
server1% passwd passwd: Changing password for khh server1% |
passwd はパスワードの入力前に終了します。
passwd のマニュアルページには、次の記述があります。
上記の条件がすべて満たされた場合、デフォルトでは passwd コマンドは /etc/nsswitch.conf を参照してパスワード更新を実行すべきレポジトリ (記録場所) を決めます。具体的には、passwd(4) と passwd_compat の両エントリを検索します。これらのエントリに対応したリソースつまりレポジトリが更新されます。なお、使用可能なパスワード更新定義形式は、以下の 5 つに限定されています。いずれも形式にも合っていない場合、passwd(1) が異常終了するので、システムにログインできません。
passwd: files passwd: files nis passwd: files nisplus passwd: compat (==> files nis) passwd: compat (==> files nisplus) passwd_compat: nisplus |
passwd(1) のマニュアルページには、passwd_compat: nis の行を使用できるとは書いてありません。passwd(1) はマニュアルページの説明どおりの動作を行います。
Solaris 2.6 リリースで、ユーザーアカウントをロックし、nispasswd に -l オプションを指定して実行すると、「passwd (SYSTEM): System error: repository out of range」のエラーになります。
代わりに passwd -r nisplus -l username を使用してください。
これは、NIS+ クライアントがネットワーク上で NIS+ サーバーを発見できない場合に出力する 3 つのメッセージの内の 1 番目のメッセージです。
詳細は、「hosts.org_dir: NIS+ servers unreachable」を参照してください。
このメッセージは、ログイン時に、ユーザーのパスワードがそのユーザーの keylogin(1) ネットワークパスワードと一致しなかった場合に表示されます。システムで NIS+ が実行されている場合、ログインプログラムは、secure RPC 認証のために、まず UNIX 認証を行なってから keylogin(1) を実行しようとします。
secure RPC の資格を得るには、ユーザーは (ログイン後に) keylogin(1) を実行し、自分の秘密鍵を入力します。ログイン時にこのメッセージを表示しないようにするには、chkey -p コマンドを実行して、NIS+ パスワードと同じになるようにネットワークパスワードを設定します。ユーザーがネットワークパスワードを忘れた場合、システム管理者は、ユーザーの資格テーブルのエントリを削除して作り直し、ユーザーが chkey(1) を使用して新しいネットワークパスワードを設定できるようにしてください。
NIS (YP) を実行している SunOS システムで、yppasswdd(1M) を実行すると、システムからこのエラーが報告されます。NIS Master サーバーでは、エラー「password file busy - try again」は、rpc.yppasswdd のメッセージファイル内にあります。このエラーは表面的には、ロックファイル /var/yp/passwd.ptmp があるために発生します。このファイルを削除すると、yppasswdd が最後まで実行されますが、それでも、その後の呼び出しでは、同じエラーメッセージが表示されて失敗します。根本的な原因は yppasswdd に -m オプションがあることで、make を実行してマップをスレーブサーバーにプッシュアウトするよう要求します。その場合、マップをスレーブサーバーにプッシュするときに問題が発生し、プッシュがハングします。したがって、プッシュが終了せず、ロックファイルは削除されません。これは、次のように操作して確認できます。
#cd /var/yp #make passwd passwd is up to date #touch passwd #make passwd |
この根本的な原因を修復するには、マップがなぜプッシュされないかをつきとめます。この例では、経路指定が問題になっていますが、他にも解決方法があるかもしれません。
ディスクグループを作成しましたが、共用にするのを忘れていました。共用ディスクグループに設定後、2 番目のノード (再起動されていない) を開始しようとしました。2 番目の pdb ノードの pdbadmin 開始ノードが失敗し、タイムアウトになるまで繰り返しこのメッセージが表示されます。
return from cluster_establish is join not allowed now retrying cluster_establish |
2 番目のノードを再起動するか、vxdctl enable を実行します。
pdbadmin 開始ノードが動作します。
保護システムによって禁止されている方法でファイルにアクセスしようとしました。
(ls -l コマンドによって表示される長いリストを参照して) ファイルの所有権と保護モードを調べ、誰がファイルへのアクセスが許されているかを確認します。次に、必要に応じてファイルまたはディレクトリへのアクセス権を変更してください。
このエラーの記号名は、EACCES、errno=13 です。
このメッセージは、mailtool(1) の使用時に To: フィールドにアドレスを入力せずにメッセージを配信しようとすると、ダイアログボックスに表示されます。
詳細は、「Recipient names must be specified」を参照してください。
プロトコルエラーが発生しました。このエラーはデバイス特有ですが、通常、ハードウェア障害には関係ありません。
このエラーの記号名は、EPROTO、errno=71 です。
SunOS システムをインストールしたマシンで rlogin(1) が失敗しました。
接続を行うマシン上の in.rlogind のアクセス権を確認します。アクセス権は、次のようになっています。
-rwxr-xr-x 1 root staff 16384 Jan 20 1994 /usr/sbin/in.rlogind |
/etc/inetd.conf ファイルでログイン行を確認します。次のようになっています。
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind |
/etc/passwd を調べて、ログイン ID のエントリに無効なログインシェルが設定されていないかを確認します。
インターネットプロトコル群として使用するプロトコルファミリがシステムに設定も実装もされていません。
このエラーの記号名は、EPFNOSUPPORT、errno=123 です。
要求されたネットワークプロトコルがシステム内に構成されていないか、またはこのプロトコルの実装が存在しません (プロトコルとは、交換されるメッセージと、システムが情報を交換する際に従うべきルールの形式を記述したものです)。
プロトコルが /etc/inet/protocols ファイルと (使用している場合は) NIS プロトコルマップに存在することを確認します。プロトコルが存在しないが使用できるようにしたい場合は、記述に従ってまたは必要に応じてプロトコルを構成します。
このエラーの記号名は、EPROTONOSUPPORT、errno=120 です。
このメッセージは、アプリケーションのプログラミングエラーまたは不正に構成されているプロトコルを示します。
/etc/protocols ファイルが NIS protocols(4) マップと数ごとに一致していることを確認します。両者が一致している場合は、アプリケーションのベンダまたは作成者に更新してもらうよう要請してください。
要求されたソケットタイプの意味論をサポートしていないプロトコルが指定されました。結果的に、プロトコルはサポートされていないソケットタイプを要求することになります。このソケットを要求したソースコードを調べて、要求しているタイプが /usr/include/sys/socket.h で指定されたタイプに含まれていることを確認します。
このエラーの記号名は、EPROTOTYPE、errno=98 です。