Linux kerneld mini-HOWTO Henrik Storner
kerneld-howto@linuxdoc.org
 JF Project 日本語訳
JF@linux.or.jp
 v2.0 22 May 2000 conversion from HTML to DocBook SGML. 2000 Linux Documentation Project <kerneld-howto@linuxdoc.org> Copyright この文書の著作権は、Henrik Storner, 1996, 1997 が保持しています。 別段の表記がない限り、この Linux HOWTO 文書の著作権は、個々の著者が 保持しています。Linux HOWTO 文書は、この著作権表示がすべての複製上に 記載されるならば、全体・部分を問わず、あらゆるメディアにおいて、複製・ 頒布することができます。商用での配布も許諾すると同時に、推奨しますが、 その際には、著者に連絡してくれることを希望します。 翻訳もしくは(Linux HOWTO 文書の統合を含む)二次的著作物を作成した場合は、 必ずこの利用許諾を付けなければなりません。すなわち、Linux HOWTO 文書から 二次的著作物を作成し、それに対してこの利用許諾以上の制限を付けることは できません。ただ、このルールには条件付きの例外もあり得るので、詳細に ついては以下の Linux HOWTO コーディネイタに連絡してください。 すなわち、われわれは、これらの文書上の情報を可能なかぎりのチャンネルを 通じて普及したいと考えています。しかし、同時に HOWTO 文書に対する著作権 も保持したいと思っているので、HOWTO 文書を頒布する計画をお持ちの場合は、 われわれに知らせてください。 質問があれば、Linux HOWTO コーディネイタ <linux-howto@sunsite.unc.edu > までメールをお送りください。 <!--About the kerneld mini-HOWTO--> kerneld mini-HOWTO について この文書では、自動カーネルモジュールローダである kerneld のインストールと使い方について説明します。この文書の最新版は、 Linux Documentation Project にあります。 Credits この文書は、Henrik Storner <storner@osiris.ping.dk> が 1997年7月 19日に作成した HTML バージョン 1.7 をベースにして、Gary Lawrence Murphy <garym@teledyn.com> が 2000年5月20日に改訂および DocBook 化を行いました。 この mini-HOWTO の作成にあたっては、以下の方々にお世話になりました。 Bjorn Ekwall bj0rn@blox.se Ben Galliart bgallia@luc.edu Cedric Tefft cedric@earthling.net Brian Miller bmiller@netspace.net.au James C. Tsiao jtsiao@madoka.jpl.nasa.gov この文書に間違いがあった場合は、<kerneld-howto@linuxdoc.org> まで メールでお知らせください。コメント・激励・提案は、歓迎いたします。 この文書を更新し、より正確なものにしてゆくために、ご連絡をお願いします。 <!--What is kerneld?--> kerneld とは？ この文書で紹介する kerneld というプログラムは、Bjorn Ekwall によって、 開発版カーネル 1.3 の配布当時に導入されました。kerneld を使うと、 デバイスドライバやネットワークドライバ、ファイルシステムなどの カーネルモジュールが必要に応じて自動的にロードされるようになります。 それゆえ、modprobe や insmod コマンドを使い、手動でモジュールをロードする必要がなくなります。 また、安定版カーネルには(今のところ？)組み込まれてはいませんが、 次のような面白い機能もあります。 初期設定のモニタ省電力プログラム(screen blanker)の代わりに、ユーザ プログラムを起動するように設定できます。つまり、どんなプログラムでもスクリーン セーバとして使うことができます。 上記モニタ省電力プログラムに関する機能と同様に、標準コンソールの ビープ音を全く違ったものに変更することができます。 kerneld は、次のふたつのコンポーネントから構成されています。 Linux カーネル空間からデーモンにリクエストを送り、特定のタスク処理 を担当するモジュールを呼び出させるカーネル機能。 カーネルからのリクエストを処理するために、どのモジュールをロード すべきか判断するユーザ空間デーモン。 kerneld の機能を働かせるには、両方のコンポーネントが動いて いなければなりません。片方だけの設定では不十分です。 <!--Why do I want to use it ?--> 何故 kerneld を使うのか？ kerneld を使うべき理由はいくつかあります。ここでは、著者自身が考える 理由を述べますが、他の人にとっては他の理由があるかもしれません。 ほとんど違いのない複数システムがあり、それらすべてのシステムのカーネル をビルドする必要がある場合、たとえばネットワークカードだけが違うと いった場合に、別々に各システムのカーネルをビルドせずとも、単一のカーネル といくつかのモジュールをビルドするだけで済みます。 開発者にとっては、モジュールのほうが、プログラムのテストがやり易く なります。ドライバのロードやアンロードをする場合でも、システムを 再起動する必要がありません。 これは、あらかじめ kerneld がロードしたモジュールだけでなく、 すべてのモジュールについて言えることです。 カーネルが使うメモリを節約できるので、アプリケーションにより多くの メモリをまわせます。カーネルが使うメモリは「絶対に」スワップアウト されないので、もし使用しないドライバをカーネルに組み込んで、それが 100Kb あったとすると、その分だけ RAM を無駄遣いしていることになります。 著者が使っている ftape フロッピーテープドライバや iBCS などは、 モジュールとしてのみ提供されているのですが、それらのモジュール を必要とするたびに毎回ロードやアンロードをする手間を省けます。 Linux ディストリビューションの作成者は、あらかじめ 284 通りのブート イメージを作成せずとも、個々のユーザが手持ちのハードウェアに応じて ドライバをロードできるようになります。現在の Linux ディストリビューション では、ハードウェアを検出して、実際に必要なモジュールだけをロード するようになっています。 とはいえ、読者が kerneld を使いたくない事情というのもあるでしょう。必要 なすべてのドライバを組み込んだ単一のカーネルイメージのほうがいい場合は、 他の文書をあたってください。 <!--Where can I pick up the necessary pieces ?--> ファイルの入手先 Linux カーネルでの kerneld サポートは、カーネル 1.3.57 で導入されました。 もしそれ以前のカーネルバージョンを使っている場合、kerneld 機能を有効に するにはカーネルのアップグレードが必要です。最新版の Linux カーネル ソースは以下のサイトから入手できますが、Linux FTP アーカイブサイト ならたいていどこででも手に入ります。 Kernel.Org Archive Metalab Linux Archive TSX-11 at MIT ユーザ空間デーモンは、modules パッケージに 同梱されています。通常これらはカーネルソースと同じ場所に置かれて います。 最新版カーネルでモジュールの自動ロードを利用しようとしている場合は、 なるべく新しい modutils パッケージを 使い、modules パッケージは使わないでください。 その際は、必ずカーネルソース付属の Documentation/Changes ファイルをチェックして、 お使いのカーネルイメージが必要とするパッケージがどのバージョン以降 なのかを確認してください。また、 FAQ に記述した、モジュールと 2.1 カーネルでの問題についてもご覧 ください。 <!--How do I set it up?-->設定方法 まず必要なパーツを入手します。適当なカーネルと最新版 modules パッケージです。つぎに、パッケージの指示に 従って、モジュールのユーティリティをインストールします。操作は 簡単です。パッケージを解凍して make install を 実行するだけです。これによって、genksysm、 insmod、lsmod、modprobe、 depmod、kerneld といった プログラムが /sbin にインストールされます。 この際、起動のたびに必要となる設定を初期化スクリプトに書き込んで おくことをおすすめします。以下の行を Slackware の場合は /etc/rc.d/rc.S ファイルに、Debian や Corel、Red Hat、 Mandrake、Caldera といった SysVinit 系の場合は /etc/rc.d/rc.sysinit ファイルに書き込んでください。 # Start kerneld - this should happen very early in the # boot process, certainly BEFORE you run fsck on filesystems # that might need to have disk drivers autoloaded if [ -x /sbin/kerneld ] then /sbin/kerneld fi # Your standard fsck commands go here # And you mount command to mount the root fs read-write # Update kernel-module dependencies file # Your root-fs MUST be mounted read-write by now if [ -x /sbin/depmod ] then /sbin/depmod -a fi 上記のコマンドは、お使いの SysV init スクリプトに既に書かれている 場合もあります。上段では、kerneld 自体を起動しています。下段では、 初期化のために depmod -a を実行して、 利用可能な全モジュールのリストを作成し、その依存関係を調べて います。depmod がモジュールのマップを作成し、それによって、 あるモジュールをロードする前に他のモジュールをロードしておく必要 があるかどうかを kerneld に指示します。 kerneld の最近のバージョンでは、libgdbm という GNU gdbm ライブラリとリンクするオプションが付いています。 モジュールユーティリティをビルドする際にこの機能を有効にすると、 libgdbm が使えない場合には kerneld を起動できなくなって しまいます。これが問題となるのは、/usr を 独立のパーティションとしていて、/usr が マウントされる前に kerneld が起動される場合です。おすすめする解決策 としては、/usr/lib/libgdbm を /lib に移動させるか、kerneld に静的にリンクするかのどちらかです。 つぎに、カーネルソースを解凍して、必要な設定作業を行ったうえでビルド します。カーネルの構築作業が初めての場合は、Linux ソースの最上 ディレクトリにある README ファイルを必ず読んでください。カーネル設定 で make xconfig を実行する際は、最初のほうに書かれた 以下の質問について特に注意してください。 Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y loadable module support を有効にする必要があります。でないと、 kerneld がロードすべきモジュールがコンパイルされません。ここでは、 Yes と答えてください。 Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y もちろん、これも有効にする必要があります。そうすれば、カーネル内の 多くの要素をモジュールとしてビルドすることができます。たとえば、 次のような質問をされた場合、 Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?] M と答えることで Module にする ことができます。一般に、システムの起動に必要なドライバだけを カーネルに組み込むべきであり、それ以外はモジュールとしてビルド してかまいません。 <!--Essential drivers-->必要不可欠なドライバ システムの起動に必要不可欠なドライバは、カーネル自体に組み込まなければ ならず、モジュールとしてロードすることはできません。よくある例としては、 ハードディスクのドライバやルートファイルシステムのドライバなどがそれに 該当します。デュアルブート設定にしていて、起動時に Linux 以外のファイル システム置かれたファイルを必要とする場合は、そのファイルシステム用の ドライバもカーネルに組み込んでおかなければなりません。 make config コマンドを使ってカーネルを設定する 場合は、設定後に make dep clean bzlilo modules modules_install と打てば、新規カーネルとモジュールのコンパイルおよびインストールが できます。 まあ、こんな感じでしょうか。 <!--Compiling a Kernel Image-->カーネルイメージのコンパイル make zImage コマンドを使った場合、カーネルの インストール手続きの手前まで実行された後、新規カーネルイメージが arch/i386/boot/zImage ファイルとして保存され ます。このカーネルイメージファイルを使うには、ブートイメージを 置くべき場所にこのファイルをコピーした上で、LILO コマンドによって インストールする必要があります。 カーネルを自分で設定してビルド・インストールする作業に関する詳しい 情報は、Kernel-HOWTO をご覧ください。この文書は、 comp.os.linux.answers に定期的に投稿されていて、 Linux Documentation Project やそのミラーサイトで閲覧することができます(訳注： 日本語訳は、 こちらです)。 <!--Trying out kerneld-->kerneld を使ってみる 上記設定が済んだら、リブートして新規カーネルが使えるようにします。 システムが立ち上がったら、ps ax コマンドを実行 してください。以下のような行が表示され、kerneld が動いているのが 分かるはずです。 PID TTY STAT TIME COMMAND 59 ? S 0:01 /sbin/kerneld kerneld が便利な点のひとつは、いったんカーネルとモジュールを インストールしてしまえば、それ以外にほとんど設定する必要が なくなるということです。手始めに、モジュールとしてビルドした ドライバのひとつを使ってみましょう。おそらく、何の設定をせずとも 動作するはずです。もし、フロッピーのドライバをモジュールとして ビルドしたなら、DOS フロッピーディスクをドライブに差し込んで、 次のように打つことができます。 osiris:~ $ mdir a: Volume in drive A has no label Volume Serial Number is 2E2B-1102 Directory for A:/ binuti~1 gz 1942 02-14-1996 11:35a binutils-2.6.0.6-2.6.0.7.diff.gz libc-5~1 gz 24747 02-14-1996 11:35a libc-5.3.4-5.3.5.diff.gz 2 file(s) 26689 bytes フロッピードライバが動いています！ フロッピーディスクを使おうと するとき、kerneld によりドライバが自動的にロードされるのです。 実際にフロッピーモジュールがロードされていることを確認するには、 /sbin/lsmod コマンドを実行すれば、現在ロード されているすべてのモジュールの一覧が表示されます。 osiris:~ $ /sbin/lsmod Module: #pages: Used by: floppy 11 0 (autoclean) ここで、(autoclean) とは、そのモジュールが 1 分以上 使われていなかった場合に、それが kerneld により自動的に削除される ということを意味しています。それゆえ、11 page 分のメモリ( 1 page が 4 kB なので、44 kB) は、フロッピードライブにアクセスしている 間だけ使用されることになります。1 分以上使わない状態が続くと、 そのメモリは解放されます。アプリケーションに割り当てるメモリが 足りない場合などに、この機能は非常に重宝します。 <!--How does kerneld know what module to load?--> kerneld がロードする対象のモジュールを認識する方法 kerneld は、たいていのモジュールタイプをあらかじめ認識できるように 作成されていますが、状況によっては、kernel からのリクエストを どう処理してよいか分からないということもあります。これは CD-ROM ドライバやネットワークドライバの場合に見られる症状です。ロード 可能なモジュールが複数存在しているのです。 kerneld デーモンがカーネルから受け取るリクエストは、 次のうちのどれかに該当します。 ブロック・デバイス・ドライバ キャラクタ・デバイス・ドライバ バイナリ・フォーマット tty 回線制御 ファイルシステム ネットワーク・デバイス ネットワークサービス (たとえば、rarp など) ネットワークプロトコル (たとえば、IPX など) kerneld は、設定ファイル /etc/conf.modules を スキャンしてどのモジュールをロードすべきか決定します ディストリビューションのなかには、この設定ファイルを modules.conf としているところもあります。 。このファイルには 2 種類の項目があります。ひとつはモジュールファイルが 置かれている場所へのパスであり、もうひとつは特定のサービスに対して ロードすべきモジュールを割り振っているエイリアスです。この設定ファイルが まだシステム上にない場合は、次のコマンドで作成することができます。 /sbin/modprobe -c | grep -v '^path' /etc/conf.modules デフォルトの path 設定に加えて、さらに別の path 設定を追加したい場合、 その際は、必ずデフォルトの全 path も一緒に設定してください 。 /etc/conf.modules 内に path 設定があると、 modprobe がデフォルトで認識していたすべての path が 書き換えられてしまうからです。 ただ、もともと通常必要とされる設定はなされているはずなので、それを いじって、わざわざpath を追加したいとは思わないでしょう。 上記とは異なり、alias や option の設定を追加するだけの場合、 /etc/conf.modules に対して新規に書き込まれた 設定は modprobe の既知の設定に追加されます。 alias や option を定義し直した場合、 /etc/conf.modules の新規の設定は、 もとの設定を上書きします。 <!--Block devices-->ブロックデバイス /sbin/modprobe -c を実行すると、カーネルが認識 している全モジュールと、そのモジュールに対するリスエスト名との 一覧が表示されます。たとえば、フロッピードライバをロードするための リクエストは、メジャー番号(major number) 2 を持つブロックデバイス に対するリクエストとなります。 osiris:~ $ /sbin/modprobe -c | grep floppy alias block-major-2 floppy この場合、なぜ block-major-2 という名称に なるのでしょうか？ 理由は、/dev/fd* という フロッピーデバイスがメジャーデバイス番号 2 を使うブロックデバイス だからです。 osiris:~ $ ls -l /dev/fd0 /dev/fd1 brw-rw-rw- 1 root root 2, 0 Mar 3 1995 /dev/fd0 brw-r--r-- 1 root root 2, 1 Mar 3 1995 /dev/fd1 <!--Character devices-->キャラクタデバイス キャラクタデバイスの場合も上記と同じような処理になります。たとえば、 ftape フロッピーテープドライバは、メジャーデバイス番号が 27 番となって います。この番号は次のようにして確認できます。 osiris:~ $ ls -lL /dev/ftape crw-rw---- 1 root disk 27, 0 Jul 18 1994 /dev/ftape ただ、kerneld は、初期設定のままでは ftape ドライバを認識しません。 /sbin/modprobe -c で出力されるリストには 載っていないからです。それゆえ、kerneld を設定して ftape ドライバ をロードするようにさせるには、kerneld の設定ファイルである /etc/conf.modules に次の一行を追加する 必要があります。 alias char-major-27 ftape <!--Network devices-->ネットワークデバイス char-major-xxx や block-major-yyy で設定するのではなく、デバイス名を使うことも可能です。 これが便利なのは、ネットワークドライバを使う場合です。たとえば、 eth0 で ne2000 ネットワークカードを使う場合、 次の行を付け加えます。 alias eth0 ne ドライバにオプションを渡す必要がある場合、たとえば、その カードが使用する IRQ をモジュールに指定する場合などは、 options という行を追加します。 options ne irq=5 この設定により、kerneld は以下のコマンドを使って NE2000 ドライバを ロードします。 /sbin/modprobe ne irq=5 もちろん、実際に使うオプションは、ロードするモジュールに合わせて 設定してください。 <!--Binary formats-->バイナリフォーマット バイナリフォーマットも同様に扱われます。プログラムを実行しようとして、 そのプログラムをロードする方法をカーネルが認識できない場合はいつも、 kerneld に binfmt-xxx という リクエストが送られます。ここで xxx の部分にはある 数字が入りますが、これは実行ファイルの最初の数バイトを見て決定 されます。それゆえ、たとえば、ZMAGIC の binfmt_aout モジュール ( a.out バイナリのモジュール) をロードできるよう kerneld を設定する場合、 以下のようになります。 alias binfmt-267 binfmt_aout ZMAGIC ファイルのマジック番号は 267 なので、/etc/magic をチェックすれば、0413 という数字が記載されているのが 分かると思います。kerneld は 10 進数を使いますが、 /etc/magic では 8 進数が使われているので、8 進数 413 = 10 進数 267 であることに注意してください。実際の a.out 実行 ファイルには、(NMAGIC、QMAGIC、ZMAGIC という) 3 種類の若干異なる 形式が存在しているので、binfmt_aout モジュールを完全にサポート するには以下のような設定が必要です。 alias binfmt-264 binfmt_aout # pure executable (NMAGIC) alias binfmt-267 binfmt_aout # demand-paged executable (ZMAGIC) alias binfmt-204 binfmt_aout # demand-paged executable (QMAGIC) ただ、a.out、Java、iBCS のバイナリフォーマットは、特に設定 せずとも、kerneld に自動的に認識されるようになっています。 <!--Line disciplines (slip, cslip and ppp)--> ライン制御 (slip, cslip, ppp) ライン制御は、tty-ldisc-x という 書式でリクエストされます。ここで x には、通常 SLIP 用 の 1 か、PPP 用の 3 が入ります。特に設定をせずとも、kerneld はどちらも 自動で認識します。 ppp を使う場合、kerneld に ppp 用のデータ圧縮モジュールである bsd_comp をロードさせたいときは、以下の 2 行を /etc/conf.modules に追加してください。 alias tty-ldisc-3 bsd_comp alias ppp0 bsd_comp <!--Network protocol families (IPX, AppleTalk, AX.25)--> ネットワークプロトコルファミリ (IPX, AppleTalk, AX.25) ネットワークプロトコルのなかにもモジュールとしてロードできる ものがあります。カーネルが kerneld に対してプロトコルファミリ をリクエストする際は、net-pf-X というリクエストを送ります。ここで X には、必要とするプロトコルファミリを示す数字が入ります。 たとえば、net-pf-3 というリクエストは AX.25 を、 net-pf-4 は IPX を、net-pf-5 は、AppleTalk を表しています。これらの数字は、Linux ソースの include/linux/socket.h ファイルにある AF_AX25 や AF_IPX 等の定義に基づいて決定されています。 alias net-pf-4 ipx 起動時に未定義プロトコルファミリに関するメッセージが表示される のを抑制する方法については、FAQ に詳しい情報を記載しています。 <!--File systems-->ファイルシステム ファイルシステムに関する kerneld リクエストには、そのファイル システムタイプの名称だけを使います。よくある例としては、CD-ROM のファイルシステム用に isofs モジュールをロードする場合があります。 すなわち、ファイルシステムタイプとして iso9660 を使う場合です。 その際の設定方法は以下のようになります。 alias iso9660 isofs <!--Devices requiring special configuration--> 個別の設定を必要とするデバイス デバイスのなかには、通常のようにデバイスとモジュールをエイリアスで 繋ぐだけでなく、さらにいくつかの追加設定を必要とするものがあります。 たとえば、以下のようなデバイスです。 メジャー番号 10 を持つキャラクタデバイス：種々のデバイス SCSI デバイス 特殊な初期化を必要とするデバイス <!--char-major-10 : Mice, watchdogs and randomness--> char-major-10 : マウス、watchdog、random デバイス ハードウェアデバイスは、通常、メジャー番号によって個別に認識されます。 たとえば、ftape は、char-major-27 です。 しかし、/dev には、キャラクタデバイスのメジャー 番号 10 (char major 10) を割り当てられているデバイスが各種大量に あります。該当するのは、以下のようなものです。 様々なマウス (バスマウス、PS/2 マウス) Watchdog デバイス カーネル random デバイス APM (Advanced Power Management) インターフェイス これらのデバイスは、単一のモジュールではなく、それぞれのデバイス ごとのモジュールによって制御されるので、これらの各種デバイス (misc.device)に関する kerneld の設定には、メジャー番号に加えて マイナー番号も使用されます。 alias char-major-10-1 psaux # For PS/2 mouse alias char-major-10-130 wdt # For WDT watchdog この機能を利用するには、カーネルのバージョン 1.3.82 以降が 必要です。それ以前のバージョンでは、kerneld にマイナー番号を 渡すことができないので、kerneld はどのデバイスをロードすべきか 判断できません。 <!--Loading SCSI drivers: The <literal>scsi_hostadapter</literal> entry-->SCSI ドライバのロード：<literal>scsi_hostadapter</literal> の設定 SCSI デバイスのドライバは、SCSI ホストアダプタのドライバ(たとえば、 Adaptec 1542)と、実際に使っている SCSI デバイスタイプごとのドライバ (たとえば、ハードディスク、CD-ROM、テープドライブなど)の両方から 成り立っていて、これらはすべてモジュール化できます。しかし、 たとえば、Adaptec のカードに接続した CD-ROM ドライブにアクセスしよう とする場合、カーネルと kerneld が認識するのは、SCSI CD-ROM のサポート のために sr_mod が必要だということだけです。 その CD-ROM がどのような SCSI コントローラに接続されているかは 認識しないので、どのモジュールをロードして SCSI コントローラを サポートすべきか分からないのです。 この問題を解決するには、/etc/conf.modules に SCSI ドライバモジュールの設定を書き込んで、多数ある SCSI コントローラ用のモジュールのうちどれをロードすべきか kerneld に 指示するようにします。その設定は、たとえば、以下のようになります。 alias scd0 sr_mod # sr_mod for SCSI CD-ROM's ... alias scsi_hostadapter aha1542 # ... need the Adaptec driver こうした設定は、カーネルのバージョン 1.3.82 以降でないと機能しない ので注意してください。 上記設定が有効なのは、SCSI コントローラが一枚の場合だけです。 複数の SCSI カードがある場合、設定はもう少し複雑になります。 原則として、何らかの SCSI ホストアダプタが既にインストール されている場合、それ以外のホストアダプタ用ドライバを kerneld に ロードさせることはできません。両方のドライバを(モジュールではなく) カーネルに組み込んでしまうか、もしくは手動でロードする必要があります。 kerneld に複数の SCSI ホストアダプタをロードさせる方法がある ことはあります。James Tsiao が以下のようなアイデアを教えて くれました。
modules.dsp での依存関係を手書きで設定 し直せば、kerneld にふたつ目の SCSI ホストドライバを簡単にロード させることができます。次にように設定すればいいのです。 /lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o 上記に設定により、kerneld は、st.o をロード する前に、aha1542.o をロードするようになります。 わたしの自宅のマシンの設定は上記と全く同じなのですが、テープ、 CD-ROM、その他汎用の SCSI デバイスを含む全 SCSI デバイスが 問題なく動いています。ただ、この設定の欠点としては、 depmod -a コマンドではこうした依存関係を自動認識でき ないので、ユーザが手で設定を書き加える必要があることと、起動時に depmod -a を実行してはいけないことです。 とはいえ、一旦設定が終われば、kerneld は aha1542.o をまったく問題なく自動的にロードします。
注意すべき点として、上記テクニックが有効なのは、各種 SCSI デバイスがふたつの SCSI コントローラに接続されている場合 だけであるということです。たとえば、ハードディスクが ひとつのコントローラ上にあり、CD-ROM ドライブやテープ、 およびその他の汎用 SCSI デバイスが別のコントローラ上に ある場合だけです。 <!--When loading a module isn't enough: The <literal>post-install</literal> entry--> モジュールのロードだけでは不十分な場合：<literal>post-install</literal> モジュールをロードしただけではデバイスが動かない場合があります。 例を挙げると、サウンドカードをモジュールとしてコンパイルした 場合、ボリュームを一定のレベルに設定しておくと便利です。しかし、 ここで問題となるのは、ボリュームを設定したとしても、再度モジュール をロードするとその設定が無効になってしまうことです。以下に Ben Galliart (<bgallia@luc.edu>) による便利なトリックを 紹介します。
試行錯誤の結果、 setmix パッケージ をインストール してから、以下の行を /etc/conf.modules に追加 する必要があることが分かりました。 post-install sound /usr/local/bin/setmix -f /etc/volume.conf
上記設定の意味は、sound モジュールがロード された後、kerneld が post-install sound で始まる設定行で指示されたコマンドを実行するということです。 これによって、sound モジュールは、 /usr/local/bin/setmix -f /etc/volume.conf という コマンドによって設定されます。 これは、他のモジュールを使う場合にも便利だと思います。たとえば、 lp モジュールを tunelp プログラムによって設定するには以下のようにします。 post-install lp tunelp options kerneld にこのオプションを認識させるには、kerneld のバージョン 1.3.69f 以降が必要です。 この mini-HOWTO の以前のバージョンでは pre-remove オプションに ついて説明していました。これは、kerneld がモジュールを削除する 直前に、特定のコマンドを実行するために利用されるはずのもの でした。しかし、結局この機能は使い物にならなかったので、 利用しないよう呼びかけがあり、おそらく今後の kerneld のリリース からこのオプションは姿を消すでしょう。現在、モジュールの設定 方法全体が見直されているので、読者がこの文書を読む頃には、 システム上で違う設定が要求されているかもしれません。 <!--Spying on kerneld--> kerneld の動作を監視する方法 あらゆる事柄を試してみても、カーネルが kerneld に対して何をさせようと しているのかが分からない場合、kerneld が受け取っているリクエスト を確認して、/etc/conf.modules に何を書き込む べきかを理解する手段があります。kdstat ユーティリティです。 この気の利いたプログラムは、module のパッケージに同梱されている のですが、デフォルトではコンパイルもインストールもされません。 ビルドするには、kerneld のソースコードがあるディレクトリに移動 して、make kdstat と打ち込んでください。 そして、kerneld に動作情報を表示させるために、kdstat debug を実行すると、kerneld は自己の動作に関する メッセージをコンソールに出力します。この状態で、使いたいコマンド を実行すると、該当する kerneld へのリクエストを見ることが できます。このリクエストを /etc/conf.modules に書き込んで、そのジョブを実行するのに必要な モジュールへのエイリアスを通すと、設定ができます。 デバッギングを終了するには、/sbin/kdstat nodebug を実行してください。 <!--Special kerneld uses--> 特殊な kerneld の使い方 読者は、スクリーンセーバ・モジュールの設定方法を知りたいと お思いかもしれません。もちろん、説明します！ モジュールパッケージの kerneld/GOODIES というディレクトリには、kerneld でスクリーンセーバや コンソールビープ音等をサポートするカーネルパッチがあります。 これらはまだ正式なカーネルの一部とはなっていないので、利用する には、これらのカーネルパッチをインストールした上でカーネルを 再構築する必要があります。 パッチをインストールするには、次のような patch コマンドを使います。 cd /usr/src/linux patch -s -p1 /usr/src/modules-*/kerneld/GOODIES/blanker_patch その上で、カーネルを再構築し、作成された新規カーネルをインストール します。 以上で、スクリーンセーバ起動の要請があると、kerneld は /sbin/screenblanker というファイルをコマンドとして実行する ようになります。このファイルの中身は好みに応じて変更することが できます。たとえば、自分が好きなスクリーンセーバを起動するシェル スクリプトに変更することができます。 カーネルがスクリーンをもとに戻す際は、SIGQUIT シグナル が /sbin/screenblanker を実行しているプロセスに 送信されます。入れ替えたシェルスクリプトやスクリーンセーバは、 これをトラップして、終了できなければなりません。スクリーンを もとのテキストモードに戻すという処理を忘れないでください。 <!--Common problems and things that make you wonder--> よくある問題と疑問 /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 を無効にすることのないよう注意して ください。 kerneld を使い初めてから、PPP コネクションを張っている 際に、システムの反応が非常に遅くなってしまいました。 これについては、複数のユーザから報告を受けています。残念な ことに、tkPPP スクリプトを使って PPP コネクションをモニターさせる設定にすると、システムに よっては kerneld との間で動作が干渉するようです。このスクリプト は、ifconfig を実行しながらループ処理を しているようですが、これが kerneld の起動を誘発し、kerneld は net-pf-X モジュール (上記参照)を探そうとするので、システム負荷が高くなり、 場合によってはシステムログに "Cannot locate module for net-pf-X" というメッセージが 大量に吐き出されます。これを回避する方法はまだ見つかっていない ので、tkPPP を使わないようにするか、 コネクション監視の方法を変えるかする以外にありません。 kerneld が SCSI ドライバをロードしてくれない！ SCSI ホストアダプタの設定を /etc/conf.modules に追加してください。詳しくは、scsi_hostadapter の設定についての記述をご覧ください。 modprobe が gcc2_compiled が未定義だと 文句を言う。 これは、モジュールユーティリティのバグであり、binutils 2.6.0.9 以降と組み合わさった場合のみ見られるものです。binutils のリリース ノートにも記述されていますので、それを読むか、バグが修正された モジュールユーティリティのアップグレード版をダウンロードして 使ってください。 サウンドドライバのボリューム等の設定を記憶させたい。 モジュールに関する設定は、ロードされている間、モジュール自体の内部に 保存されます。それゆえ、kerneld がそのモジュールを自動的にアンロード すると、ユーザが行った設定はすべて消去されるので、再度モジュール がロードされた際にはデフォルトの設定に戻ってしまいます。 モジュールが自動的にロードされた後に、何らかのプログラムを実行して モジュールを設定するよう kerneld に指示することができます。 Section 5.3 の post-install の設定をご覧ください。 DOSEMU でモジュールを使う必要があるのですが、どうすれば kerneld に それらをロードさせることができますか？ できません。正式版の DOSEMU も開発版のほうでも、kerneld を使った dosemu モジュールのロードはサポートされていません。しかし、 もしカーネル 2.0.26 以降を使っているなら、特別な dosemu モジュール は不要になりました。DOSEMU を 0.66.1 かそれ以降のバージョンに アップグレードしてください。 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 をチェック してください。 kerneld がファイルシステムモジュールをロードするのを待たずに、 mount が実行されてしまう。 mount(8) コマンドが kerneld のファイルシステムモジュールのロードを 待たずに実行されてしまう問題については、数多くの報告が既になされて います。lsmod を使うと、kerneld がロードした モジュールの一覧が表示されるので、そのすぐ後で mount コマンドを再実行 すれば上手くいくと思います。これはモジュールユーティリティのバージョン 1.3.69f のバグのようであり、Debian ユーザがこの影響を受けているようです。 モジュールユーティリティの最新バージョンを入手すれば解決します。 kerneld が ncpfs モジュールをロード できません。 ncpfs ユーティリティは、-DHAVE_KERNELD を付けて コンパイルする必要があります。詳しくは、ncpfs の Makefile をご覧ください。 kerneld が smbfs をロードできません。 smbmount ユーティリティの古い バージョンを使っているのだと思われます。最新バージョン (0.10 以降)を the SMBFS archive one TSX-11 から入手してください。 モジュール化が可能なものすべてをモジュールとしてビルドしたら、 システムが起動しなくなったり、kerneld がルートファイルシステム モジュールをロードできなくなったりします。 あらゆるものをモジュール化できるというわけではありません。 カーネルには最低限必要なドライバを組み込んで、ルートファイル システムをマウントしたり、必要なプログラムを実行したりして、 kerneld を起動し得る状態にしなければなりません 実際のところ、これは真実ではありません。1.3.x 以降や 2.x での カーネルは、起動時に ram-disk が使えるようになっていて、これを LILO や Loadlin でロードすることができます。このディスクから 起動の初期の段階でモジュールをロードすることが可能です。 設定方法は、カーネルソースに付属する linux/Documentation/initrd.txt ファイルに 記述されています。 。すなわち、以下のドライバはモジュール化できません。 ルートファイルシステムが乗っているハードディスクの ドライバ ルートファイルシステム自体のドライバ init、kerneld その他をロードするバイナリフォーマット のローダ 起動時に kerneld がロードされません。libgdbm 関する エラーが出ます。 kerneld の新しいバージョンでは、GNU dbm ライブラリ libgdbm.so を起動する必要があります。 インストール時にはたいていこのファイルが /usr/lib に置かれるのですが、おそらく /usr ファイルシステムがマウントされる前に kerneld が起動されているのではないかと思われます。この場合の 症状として、kerneld は、ブート時に (rc スクリプトから) 起動され ることがないのに、システムが立ち上がった後なら手動で起動できる というのがあります。解決策としては、/usr が マウントされた後に kerneld を起動するようにするか、もしくは、 gdbm ライブラリを /lib 等のルートファイル システム上に移動させるかのいずれかです。 Cannot load module xxx というエラーが出るのですが、カーネル再構築の際に xxx は無効にしているのです！ Slackware (もしくはそれ以外でも)をインストールすると、デフォルトで /etc/rc.d/rc.modules が作成され、このファイル 内で各種モジュールに対して明示的に modprobe が実行されます。 modprobe の対象となるモジュールがどれであるかは、インストール時の カーネル設定をもとに決められています。おそらくカーネルを再構築して、 rc.modules で modprobe を実行されるはずの モジュールのいくつかを無効にしたために、エラーメッセージが出ている のだと思います。rc.modules を編集して 使わなくなったモジュールをコメントアウトするか、 rc.modules ファイル自体を削除して必要なときに kerneld にモジュールをロードさせるようにしてください。 カーネルとモジュールを再構築したのですが、それでも起動時に unresolved symbols というメッセージが表示されます。 おそらく、カーネルを再設定・再構築して、モジュールのいくつか を無効にしたのだと思われます。使わなくなった古いモジュールが /lib/modules ディレクトリに残っていて、 それが邪魔をしているのです。最も簡単な解決策は、 /lib/modules/x.y.z ディレクトリ を丸ごと削除して、カーネルソースディレクトリで再度 make modules_install を実行することです。この問題は、 カーネルのバージョンはそのままで再構築した場合のみ起こるもの であることに注意してください。もし新しいカーネルバージョンに 移行したのに、このエラーが表示される場合は、これとは異なる 問題が発生していることになります。 Linux 2.1/2.3 をインストールしたら、モジュールがまったく ロードできなくなってしまった！ 奇数番号の Linux では開発版カーネルが使われています。それゆえ、 ときどき不具合が生じるのは致し方ありません。大幅な変更がなされた 点として、モジュールの処理方法と、カーネルとモジュールが ロードされるメモリの位置の変更があります。 つまり、開発版カーネルでモジュールを利用する場合、次のことを 実行すべきです。 Documentation/Changes ファイルを読んで、 システム上でアップグレードを必要とするパッケージがどれであるかを 確認すること。 modutils パッケージの最新版を使うこと。これは、 Red Hat の AlphaBits やそのミラーサイト TSX-11 から入手できます。 2.1 カーネルでモジュールを使いたい場合は、最低でもカーネル 2.1.29 を 使用することをおすすめします。 ダイヤル・オン・デマンドでのネットワーキングは可能ですか？ もともと、kerneld ではオンデマンドでのダイヤルアップネットワーク 接続の確立をサポートしていました。コネクションが確立されていない 状態でパケットをネットワークに送信しようとした場合、kerneld が /sbin/request_route スクリプトを実行して、 PPP や SLIP コネクションを設定するようになっていました。 しかし、結局この仕組みはよくないということになりました。 Linux ネットワーキングの開発で有名な Alan Cox は、 linux-kernel メーリングリストに次のように書いています。
request-route の仕組みは、時代遅れのオンボロとなって いるから、不要だ。 [...] これも 2.1.x から削除していい。
request-route スクリプトと kerneld の組み合わせのかわりとして、 Eric Schenk の diald パッケージ を使って、デマンドダイアリングを運用する ことをおすすめします。