デフォルトのテープデバイス /dev/rmt/0、または TAPE 環境変数で指定されているデバイスが、現在、システムに接続されていないか、設定されていないか、またはそのハードウェアのシンボリックリンクが壊れています。
/dev/rmt ディレクトリ内のファイルを一覧表示して、現在設定されているテープデバイスを調べます。設定されているデバイスがない場合は、テープデバイスがシステムに正しく装着されていることを確認してから、-r オプションを付けてリブートし、デバイスを設定し直します。
/dev/rmt/0 以外のテープデバイスが設定されている場合は、tar(1) の -f オプションの後に指定できます。
tar(1) からのこのエラーメッセージは、テープから読み込んだディレクトリとファイルのチェックサムが、ヘッダブロックに宣言されているチェックサムと一致しないことを示します。通常、このメッセージは、ブロック化因数が間違っていることを示します。ただし、テープ上のデータが損傷していることを示す場合もあります。
この問題を解決するには、コマンド行で (-b の後に) 指定したブロック化因数が、初めに指定したブロック化因数と一致することを確認します。疑わしい場合は、ブロックサイズを省略して、tar(1) に自動的に決めさせます。これでも解決しない場合は、テープのデータが損傷している可能性があります。
tar(1) の出力ファイルで物理的な書き込みエラーが発生しました。出力ファイルは、通常はテープですが、フロッピーディスクまたはディスクファイルの場合もあります。システムコンソールで、デバイスドライバが実際のエラー状態を表示しているか見てください。テープが書き込み禁止になっているか、物理的な入出力エラーが発生したか、テープの終わりに達したか、またはファイルの大きさ制限を超えたかのいずれかが原因の可能性があります。
テープが書き込み禁止になっている場合は、書き込みスイッチを有効にします。物理的な入出力エラーの場合は、新しいテープに交換します。テープの終わりに達した場合は、そのデバイスがサポートしている場合は高密度テープを使用するか、マルチボリュームをサポートしている cpio(1) または pax(1) を使用します。ファイルの大きさ制限を超えた場合は、親シェルの limit(1) または ulimit(1) 機能を使用して、ファイルの最大サイズを大きくします。
tar テープの詳細については、『Solaris のシステム管理 (第 1 巻)』の UFS ファイルのコピーに関する節を参照してください。
このエラーは、書き込みのために現在開いている手続きのみの (共用テキスト) ファイルを実行しようとした場合や、実行中の手続きのみのファイルを書き込みのために開こうとしたり、削除しようとしたりする場合に発生します。このメッセージは現在は使用されていません。
このエラーの記号名は、ETXTBSY、errno=26 です。
このメッセージは、cmdtool(1) のスクロールウィンドウで 100,000 文字がスクロールされるとセッションの先頭部分で表示されます。スクロールバーの最上部にある矩形をクリックすると、このメッセージが表示されることがあります。データは失われていませんが、ユーザーは、この位置よりも前にスクロールできません。
コマンドツールのログファイルの最大サイズを大きくするには、cmdtool に -M オプションを付けて使用し、100,000 バイトよりも大きな値を指定します。
AutoClient (AutoClient 2.1 - Solstice AdminSuite 2.3) を構成後、特に Solaris 2.6 環境では、/dev/console と /var/adm/messages の両方またはどちらかからサーバーに次のようなエラーメッセージが表示されることがあります。
tftpd: nak: Transport endpoint is already connected |
その後の AutoClient による起動ネットはハングします。次に例を示します。
Boot Device:... File and Args... |
このエラーメッセージは解読困難です。また、このように AutoClient の起動の初期には、イベントの記録もほとんどありません。この問題の原因を確かめるには、クライアントのサブネットの別のシステムからのクライアントの snoop の実行が必要です。
Solaris 2.6 で in.tftpd に変更が加えられ、send() ではなく sendto() を使用するようになりました。Solaris 2.5.1 環境では、sendto() のかわりに send() を使用するので、Solaris 2.5.1 から Solaris 2.6 環境に in.tftpd をコピーするのも 1 つの方法です。さらに、クライアントの snoop を実行することで、受信しようとして見つからなかったファイルをサーバーから障害追跡する方法もあります。
次に例を示します (オンボード Ethernet インタフェースの使用を想定)。
# snoop autoclient_name |
# snoop ethernet_address_of_autoclient_name |
81911ED4.SUN4C TFTP Error: access violation |
このエラーは、/tftpboot ディレクトリに何らかの問題があることを示しています。
AUTOCLIENT の場合: 問題は、起動サーバーの /tftpboot ディレクトリにあります。HOSTID ファイルと HOSTID.ARCH ファイルが、現在のアーキテクチャの正しい inetboot ファイルにリンクされていることを確認してください。次に、sun4m システムの場合の正しいエントリを示します。
81971904 -> inetboot.sun4m.Solaris_2.4 81971904.SUN4M -> inetboot.sun4m.Solaris_2.4 |
次のエントリは、sun4m システムでは正しくありません。
C753002F -> inetboot.axil4m.Solaris_2.5.1 C753002F.AXIL4M -> inetboot.axil4m.Solaris_2.5.1 |
間違っている場合は、現在のディレクトリで対応するクライアントのエントリを削除し、add_install_client スクリプトまたは Solstice ツールで再度そのクライアントを追加してください。
JUMPSTART クライアントの場合: サーバーからクライアントに対する「Error: access violation」は、add_install_client コマンド行で間違ったカーネルアーキテクチャが指定されたことを表している場合があります。サーバーで、次のコマンドを実行します。
# cd /cdrom/cdrom0/s0 # ./add_install_client host_name correct_architecture |
間違ったアーキテクチャは add_install_client スクリプトによって削除され、インストールサーバーは、クライアントを起動するための正しいアーキテクチャでセットアップされます。add_install_client の使用に問題がある場合は、./rm_install_client および ./add_install_client を正しいアーキテクチャで使用してください。
他はすべて /tftpboot ディレクトリのチェックと同じ手順を使用してください。
ブート時、/etc/rcS スクリプトは fsck(1M) コマンドを実行して、/etc/vfstab の fsck がマークされたファイルシステムの整合性をチェックします。fsck(1M) がファイルシステムを自動的に修復できなかった場合、ブート手続きは中断され、このメッセージを表示します。この状態では、fsck(1M) の修復作業はファイルの損失を伴うため、システム管理者に判断を仰ぎます。すでにデータが損傷している恐れがあります。
まずファイルシステムで fsck -n を実行し、障害の数と種類を調べます。その後、再度 fsck(1M) を実行してファイルシステムを修復します。ファイルシステムのバックアップがある場合は、通常、fsck(1M) からの質問にすべて「y」と答えても問題はありません。後で参照できるように、問題のあるファイルと i ノード番号をすべて記録しておくことを推奨します。fsck(1M) を自分で実行する場合は、ブートスクリプトが推奨するオプションを指定します。たとえば、次のように入力します。
# fsck /dev/rdsk/c0t4d0s0 |
バックアップがない場合は、fsck(1M) の実行を詳しい方に依頼してください。
詳細については、『Solaris のシステム管理 (第 1 巻)』のファイルシステムの整合性チェックに関する節を参照してください。
このメッセージは、リブートの初めの方で「Boot device: ...」メッセージの後に表示され、その後システムはハングします。問題は、非ブートデバイスの SCSI ターゲットが重複していることです。外部デバイスの電源を切っておくと、この障害が発生しにくくなります。
解決方法については、「Boot device: /iommu/sbus/directory/directory/sd@3,0」を参照してください。
詳細については、『Solaris のシステム管理 (第 1 巻)』の停止とブートに関する節を参照してください。
このメッセージは、システムが停止直前であり、変更内容を保存できないことを意味しています。
多くの場合、このメッセージの前に、システムが 15 分や 10 分で停止するといった意味のメッセージが表示されます。これらの初期ブロードキャストシャットダウンメッセージが表示された場合は、すべての作業内容を保存し、作成中の電子メールを送信し、ファイルを閉じてください。vi(1) セッションは後で復元できるように自動的に保存されますが、他の多くのアプリケーションにはクラッシュ保護機構がありません。データが失われる恐れがあります。
システムのシャットダウンについては、『Solaris のシステム管理 (第 1 巻)』を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、「halting the system」と入力して検索文字列として使用します。
システムの shutdown(1M) スクリプトからのこのメッセージは、スーパーユーザーがシステムを停止しようとしていることを示します。
即座にすべての変更内容を保存しないと、作業結果が失われます。変更中のファイルを書き出し、作成中の電子メールメッセージを送信し、ファイルを閉じてください。
システムのシャットダウンについては、『Solaris のシステム管理 (第 1 巻)』を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、「halting the system」と入力して検索文字列として使用します。
FireWall バージョン 2.0 を使用中に、次のようなエラーが発生します。
# telnet firewall-machine Trying 192.29.174.60 ... Connected to firewall-machine Escape character is '^]'. CheckPoint FireWall-1 authenticated Telnet server running on firewall-machine Login: testuser This gateway does not support Unix Password. |
「Network Objects」を開き、該当する Gateway オブジェクト、「Host Properties Auth Schemes」を編集し、UNIX Password を選択します。UNIX Password は、認証の方法としては安全でないと考えられているため、デフォルトのチェックはありません。
このメッセージは、別のメールリーダが受信箱をロックしているときに mailtool(1) を起動すると、ポップアップダイアログボックスに表示されます。次に、「Do you wish to ask that mail reader to save the changes?」という質問が表示されます。この質問には、次の対処方法に示す 3 つの選択肢があります。
「変更内容を保存 (Save Changes)」を選択すると、mailtool(1) はもう一方のメールリーダに、ロックを解除して受信箱に加えた変更内容を書き出すように要求します。「変更内容を廃棄 (Ignore)」を選択すると、mailtool(1) は受信箱をロックせずに読み取ります。「取り消し (Cancel)」を選択すると、mailtool(1) は終了します。
この障害はネットワークからのブート時に発生し、ネットワークの接続障害を示します。
Ethernet ケーブルがネットワークに接続されていることを確認します。次に、NIS ethers(4) マップまたはブートサーバー上にこのシステムのエントリがあることを確認します。さらに、サーバーとクライアントの IP アドレスを調べて、両者が同一のサブネット上にあることを確認します。また、ローカルの /etc/hosts ファイルが、ethers の内容、および NIS の hosts(4) マップと矛盾していてはいけません。
これらが原因でなかった場合は、システムの PROM モニタの ok プロンプトで test net を実行して、ネットワークの接続を調べます (古い PROM モニタでは test-net を使用してください)。ネットワークテストが失敗する場合は、Ethernet のポート、カード、ヒューズ、ケーブルを調べて、必要に応じて交換します。また、ツイストペアポートも調べて、正しいサブネットに接続されていることを確認します。
パケットの詳細については、『日本語 Solaris のインストール (SPARC 版)』を参照してください。AnswerBook のオンラインマニュアルを使用している場合は、「ARP/RARP」と入力して検索文字列として使用します。
STREAMS ioctl コールに設定されたタイマーがタイムアウトしました。このエラーの原因はデバイスによって異なり、ハードウェアまたはソフトウェアの障害、あるいは特定の操作に対してタイムアウト値が短すぎるということを示しています。ioctl(2) 操作のステータスは不定です。このエラーは、_lwp_cond_timedwait(2) や cond_timedwait(3THR) によるタイムアウトの場合にも返されます。
このエラーの記号名は、ETIME、errno=62 です。
4.1.3C Sbus カードによりシステムフリーズになりました。
ファイルに対して、最大数 (LINK_MAX、デフォルトでは 32767) を超えるハードリンクを作成しようとしました。サブディレクトリのそれぞれが親ディレクトリへリンクされているため、多数のサブディレクトリを作成しようとすると同じエラーが発生します。
同じファイルに対して多数のリンクが存在する理由を調べます。最大数を超えるハードリンクを得るには、シンボリックリンクを使用します。
このエラーの記号名は、EMLINK、errno=31 です。
プロセスが多くのファイルを一度に開きすぎました。システムは、ファイルをオープンできる制限値としてプロセスごとのソフト制限値である OPEN_MAX (通常は 64 ですが、増やすことができます) と、プロセスごとのハード制限値 (通常は 1024 で、これ以上増やすことはできません) を適用します。
ソフト制限値はシェルから変更できます。C シェルの場合は、limit(1) コマンドを使用して記述子の数を増やします。Bourne シェルまたは Korn シェルの場合は、-n オプションを付けた ulimit コマンドを使用して、ファイル記述子の数を増やします。
このエラーのために、ウィンドウシステムが新たなアプリケーションの起動を拒否する場合は、ウィンドウシステムを起動する前に、ログインシェルのファイルをオープンできる制限値を大きくします。
このエラーの記号名は、EMFILE、errno=24 です。
すでに接続されているトランスポート終端に対して接続要求が行われたか、あるいはすでに接続されているにもかかわらず sendto(3XNET) または sendmsg(3XNET) のトランスポート終端に、接続先が指定されました。
このエラーの記号名は、EISCONN、errno=133 です。
トランスポート終端が接続されていないか、データグラムの送信時にアドレスの指定がなかったため、データ送受信の要求が拒否されました。
このエラーの記号名は、ENOTCONN、errno=134 です。
Ultra システムが「TRAP 3E」で起動に失敗しました。システムは、不良マジックナンバーエラーを表示することもあります。
このエラーは、起動ディスク上に不良スーパーブロックがあることが原因で発生します。この不良スーパーブロックは、SCSI 設定の問題が原因で発生した可能性があります。
解決策は次のとおりです。
SCSI バスに、不当な設定、不良ケーブル、重複した SCSI などがないかどうかを調べます。
CD-ROM からシングルユーザーとして起動します。
OK boot cdrom -sw |
起動ディスクに対して fsck(1M) を実行します。すると、おそらくスーパーブロックのエラーで失敗します。
# fsck /dev/rdsk/device |
代わりのスーパーブロックの場所を見つけます。必ず大文字の -N を使用してください。次に例を示します。
# newfs -N /dev/rdsk/c0t0d0s0 /dev/rdsk/c0t0d0s0: 2048960 sectors in 1348 cylinders of 19 tracks, 80 sectors 1000.5MB in 85 cyl groups (16 c/g, 11.88MB/g, 5696 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 24432, 48832, 73232, 97632, 122032, 146432, 170832, 195232, 219632, 244032, 268432, 292832, 317232, 341632, 366032, 390432, 414832, 439232, 463632, 488032, 512432, 536832, 561232, 585632, 610032, 634432, 658832, 683232, 707632, 732032, 756432, 778272, 802672, 827072, 851472, 875872, 900272, 924672, 949072, 973472, 997872, 1022272, 1290672, ... |
代替スーパーブロックを使用して、fsck(1M) をディスクで実行してください。代替スーパーブロックを繰り返し実行しなければ機能しない場合があります。最初と中間と最後からいくつかのブロック番号を抜き出して試してください。
# fsck -o b=<altblk> /dev/rdsk/c0t0d0s0 |
ブートブロックも不良である場合があります。起動に使用した CD-ROM の中のブートブロックで復元してください。
# /usr/sbin/installboot /usr/platform/architecture/lib/fs/ufs/bootblk /dev/rdsk/c0t0d0s0 |
オペレーティング環境を再起動します。
# reboot |