web-dev-qa-db-ja.com

カーネルモジュールを1つだけビルドする方法（レシピ）

Linuxカーネルモジュールにバグがあり、ストックのUbuntu 14.04カーネルでエラーが発生します（クラッシュ）。

だからこそ、edit/patchそれだけのソースをシングルカーネルモジュールを追加して、デバッグ出力を追加します。問題のカーネルモジュールはmvsasであり、起動する必要はありません。そのため、initrdイメージを更新する必要はありません。

多くの情報を読んで（以下に示すように）、セットアップとビルドプロセスの混乱を見つけました。次の2つのレシピが必要です。

  1. ビルド環境を一度セットアップ/構成するには
  2. このカーネルモジュールのソースファイル（.cおよび.h）を編集し、その編集を新しいカーネルモジュール（.ko）に変換した後の手順

使用されているソースは次のとおりです。

14.04driverskernelcompilingsource-code
34
Pro Backup

カスタムモジュールを作成するレシピは、3つのセクションに分割する必要がある場合があります。

一度セットアップする

$ cd ~
$ apt-get source linux-source-3.13.0

Mvsas固有のドライバーソースファイルをコピーするのが面倒です。それらをすべて現在の作業ディレクトリにコピーするだけです。 apt-getの結果、ソースURIの欠落に関するエラーメッセージが表示される場合は、下部の注4を参照してください。

$ cd linux-3.13.0
$ make oldconfig
$ make prepare
$ make scripts

これにより、カーネルモジュールのビルドに必要なファイルがいくつか準備されます。

各カーネルバージョン

$ apt-get install linux-headers-$(uname -r)

これにより、ヘッダーとそのカーネルバージョンのUbuntuカーネル構成ファイルが/ lib/modulesにインストールされます。

$ cd ~/linux-3.13.0
$ cp -v /usr/src/linux-headers-$(uname -r)/Module.symvers .

これにより、insmodまたはmodprobeでモジュールをロードするときに、「no module_layoutのシンボルバージョンがありません」というメッセージが表示されなくなります。

$ mv -v /lib/modules/$(uname -r)/kernel/drivers/scsi/mvsas/mvsas.ko /lib/modules/$(uname -r)/kernel/drivers/scsi/mvsas/mvsas.ko.backup

これにより、元の（Ubuntuビルド）カーネルモジュールの名前が変更され、カスタムパッチが適用されたカーネルモジュールがロードされるようになります。

各編集

$ cd ~/linux-3.13.0/drivers/scsi/mvsas
$ nano mv_sas.h
$ nano mv_sas.c

これらは編集用です。

$ make -C /lib/modules/$(uname -r)/build M=$(pwd) modules

これにより、/lib/modules/$(uname -r)/に保存されているストックUbuntuディストリビューションのカーネル構成を使用して、カーネルモジュール.koファイルがコンパイルおよびビルドされます。

$ make -C /lib/modules/$(uname -r)/build M=$(pwd) modules_install

これにより、/lib/modules/$(uname -r)/extra/にカーネルモジュールがインストールされ、ディストリビューションカーネルモジュールファイルの名前を変更しなかった場合にディストリビューションモジュールが上書きされることはありません。このmvsasの場合、 depmod も実行されます。

$ lsmod | grep mvsas

これにより出力が発生する場合、mvsasモジュールは最初に（modprobe -r mvsas）でアンロードする必要があります。

$ Sudo modprobe -v mvsas

これにより、新しいカーネルモジュールがロードされます。

出力をチェックして、/lib/modules/.../extra/mvsas.koがロードされていることを確認します。

Modprobeエラー：挿入できませんでした

場合によっては、詳細なmodprobe出力でmodprobe: ERROR: could not insert 'xyz': Unknown symbol in module, or unknown parameter (see dmesg)が発生することがありますが、insmodがカーネルのデフォルトの場所からモジュールをロードしようとしていることがわかります。例えば：

# insmod /lib/modules/3.17.0-031700rc7-generic/kernel/drivers/scsi/pm8001/pm80xx.ko
modprobe: ERROR: could not insert 'pm80xx': Unknown symbol in module, or unknown parameter (see dmesg)

その場合、手動で depmod を実行し、モジュールを再度ロードする必要があります。

# depmod
# Sudo modprobe -v mvsas

ノート

  1. 結果の.koモジュールファイルは、Ubuntuによって配布された元のモジュールファイルよりもサイズがはるかに大きい（たとえば20倍）場合があります。その場合、make prepareステップは、カーネル構成ファイルをデバッグするLinux開発者を作成し、ソースディレクトリからビルドしている可能性があります。 -Cパラメーターは期待どおりに機能しない可能性があります。
  2. 私はmake modules_prepareやmake M=scripts/modのような他のコマンドのガイドを見てきましたが、この場合にはこれらが必要だとは思いません。
  3. -C /lib/modules/$(uname -r)/buildを-C /usr/src/linux-headers-$(uname -r)に置き換えることにより、Linux開発者のデバッグ構成を使用できます。
  4. デフォルト設定では、apt-get source linux-sourcesはエラーE: You must put some 'source' URIs in your sources.listを返します。この問題を修正するには、最初の/etc/apt/sources.list行のコメントを外す（先頭の#を削除する）ことにより、ファイルdeb-srcを変更できます。 Ubuntu 17.10の例：deb-src http://ie.archive.ubuntu.com/ubuntu/ artful main restricted。 Sudo apt-get updateを実行すると、コマンドはソースを配信します。 この質問 も参照してください。これを行うためのGUIメソッドも説明されています。
32
Pro Backup