8. よくある問題と疑問

8.1. /sbin/ifconfig を実行すると、Cannot locate module for net-pf-X というメッセージが表示されるのは何故でしょう?
8.2. kerneld を使い初めてから、PPP コネクションを張っている 際に、システムの反応が非常に遅くなってしまいました。
8.3. kerneld が SCSI ドライバをロードしてくれない!
8.4. modprobe が gcc2_compiled が未定義だと 文句を言う。
8.5. サウンドドライバのボリューム等の設定を記憶させたい。
8.6. DOSEMU でモジュールを使う必要があるのですが、どうすれば kerneld に それらをロードさせることができますか?
8.7. Ouch, kerneld timed out, message failed と いうメッセージが表示されるのは、なぜでしょう?
8.8. kerneld がファイルシステムモジュールをロードするのを待たずに、 mount が実行されてしまう。
8.9. kerneld が ncpfs モジュールをロード できません。
8.10. kerneld が smbfs をロードできません。
8.11. モジュール化が可能なものすべてをモジュールとしてビルドしたら、 システムが起動しなくなったり、kerneld がルートファイルシステム モジュールをロードできなくなったりします。
8.12. 起動時に kerneld がロードされません。libgdbm 関する エラーが出ます。
8.13. Cannot load module xxx というエラーが出るのですが、カーネル再構築の際に xxx は無効にしているのです!
8.14. カーネルとモジュールを再構築したのですが、それでも起動時に unresolved symbols というメッセージが表示されます。
8.15. Linux 2.1/2.3 をインストールしたら、モジュールがまったく ロードできなくなってしまった!
8.16. ダイヤル・オン・デマンドでのネットワーキングは可能ですか?

8.1. /sbin/ifconfig を実行すると、Cannot locate module for net-pf-X というメッセージが表示されるのは何故でしょう?

カーネルバージョン 1.3.80 の頃に、ネットワーク関係のコードが 変更され、(IPX や AX.45、AppleTalk といった)プロトコルファミリ がモジュールとしてロードできるようになりました。このために、 net-pf-X という kerneld への リクエストが新規に追加されました。ここで X には プロトコルを判別するための数字が入ります(種々の数字の意味について は、/usr/src/linux/include/linux/socket.h を ご覧ください)。ただ、残念なことに、ifconfig はたまたまこうしたメッセージをトリガーしてしまっているようです。 それゆえ、システムの起動時に ifconfig で ループバックデバイスが設定される際に、多くのユーザのログにそうした メッセージが出力されてしまいます。このメッセージは無害であり、 /etc/conf.modules に以下の行を追加すれば出力 されなくなります。

  alias net-pf-3 off      # Forget AX.25
  alias net-pf-4 off      # Forget IPX
  alias net-pf-5 off      # Forget AppleTalk

当然ではありますが、IPX をモジュールとして使う場合は、 上記の行を追加して IPX を無効にすることのないよう注意して ください。

8.2. kerneld を使い初めてから、PPP コネクションを張っている 際に、システムの反応が非常に遅くなってしまいました。

これについては、複数のユーザから報告を受けています。残念な ことに、tkPPP スクリプトを使って PPP コネクションをモニターさせる設定にすると、システムに よっては kerneld との間で動作が干渉するようです。このスクリプト は、ifconfig を実行しながらループ処理を しているようですが、これが kerneld の起動を誘発し、kerneld は net-pf-X モジュール (上記参照)を探そうとするので、システム負荷が高くなり、 場合によってはシステムログに "Cannot locate module for net-pf-X" というメッセージが 大量に吐き出されます。これを回避する方法はまだ見つかっていない ので、tkPPP を使わないようにするか、 コネクション監視の方法を変えるかする以外にありません。

8.3. kerneld が SCSI ドライバをロードしてくれない!

SCSI ホストアダプタの設定を /etc/conf.modules に追加してください。詳しくは、scsi_hostadapter の設定についての記述をご覧ください。

8.4. modprobe が gcc2_compiled が未定義だと 文句を言う。

これは、モジュールユーティリティのバグであり、binutils 2.6.0.9 以降と組み合わさった場合のみ見られるものです。binutils のリリース ノートにも記述されていますので、それを読むか、バグが修正された モジュールユーティリティのアップグレード版をダウンロードして 使ってください。

8.5. サウンドドライバのボリューム等の設定を記憶させたい。

モジュールに関する設定は、ロードされている間、モジュール自体の内部に 保存されます。それゆえ、kerneld がそのモジュールを自動的にアンロード すると、ユーザが行った設定はすべて消去されるので、再度モジュール がロードされた際にはデフォルトの設定に戻ってしまいます。

モジュールが自動的にロードされた後に、何らかのプログラムを実行して モジュールを設定するよう kerneld に指示することができます。 Section 5.3post-install の設定をご覧ください。

8.6. DOSEMU でモジュールを使う必要があるのですが、どうすれば kerneld に それらをロードさせることができますか?

できません。正式版の DOSEMU も開発版のほうでも、kerneld を使った dosemu モジュールのロードはサポートされていません。しかし、 もしカーネル 2.0.26 以降を使っているなら、特別な dosemu モジュール は不要になりました。DOSEMU を 0.66.1 かそれ以降のバージョンに アップグレードしてください。

8.7. Ouch, kerneld timed out, message failed と いうメッセージが表示されるのは、なぜでしょう?

カーネルが kerneld にリクエストを送ると、カーネルは、kerneld からの 応答確認を 1 秒以内に受信することを期待します。kerneld がこの応答確認 を送信しない場合、上記メッセージがログに出力されます。このリクエストは 再度送信され、最終的に kerneld に渡されます。

上記の問題は、通常、非常に負荷の高いシステム上で起こります。 kerneld はユーザモードのプロセスなので、スケジューリング において、システム上の他のプロセスと同じ扱いになります。 システムの負荷が高い場合、カーネルのタイムアウト時間が経過する 前に応答確認を送信する順番が回ってこない場合があるのです。

システム負荷が低い場合にもこの問題が起こるようなら、kerneld を 再起動してみてください。kerneld プロセスを kill して、再度 /usr/sbin/kerneld でプロセスを起動します。 それでも問題が解消しないときは、バグレポートを <linux-kernel@vger.rutgers.edu> にメールしてください。 ただ、バグレポートを送る前には、必ずカーネル、kerneld および モジュールユーティリティのバージョンが最新版であることを 確かめてからにしてください。使用環境については、 linux/Documentation/Changes をチェック してください。

8.8. kerneld がファイルシステムモジュールをロードするのを待たずに、 mount が実行されてしまう。

mount(8) コマンドが kerneld のファイルシステムモジュールのロードを 待たずに実行されてしまう問題については、数多くの報告が既になされて います。lsmod を使うと、kerneld がロードした モジュールの一覧が表示されるので、そのすぐ後で mount コマンドを再実行 すれば上手くいくと思います。これはモジュールユーティリティのバージョン 1.3.69f のバグのようであり、Debian ユーザがこの影響を受けているようです。 モジュールユーティリティの最新バージョンを入手すれば解決します。

8.9. kerneld が ncpfs モジュールをロード できません。

ncpfs ユーティリティは、-DHAVE_KERNELD を付けて コンパイルする必要があります。詳しくは、ncpfsMakefile をご覧ください。

8.10. kerneld が smbfs をロードできません。

smbmount ユーティリティの古い バージョンを使っているのだと思われます。最新バージョン (0.10 以降)を the SMBFS archive one TSX-11 から入手してください。

8.11. モジュール化が可能なものすべてをモジュールとしてビルドしたら、 システムが起動しなくなったり、kerneld がルートファイルシステム モジュールをロードできなくなったりします。

あらゆるものをモジュール化できるというわけではありません。 カーネルには最低限必要なドライバを組み込んで、ルートファイル システムをマウントしたり、必要なプログラムを実行したりして、 kerneld を起動し得る状態にしなければなりません [1] 。すなわち、以下のドライバはモジュール化できません。

  • ルートファイルシステムが乗っているハードディスクの ドライバ

  • ルートファイルシステム自体のドライバ

  • init、kerneld その他をロードするバイナリフォーマット のローダ

8.12. 起動時に kerneld がロードされません。libgdbm 関する エラーが出ます。

kerneld の新しいバージョンでは、GNU dbm ライブラリ libgdbm.so を起動する必要があります。 インストール時にはたいていこのファイルが /usr/lib に置かれるのですが、おそらく /usr ファイルシステムがマウントされる前に kerneld が起動されているのではないかと思われます。この場合の 症状として、kerneld は、ブート時に (rc スクリプトから) 起動され ることがないのに、システムが立ち上がった後なら手動で起動できる というのがあります。解決策としては、/usr が マウントされた後に kerneld を起動するようにするか、もしくは、 gdbm ライブラリを /lib 等のルートファイル システム上に移動させるかのいずれかです。

8.13. Cannot load module xxx というエラーが出るのですが、カーネル再構築の際に xxx は無効にしているのです!

Slackware (もしくはそれ以外でも)をインストールすると、デフォルトで /etc/rc.d/rc.modules が作成され、このファイル 内で各種モジュールに対して明示的に modprobe が実行されます。 modprobe の対象となるモジュールがどれであるかは、インストール時の カーネル設定をもとに決められています。おそらくカーネルを再構築して、 rc.modules で modprobe を実行されるはずの モジュールのいくつかを無効にしたために、エラーメッセージが出ている のだと思います。rc.modules を編集して 使わなくなったモジュールをコメントアウトするか、rc.modules ファイル自体を削除して必要なときに kerneld にモジュールをロードさせるようにしてください。

8.14. カーネルとモジュールを再構築したのですが、それでも起動時に unresolved symbols というメッセージが表示されます。

おそらく、カーネルを再設定・再構築して、モジュールのいくつか を無効にしたのだと思われます。使わなくなった古いモジュールが /lib/modules ディレクトリに残っていて、 それが邪魔をしているのです。最も簡単な解決策は、/lib/modules/x.y.z ディレクトリ を丸ごと削除して、カーネルソースディレクトリで再度 make modules_install を実行することです。この問題は、 カーネルのバージョンはそのままで再構築した場合のみ起こるもの であることに注意してください。もし新しいカーネルバージョンに 移行したのに、このエラーが表示される場合は、これとは異なる 問題が発生していることになります。

8.15. Linux 2.1/2.3 をインストールしたら、モジュールがまったく ロードできなくなってしまった!

奇数番号の Linux では開発版カーネルが使われています。それゆえ、 ときどき不具合が生じるのは致し方ありません。大幅な変更がなされた 点として、モジュールの処理方法と、カーネルとモジュールが ロードされるメモリの位置の変更があります。

つまり、開発版カーネルでモジュールを利用する場合、次のことを 実行すべきです。

  • Documentation/Changes ファイルを読んで、 システム上でアップグレードを必要とするパッケージがどれであるかを 確認すること。

  • modutils パッケージの最新版を使うこと。これは、 Red Hat の AlphaBits やそのミラーサイト TSX-11 から入手できます。

2.1 カーネルでモジュールを使いたい場合は、最低でもカーネル 2.1.29 を 使用することをおすすめします。

8.16. ダイヤル・オン・デマンドでのネットワーキングは可能ですか?

もともと、kerneld ではオンデマンドでのダイヤルアップネットワーク 接続の確立をサポートしていました。コネクションが確立されていない 状態でパケットをネットワークに送信しようとした場合、kerneld が /sbin/request_route スクリプトを実行して、 PPP や SLIP コネクションを設定するようになっていました。

しかし、結局この仕組みはよくないということになりました。 Linux ネットワーキングの開発で有名な Alan Cox は、 linux-kernel メーリングリストに次のように書いています。

request-route の仕組みは、時代遅れのオンボロとなって いるから、不要だ。 [...] これも 2.1.x から削除していい。

request-route スクリプトと kerneld の組み合わせのかわりとして、 Eric Schenk の diald パッケージ を使って、デマンドダイアリングを運用する ことをおすすめします。

Notes

[1]

実際のところ、これは真実ではありません。1.3.x 以降や 2.x での カーネルは、起動時に ram-disk が使えるようになっていて、これを LILO や Loadlin でロードすることができます。このディスクから 起動の初期の段階でモジュールをロードすることが可能です。 設定方法は、カーネルソースに付属する linux/Documentation/initrd.txt ファイルに 記述されています。