カーネルモジュール

関連記事

• ブートデバッグ
• カーネル
• カーネルパラメータ
• カーネルモジュールのコンパイル

カーネルモジュール は、要求に応じてカーネルにロードおよびアンロードできるコードの一部です。これにより、システムを再起動する必要なく、カーネルの機能を拡張することができます。

カーネルモジュールを作成するには、The Linux Kernel Module Programming Guide を参照してください。モジュールは、ビルトインまたはロード可能として設定できます。モジュールを動的にロードまたは削除するには、カーネルの設定でそのモジュールをロード可能なモジュールとして設定する必要があります（そのモジュールに関連する行には M という文字が表示されます）。

新しいカーネルがインストールされるときにカーネルモジュールを自動的に再構築するには、Dynamic Kernel Module Support (DKMS) を参照してください。

情報を取得

モジュールは /usr/lib/modules/kernel_release に保存されます。uname -r コマンドを使うことで現在のカーネルのリリースバージョンを表示できます。

ノート: モジュール名にはよくアンダーバー (_) やダッシュ (-) が使われますが、modprobe コマンドと /etc/modprobe.d/ の設定ファイルではこの２つの記号は相互に置き換え可能です。

現在ロードされているカーネルモジュールを表示する:

$ lsmod

モジュールについての情報を表示する:

$ modinfo module_name

ロードされたモジュールに設定されたオプションを一覧する:

$ systool -v -m module_name

全てのモジュールの全ての設定を表示する:

$ modprobe -c | less

特定のモジュールの設定を表示する:

$ modprobe -c | grep module_name

モジュール自身を含む、モジュール（やエイリアス）の依存関係を一覧する:

$ modprobe --show-depends module_name

モジュールの自動ロード

今日、必要なモジュールのロードはすべて udev によって自動的に処理されます。したがって、ツリー外のカーネルモジュールを使用する必要がない場合は、ブート時にロードする必要のあるモジュールを設定ファイルに記述する必要はありません。ただし、ブートプロセスで追加のモジュールをロードしたり、コンピューターを正しく機能させるために他のモジュールをブラックリストに入れるなどのケースが考えられます。

systemd

カーネルモジュールを /etc/modules-load.d/ 配下のファイルに明示的にリストアップして、systemd が起動時にロードできるようにすることができます。各設定ファイルの名前の形式は /etc/modules-load.d/program.conf です。設定ファイルにはロードするカーネルモジュール名のリストが改行で区切られて含まれています。空行と最初の非空白文字が # または ; である行は無視されます。

/etc/modules-load.d/virtio-net.conf

# 起動時に virtio_net.ko をロード
virtio_net

詳しくは modules-load.d(5) を参照してください。

モジュールの早期ロード

initramfs イメージには、 /etc/modules-load.d/ で要求されたカーネルモジュールが含まれていない場合があります。また、そのフォルダに設定されているファイルが不足している場合もあります。モジュールの早期ロードは使用する initramfs ジェネレータに依存します。

• mkinitcpio: Mkinitcpio#MODULES を参照してください。
• dracut: Dracut#カーネルモジュールの早期ロード を参照してください。
• booster: Booster#モジュールの早期ロード を参照してください。

手動でモジュールを扱う

カーネルモジュールは kmod パッケージによって提供されるツールを使って管理します。これらのツールは手動で使用できます。

ノート: カーネルをアップグレードしたがまだ再起動していない場合、modprobe はエラーメッセージなしで失敗し、コード 1 で終了します、これはパス /usr/lib/modules/$(uname -r)/ がもう存在しないためです。modprobe が失敗したときにこのパスが存在するかどうか手動で確認してください。

モジュールをロードするには:

# modprobe module_name

ファイル名でモジュールをロードするには（つまり、/usr/lib/modules/$(uname -r)/ にインストールされていないモジュール）:

# insmod filename [args]

モジュールをアンロードするには:

# modprobe -r module_name

もしくは:

# rmmod module_name

モジュールオプションを設定する

カーネル モジュールにパラメータを渡すには、modprobe を使用してパラメータを手動で渡すか、modprobe 設定ファイルまたはカーネルコマンド ラインを使用して特定のパラメータが常に適用されるようにすることができます。モジュールがカーネルに組み込まれている場合は、カーネル コマンド ラインを使用する必要があり、他の方法は機能しません。

ロード時に modprobe を使って手動で行う

モジュールにパラメータを渡す基本的な方法は、modprobe コマンドを使用することです。パラメータはコマンドラインで単純な key=value の代入で指定します。

# modprobe module_name parameter_name=parameter_value

/etc/modprobe.d/ 内のファイルを使用する

/etc/modprobe.d/ ディレクトリ内のファイルは、udev にモジュール設定を渡すために使用できます。これにより、システムの起動時に modprobe を使用してモジュールのロードを管理します。このディレクトリ内の設定ファイルは、.conf 拡張子で終わる任意の名前を持つことができます。構文は次のとおりです:

/etc/modprobe.d/myfilename.conf

options module_name parameter_name=parameter_value

複数のモジュールパラメータはスペースで区切られ、パラメータにはカンマで区切られた値のリストを指定できます:

/etc/modprobe.d/myfilename.conf

options module_name param1=value1 param2=value2a,value2b …

例:

/etc/modprobe.d/thinkfan.conf

# ThinkPad では、'thinkfan' デーモンがファンの速度を制御できるようにします
options thinkpad_acpi fan_control=1

ノート: 影響を受けるモジュールが initramfs からロードされている場合、適切な .conf ファイルを mkinitcpio.conf の FILES に追加するか、modconf フック を使用してから、.conf ファイルを含めるために initramfs の再生成 を行う必要があります。デフォルトの initramfs の内容を確認するには、lsinitcpio を使用してください。

カーネルコマンドラインを使う

モジュールがカーネルに組み込まれている場合、モジュールにオプションを設定するのにカーネルコマンドラインを使うこともできます。一般的なブートローダでは次の構文を使って下さい:

modname.parametername=parametercontents

例:

thinkpad_acpi.fan_control=1

カーネルパラメータのページで説明されているようにして、あなたのブートローダのカーネルラインにこれを追加するだけです。

エイリアス

エイリアスによってモジュールに代わりの名前を付けることができます。例: alias my-mod really_long_modulename で modprobe really_long_modulename の代わりに modprobe my-mod を使うことができるようになります。シェルのようにワイルドカードを使うこともできます。alias my-mod* really_long_modulename で modprobe my-mod-something が modprobe really_long_modulename と同じ意味になります。エイリアスを作るには:

/etc/modprobe.d/myalias.conf

alias mymod really_long_module_name

モジュールによっては、アプリケーションがモジュールを必要としたときに自動でロードするためにエイリアスが設定されているものもあります。こういったエイリアスを無効化すると自動ロードも止まります。ただし手動でモジュールをロードすることはできます。

/etc/modprobe.d/modprobe.conf

# Prevent Bluetooth autoload

alias net-pf-31 off

ブラックリスト

カーネルモジュールで、ブラックリストとはカーネルモジュールをロードしないようにすることを指します。ブラックリストが役にたつのは、例えば、関連するハードウェアが必要ない場合や、モジュールをロードすると問題が発生する場合: 2つのカーネルモジュールが同じハードウェアをコントロールしようとして、互いにコンフリクトを生じる場合などです。

いくつかのモジュールは initramfs の一部としてロードされます。mkinitcpio -M ですべての自動検出したモジュールを表示します: initramfs のモジュールのロードを止めるには、/etc/modprobe.d/ 中に .conf ファイルを作成してモジュールをブラックリストに登録します。mkinitcpio -v を実行することで様々なフック（例: ファイルシステムフック、SCSI フックなど）によって使われている全てのモジュールを一覧できます。モジュールをブラックリスト入りさせたら、イメージを生成し、それから再起動してください。

ノート: modconf フック が有効になっていない場合は、/etc/mkinitcpio.conf の FILES セクションに使った .conf ファイルを追加する必要があります。

/etc/modprobe.d/ 内のファイルを使う

/etc/modprobe.d/ 内に .conf ファイルを作成し、blacklist キーワードを使って一行ずつブラックリスト入りさせたいモジュールを追加します。例えば pcspkr モジュールをロードさせたくない場合:

/etc/modprobe.d/nobeep.conf

# Do not load the 'pcspkr' module on boot

blacklist pcspkr

ノート: blacklist コマンドはモジュールをブラックリスト入りさせて自動でロードしないようにしますが、他のブラックリスト入りしてないモジュールによって必要になった場合、モジュールがロードされることがあります。また、手動でモジュールをロードすることも可能です。

しかしながら、この挙動を変えることが可能です; install コマンドを使って、modprobe に通常通りカーネルでモジュールを挿入する代わりにカスタムコマンドを実行させることで、いつでもモジュールのロードが失敗するように強制することができます:

/etc/modprobe.d/blacklist.conf

...
install module_name /bin/true
...

事実上の、モジュールとそれが必要な他のモジュールのブラックリスト化になります。

カーネルコマンドラインを使う

ヒント: 問題のあるモジュールによってシステムが起動できない場合、この方法が役に立つでしょう。

ブートローダでモジュールをブラックリスト入りさせることもできます。

カーネルパラメータのページで説明されているようにして、あなたのブートローダのカーネルラインに module_blacklist=modname1,modname2,modname3 を追加するだけです。

ノート: 複数のモジュールをブラックリスト入りさせるときは、カンマで分割することを覚えておいて下さい。スペースなどを使うとシンタックスを破壊してしまうおそれがあります。

トラブルシューティング

モジュールがロードされない

特定のモジュールがロードされない場合、起動ログ (journalctl -b で見れます) にモジュールがブラックリストに入っていると書かれているのに /etc/modprobe.d/ ディレクトリには該当するエントリが存在しないとき、/usr/lib/modprobe.d/ にある他の modprobe ソースファイルにブラックリストのエントリがないか確認してください。

カーネルモジュールに含まれている "vermagic" 文字列が、現在実行中のカーネルの値と一致しない場合もモジュールはロードされません。カーネルとモジュールの互換性に問題がないという確証があるときは modprobe --force-vermagic で "vermagic" のチェックを無視させることができます。

警告: カーネルモジュールのバージョンチェックを無視するとカーネルがクラッシュしたり、システムが予期しない挙動を見せる可能性があります。--force-vermagic を使うときは細心の注意を払ってください。

参照

• modprobe man ページ
• PC スピーカーのビープ音の無効化
• Writing a WMI driver - an LWM introduction