--- [管理番号 180] (最終更新 2003/11/17 02:28:48) Q. カーネルが panic する場所を特定したいのですが、 デバッグ用シンボルテーブルを含んだカーネルはどうやったら 作れるのですか? A. config(8) コマンドに -g オプションをつけて # config -g MYKERNEL とするか、カーネルコンフィギュレーションファイルに makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols などという行を付け加え、config(8) コマンドを実行します。 あとは普通に make すればいいのですが、このように作成された カーネルはデバッグ用の情報を含むためサイズが大きなものとなります。 たとえば 4.3-RELEASE の場合、通常 2 MB 強のカーネルが 9 MB 弱程度にまで大きくなるので、ルートファイルシステムの 残り容量に気をつける必要があります。strip(1) したカーネルを インストールしましょう。 [4.0-RELEASE 以降] 普通にカーネルの再構築の要領で make すれば、デバッグ用のカーネル kernl.debug が作成され、make install の際には objcopy(1) で デバッグ情報の取り除かれたカーネルが自動的にインストールされます。 [3.x-RELEASE 系列まで] 次のようにして、デバッグ情報を含んだカーネルのバックアップを作成し、 デバッグ情報を取り去ったものをインストールします。 # cp kernel kernel.debug # strip -x kernel # make install kernel デバッグの時は、次の例のように kernel.debug の方を指定します。 # cd /usr/src/sys/compile/MYKERNEL # gdb -k ./kernel.debug /var/crash/vmcore.0 デバッグの際には次のページが参考になるでしょう。 --- [管理番号 181] (最終更新 1999/02/17 23:58:45) Q. crash dumpを記録するにはどうすればよいのですか? A. 2つ方法があります。 1つはdump用のデバイスを指定する方法です。具体的にはdumponコマンドを使いますが、 2.2.1-RELEASEの場合は/etc/sysconfigのdumpdevを指定するか、あるいはカーネル 構築時に設定すればOKです。 もう1つは/var/crashに書き込む方法です。具体的にはsavecoreコマンドを使いますが、 2.2.1-RELEASEの場合は/etc/sysconfigのsavecoreをYESに指定してください。ただし /varの容量を主記憶の大きさ+minfreeの容量(通常2Mbyte、詳しくはman savecoreを 参照)分食いますので残り容量に注意してください。 もっともcrash dumpを記録するのは、デバッグ用のシンボルテーブルが付いた カーネルでないと意味はないので気をつけましょう。 --- [管理番号 182] (最終更新 2004/04/09 05:05:57) Q. crash dump を swap デバイスに取ったのですが、どうやってこの dump 結果を見たらよいのでしょうか? A. swap デバイスはマルチユーザモードでは中身が変更されてしまいます。 ですからシングルユーザモードで上げてください。crash 直後は各 ファイルシステムが clean な状態になっていないので、 1. boot: kernel -s でシングルユーザモードで起動する。 2. fsck -p でファイルシステムをチェックする。 3. mount -a -t ufs で ufs のファイルシステムをマウントする。 4. savecore -N /kernel /var/crash とする。 という操作で /var/crash/ に vmcore.0 などが作成されます。vmcore は セキュリティ上の理由で、root しか読めません。 ここまでの一連の動作は、/etc/rc.conf に dumpdev 変数を適切に 定義しておく事で /etc/rc の中で、自動的に行われます (もちろん fsck で止まったりしなければ)。 最後に gdb -k /kernel /dev/ad0b (/dev/ad0b が crash dump 用のデバイスの場合) とすれば OK です。カーネルにはデバッグ用のシンボルテーブルを 付けるのをお忘れなく。 --- [管理番号 183] (最終更新 1999/02/17 23:58:45) Q. Xを上げていてpanicしてしまったのですが、panicのログはどこを見れば 書いてあるのでしょうか。 A. /var/log/messagesを見てください。/kernelからのメッセージとして 書かれています。 --- [管理番号 682] (最終更新 1999/02/17 23:58:45) Q. CVSup の実行中いきなりリブートしてしまいます。/var/log/messages に /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or increase maxusers! というメッセージが残ってました。 A. これはネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなっ たことを示しています。コンフィギュレーションファイルに options NMBCLUSTERS=2048 の一行を付け加えてカーネルを再構築してください。詳しくは を御覧ください。なお、カーネル再構築後、リブートしたら netstat -m で mbuf クラスタの割り当て状況を確認することを御勧めします。max が設定 された値になっていればいいわけです。 --- [管理番号 702] (最終更新 2003/11/17 02:28:48) Q. lkm(4) または kld(4) に関係した問題で、CD-ROM をマウントしようとして # mount -t cd9660 /dev/cd0a /cdrom を実行すると、OS がリブートしてしまいました。また、MSDOSFS や NFS 及 びその他のモジュールでも起り得る現象で、もちろん現象としてはリブート するとは限らず予測不能です。 A. FreeBSD 2.2.X-RELEASE までの LKM (Loadable Kernel Module)、または 3.0-R で登場して 3.1-R 以降 LKM と置き換えられた KLD (Dynamic Kernel Linker) を使用している場合、カーネルにコンフィグファイルの修正以外の 変更を加えると、カーネルと LKM / KLD との不整合が生じることがあります。 以下の点を確認してください。 (1) カーネルのコンフィグファイルに、以下の行はありますか。 なければ、LKM または KLD を使用していることになります。 options "CD9660" #ISO 9660 filesystem (2) 最近、カーネルソースに、コンフィグファイルの修正以外の変更を加え ましたか。例えばパッチを当てた場合や CVSup した場合などもこの ケースに該当します。 (1) が no、(2) が yes の時は、次の作業を行ない、LKM または KLD を作り 直してください。/usr/src 以下には最低限のカーネルソース (src/ssys.* 配布ファイル) が展開されているものとします。 a) LKM (2.2.X-RELEASE) $ su # cd /usr/src/lkm # make clean # make all install LKM バイナリは /lkm にインストールされています。また関連コマンドと して modload(8), modstat(8), modunload(8) があります。 b) KLD (3.0-RELEASE 以降) $ su # cd /usr/src/sys/modules # make clean # make all install KLD モジュールは /modules にインストールされています。また関連 コマンドとして kldload(8), kldstat(8), kldunload(8) があります。 --- [管理番号 784] (最終更新 1999/02/17 23:58:45) Q. 終了手順を踏まなければならないことは理解しているのですが、 どうしてもリセットを行なわなければならない事態に陥ってしまいました。 何か注意することはありますか？ A. いきなり電源を切ってはいけません。 ちゃんと、お祈りしてから切りましょう リセットしなければならないと思ってから、しばらく放置して下さい。 どれくらいの時間放置すればよいのかはっきりしたことはわかりませんが、 1 分程度待って下さい (これが十分かどうかはわかりません)。運がよければ この間にまだファイルシステムに書かれていなかったデータがディスクに 書き込まれます。すると、ファイルシステムの整合性を損なうことが なくなるので、起動時には "clean flag" が立っていないこと以外は 正常である可能性が高くなります。