Linuxにおけるdepmodチュートリアル：実践的な使い方、オプション、および例

Linux を扱ってカーネルに手を加えると、遅かれ早かれ次のような問題に遭遇します。 depmodとmodules.depファイルあなたはそれを見たことがあるかもしれません システムをアップグレードする外部ドライバをインストールするとき、または多くの人が経験するように、VirtualBox のようなプログラムがモジュールの読み込みを停止し、おなじみの「モジュールが見つかりません」というメッセージが表示されるとき。

この記事では、このコマンドが具体的にどのような動作をするのかを詳しく解説していきます。 Linuxにおけるdepmodの内部動作この解説では、depmod.dy設定ファイルの役割と、カーネルモジュールに関する問題を回避するために日常業務でどのように活用できるかを説明します。すべてスペイン語（スペイン発）で、分かりやすい例を用いて解説しており、端末の開き方を知っていること以外に前提条件はありません。

depmodとは何ですか？また、Linuxではどのような用途で使われますか？

コマンド depmodはユーザー空間ツールです これは、指定されたカーネルのすべてのモジュールを分析し、それらがエクスポートするシンボルと必要とするシンボルを識別します。この分析に基づいて、通常は依存関係ファイルと呼ばれるファイルを生成します。 modules.depシステムはこれを使用して、どのモジュールを他のモジュールより先にロードすべきかを判断します。

Linuxでは、カーネルモジュールは シンボルを介して他のモジュールにサービスを提供するコード内でマクロでマークされているもの EXPORT_SYMBOL別のモジュールがこれらのシンボルのいずれかを使用すると、最初のモジュールに依存するようになります。多数のロード可能なモジュールが存在する環境では、この依存関係ネットワークは適切に管理しないと非常に複雑になる可能性があります。

Depmodの使命は、説明するのは簡単だが、非常に重要である。 /lib/modules/ 内のモジュールツリーを走査する各モジュールがエクスポートするシンボルと必要とするシンボルを調べ、そこから依存関係リストを作成します。このようにして、別のツールが modprobe 特定のモジュールをロードしたい場合、最初にロードすべき他のモジュールを事前に把握できます。

プラス modules.dep、depmodもいくつかの「マップ」ファイルを生成します。 同じディレクトリにあり、ホットプラグインフラストラクチャと kmod ツールによってモジュールの動的ロードを管理するために使用されます (たとえば、USB デバイスを接続してシステムが決定する場合)。 どのドライバーをロードするか).

depmodコマンドの基本的な構文

このツールの最も簡単な使い方は、オプションなしで呼び出すことです。 実行中のカーネル用の modules.dep ファイルを生成しますマニュアルページによると、一般的な構文は以下のとおりです。

depmod

また、特定のモジュールを引数として指定して呼び出すこともできます。 depmod はこれらのモジュールのみを検査しますこの使用パターンはあまり一般的ではありません。なぜなら、通常は個々のモジュールだけでなく、モジュールツリー全体の依存関係を更新することが望ましいからです。

正式には、マニュアルページには次のような記述があります。

depmod
depmod

これらの変種では、 バージョンとはカーネルのバージョンを指します （たとえば 5.4.0-81-generic）モジュールディレクトリを解析する必要があります。何も指定しない場合、depmod はによって返されるバージョンを使用します。 uname -rつまり、その瞬間に実行されているカーネルのことです。

depmodの最も重要なパラメータとオプション

このコマンドには、動作を調整できるオプションがいくつかあります。これらの多くは、 コンパイル環境、カスタムカーネル、またはステージングエリア最も一般的に使用されているものを以下にまとめます。

オプション／パラメータ	説明
kernel_version	オプションのパラメータで、 依存関係が生成されるカーネルバージョン省略した場合、実行中のカーネルが使用されます。
-a, --all	これにより、depmodは依存関係情報を生成します。 インストールされているすべてのカーネルバージョンについてコマンドラインでファイル名が指定されていない場合、このモードはデフォルトで有効になります。
-A, --quick	クイックモード: depmod modules.depよりも新しいモジュールが存在するかどうかを確認してください。 何も存在しない場合は、何も再生成せずに終了します。これにより、モジュールが多いシステムでは時間を節約できます。
-b <basedir>, --basedir <basedir>	これにより、 モジュールが配置されている代替ベースディレクトリこれは、ステージング ディレクトリで作業している場合に非常に便利です。 /lib/modules/<versión>。 ザ basedir に書き込まれたパスから削除されます modules.depファイルは最終的な移動先へ移動する準備が整う。
-C <archivo o directorio>, --config	このオプションでは デフォルトの設定ファイルを置き換える （通常 /etc/depmod.conf またはディレクトリ /etc/depmod.d/ 最初のものが存在しない場合）。
-e, --errsyms	と組み合わせると -Fdepmod を作成します モジュールが必要とするが提供されていないシンボルのレポート 他のモジュールによっても、カーネル自体によっても行われない。
-F <System.map>, --filesyms	ファイルを指定できます System.mapはカーネルのコンパイル時に生成されます。これにより、depmod はカーネル内で既に解決されているシンボルを認識し、不足しているシンボルを正しく報告できるようになります。
-h, --help	コマンドの使用方法に関する簡単なヘルプメッセージを表示します。 処刑は終了した。.
-n, --dry-run	すべての計算を実行しますが 出力をコンソールに書き込む モジュールディレクトリにファイルを生成する代わりに、(stdout) に出力します。何も変更せずに depmod の動作を確認するのに非常に便利です。
-v, --verbose	詳細モード: depmod が画面に表示されます 各モジュールが依存するすべてのシンボル そして、それらを提供するモジュールの名前。
-V, --version	を表示します depmodプログラムのバージョン そして、それは機能します。ただし、非常に古いカーネルでは、ドキュメント自体が警告しているように、追加の考慮事項が必要になる場合があります。

オプションに加えて、モジュールファイル名を引数として渡す場合は、 depmod は、それらを検査することに限定されています。 選択したカーネルバージョンに対応するモジュールディレクトリのすべてのコンテンツを処理する代わりに。

実践例：depmodでモジュールの問題を解決する方法（VirtualBoxの例）

depmod の有用性を示す非常に代表的な例として、 カーネルモジュールが「不足している」ため、VirtualBoxが動作しなくなります。実際の状況を想像してみてください。カーネルのアップデートまたは再コンパイルの後、 バーチャルマシンVirtualBoxはモジュールをロードできないと警告します vboxdrv またはその他の関連モジュール。

このような場合、次のようなエラーメッセージが表示されるのが一般的です。 System.map および特定のモジュールの欠如 想定されるパスにあります。たとえば、ファイルが System.map depmod やシステムツールが期待する場所に存在しません (たとえば、 /usr/src/linux）存在するが、 /boot.

ArchフォーラムやGentoo環境などの技術フォーラムで広く議論されている解決策は、通常、単純な sudo depmod -a 強制的に再生させる ファイルから modules.dep 使用しているカーネルバージョンの。その手順の後、モジュールを手動でロードしてみてください。 modprobe vboxdrv そして、すべてが正常であれば、エラーは消えます。

このコマンドが実際に行っていることは、そのカーネルで使用可能なすべてのモジュールを再走査することです。 エクスポートされたシンボルと必要なシンボルのマップを再計算する また、modprobe を含む他のツールで使用される依存関係ファイルとマップファイルを更新します。 modules.dep修正されました。

実際には、依存関係を再生成せずにモジュール（VirtualBox からのものなど）をインストール、再コンパイル、または移動した場合、 depmod「順序を付ける」 そうすれば、システムは誰が誰に依存しているか、何が何より先にロードされるべきかを再び認識できるようになります。

depmodがmodules.depファイルやその他のマップファイルを生成する方法

もう少し詳しく説明すると、depmod は、以下のすべてのモジュールを分析することによって機能します。 /lib/modules/<versión> または設定されているディレクトリ各モジュールについて、どのシンボルをエクスポートするか（つまり、他のモジュールにどの関数や変数を提供するか）と、機能するために必要なシンボルを検査します。

この情報に基づいて、depmod は modules.depファイル内の依存関係のリスト同じモジュールディレクトリに配置されています。ファイルの各行は、モジュールとそれが依存するモジュールを示しており、これは次のようなツールの基礎となります。 modprobe モジュールを正しい順序でロードする場合。

このツールは生成も担当しています ホットプラグインフラストラクチャ用のその他のマップファイル そして、モジュール管理システム全般にとっても重要です。一般ユーザーが直接編集することは通常ありませんが、新しいハードウェアが検出された際にモジュールの自動読み込みが正しく機能するためには不可欠です。

depmod呼び出しでaが指定されている場合 特定のカーネルバージョン、そのバージョンに対応するディレクトリが、によって報告された現在のバージョンの代わりに使用されます。 uname -rこれは、例えばクロスコンパイル環境やchroot環境など、まだ実行していないカーネル用のモジュールを準備する場合に役立ちます。

より高度なシナリオでは、このオプションも使用されます -F System.map カーネルシンボルマップを提供する これはコンパイル中に生成されたものです。これにより、depmod はカーネル自体によって解決されるシンボルと外部モジュールによって提供されるべきシンボルを区別し、オプションを使用してより正確な警告を発行できます。 -e.

depmod.dy 設定ディレクトリ、優先度設定

depmod はコマンド自体に加えて、 depmod.dy ディレクトリ、可能性のある depmod.conf ファイルこの設定により、モジュールの処理順序を変更したり、複数のバージョンのモジュールが存在する場合に、どのバージョンを優先的に処理するかを定義したりできます。

ドキュメントによると、depmod は以下のパスから設定を読み取ります。

• /usr/lib/depmod.d/*.conf
• /etc/depmod.d/*.conf
• /run/depmod.d/*.conf

これらのパスの下にあるファイルは、 シンプルなテキスト形式で、1行に1つの指示を記述します。空白行は許可されており、 # これらはコメントとして扱われます。行が \指示は次の行に続きます。これは、長い設定をより整理しやすくするのに役立ちます。

これらのファイル内では、主に2種類のコマンドを使用できます。 search y overrideどちらも、どのモジュールを先に処理するか、後に処理するか、そして競合が発生した場合にどのバージョンを優先するかを制御する役割を果たします。

depmod.d の検索コマンド: モジュールの処理順序

コマンド search depmod.d 内で定義するために使用されます /lib/modules のサブディレクトリはどのような順序で処理されますか？ depmod がシステムを分析する際、（または別の構成済みモジュールの場所）

一般的な構文は次のようになります。

search subdirectorio1 subdirectorio2 ...

ディレクトリは優先順位の高い順から低い順に並んでいます。 最初のものが最も優先順位が高く、最後のものが最も優先順位が低い。さらに、特別なキーワードがあります。 built-inこれは、カーネルによってインストールされる標準モジュールディレクトリを指します。

デフォルトでは、depmod はサブディレクトリに優先順位を付けます。 updates 統合モジュールに関して内部的に検索文字列を使用する "updates built-in"これにより、モジュールの更新バージョンをインストールできます。 updatesは、カーネルにデフォルトで付属しているものよりも優先して使用されることが望ましい。

より複雑な構成では search 多くのディストリビューションで共通のレイアウトを設定できます。 カスタムモジュールまたはサードパーティ製モジュールは、特定のパスに配置されます。 それによって、カーネルから供給されるものよりも優先され、カーネル自体には手を加えない。

depmod.d のオーバーライドコマンド: モジュールの特定のバージョンを選択する

depmod.d のもう 1 つの重要なコマンドは override、のために設計されています 同じ名前のモジュールが複数存在する場合に、どのバージョンを使用するかを選択するこれは、カーネルに付属するモジュールに加えて、カスタム版または実験版のモジュールもインストールされている場合によく発生します。

一般的な構文は次のとおりです。

override modulename kernelversion modulesubdirectory

この命令では、パラメータ modulename 優先したいモジュールを特定します。 kernelversion 特定のバージョンでもワイルドカードでも構いません。* （すべてのカーネルに適用するため）、そして modulesubdirectory サブディレクトリ内 /lib/modules （または別のモジュールパス）「勝者」バージョンが配置されている場所。

典型的な例としては、次のようなものがあります。

override kmod * extra

この行は、どのカーネルバージョンでも、 extraサブディレクトリにkmodという名前のモジュールがある場合そのバージョンは、カーネルに付属している、または他の標準ディレクトリにある同名のバージョンよりも優先されます。

これらのルールは、テストしたい場合に特に役立ちます カスタムドライバーまたは試用版 システムのオリジナルバージョンを削除せずに、設定を調整または削除するだけで簡単に元に戻せるようにする override.

内部動作と他のツール（modprobe、kmod、hotplug）との関係

depmod は単独では動作せず、エコシステムの一部です。 Linuxモジュール管理ツール（kmod）彼の仕事は、次のようなコマンドに直接反映されています。 modprobe あるいは、システムが新しいハードウェアを検出した際に、モジュールを自動的にロードする方法など。

あなたが走るとき modprobe nombre_moduloこのツールは modules.depおよびdepmodによって生成されたその他のファイルの内容 依存関係を満たすためにプリロードする必要のあるモジュールを特定します。これらのファイルが古かったり破損していたり​​すると、modprobe は未解決のシンボルエラーや見つからないモジュールなどのエラーで失敗する可能性があります。

ホットプラグインフラストラクチャもこれらの依存関係に依存しています。デバイスを接続したり、カーネルが新しいコンポーネントを検出したりすると、 udevシステムと関連ツールは、どのモジュールをロードするかを尋ねます。そして、その答えは主にdepmodの作業から作成されたテーブルに依存します。

さらに、これらすべてがプロジェクトに統合されています。 kmodは、ユーザー空間ツールを提供する。 モジュールを管理するため。depmod.d のマニュアルには、このドキュメントのこの部分は kmod プロジェクトの一部であり、エラーや改善点が見つかった場合は、Linux モジュール専用のメーリングリストに報告できることが示されています。

この統合のおかげで、多くの場合、depmod が自動的に実行されます。 新しいカーネルをインストールした後、またはモジュールを追加するパッケージをインストールしたときにしかし、ご覧いただいたように、通常のパッケージサイクル外で問題や変更が発生した場合は、手動で実行することが依然として非常に役立ちます。

depmodの使用例

理論をさらに明確にするために、最も単純なものからやや高度な環境まで、実際の状況でdepmodがどのように使用されているかの例をいくつか見てみる価値がある。

実行中のカーネルの依存関係を生成する

最も一般的なケースは、以下のコマンドで現在のカーネル依存関係を強制的に更新することです。

sudo depmod

バージョンが指定されていないため、depmodは返されたバージョンを使用します。 uname -r そして、modules.depとマップを更新します。 そのカーネルの場合。明示的に使用することもできます。

sudo depmod -a

選択 -a これは「すべてのモジュールを処理する」という意味であり、depmodはこの動作を採用しています。 ファイル名が指定されていない場合多くのチュートリアルでは、このコマンドはモジュールが読み込まれない問題の解決策としてよく紹介されています。

特定のカーネルバージョンの依存関係を生成する

カーネルが複数インストールされている場合、またはカーネル用のモジュールを準備している場合は、 まだ始まっていないdepmodにどのバージョンを使用するかを指定できます。

sudo depmod 5.4.0-81-generic

これにより、コマンドは /lib/modules/5.4.0-81-generic そして、そこにmodules.depファイルが生成されます。 また、その時点で実行中のカーネルのマップには手を加えずに、他のマップも変更します。

インストールされているすべてのカーネルの依存関係を再生成します。

セキュリティ上の理由から古いバージョンを維持しているサーバーなど、複数のカーネルが共存するシステムでは、 すべてのバージョンで強制的な依存関係の再生成を実行します。 1 つのコマンドで:

sudo depmod -a

この文脈では、depmod は、以下のさまざまなバージョンを実行します。 /lib/modules およびアップデート それぞれのモジュールの依存関係モジュールの更新や変更の適用後も、すべてが一貫性を保つようにする。

ステージングディレクトリと –basedir オプションと組み合わせて使用​​します。

カスタムカーネルやビルド環境を扱う場合、 一時ディレクトリ内のモジュール とは違う /lib/modulesその状況では、オプションを使用できます -b o --basedir:

depmod -b /ruta/al/staging 5.4.0-81-generic

これにより、depmod は /ruta/al/staging/lib/modules/5.4.0-81-generic 作業ディレクトリのように、しかし生成時には modules.depはbasedir部分を削除します パスが保存されるため、後でファイルを再生成することなく、標準パスに移動できます。

System.map を使用して未解決のシンボルをチェックする

開発環境やモジュールの詳細なデバッグでは、depmod の使用は非常に役立ちます。 未解決シンボルを検出する オプションを組み合わせる -F y -e:

depmod -F /boot/System.map-5.4.0-81-generic -e 5.4.0-81-generic

この場合は、ファイルが提供されます。 System.map カーネルのコンパイル時に生成され、depmod を可能にする コアで既に定義しておくべきシンボルを特定する。 オプション付き -eこのコマンドは、モジュールが必要とするシンボルのうち、カーネルや他のモジュールに存在しないシンボルを報告します。これは通常、コンパイル、バージョン、または構成の問題を示しています。

これらの「孤立した」シンボルが検出されると、何かがおかしいという非常に明確な手がかりになります。 コンパイルに使用されるカーネル、インストール済みモジュール、およびヘッダーこのような状況では、System.mapとdepmodの詳細な出力を確認することで、多くの時間を節約できます。

これらを総合すると、depmodはLinuxにおけるモジュール管理の基本的な要素となる。 それがなければ、システムはモジュール間の依存関係の全体像を失ってしまうだろう。 また、modprobeのようなツールやホットプラグのインフラストラクチャ自体も正しく動作しなくなります。その動作原理、depmod.dを使った設定方法、そして手動で実行すべきタイミングを理解することで、ドライバやカーネルモジュールの問題をより迅速かつ安全に診断・トラブルシューティングできるという大きなメリットが得られます。