第3章 システムの初期化

目次

3.1. ブートストラッププロセスの概要
3.1.1. 1段目: BIOS
3.1.2. 2段目: ブートローダー
3.1.3. 3段目: ミニ Debian システム
3.1.4. 4段目: 通常の Debian システム
3.2. Systemd init
3.2.1. ホスト名
3.2.2. ファイルシステム
3.2.3. ネットワークインターフェースの初期化
3.2.4. カーネルメッセージ
3.2.5. システムメッセージ
3.2.6. systemd の下でのシステム管理
3.2.7. systemd のカスタム化
3.3. udev システム
3.3.1. カーネルモジュール初期化

Debian システムが以下に起動され設定されるかの知っていることはシステム管理者として賢明です。正確で詳細な情報がインストールされたパッケージのソースや文書中にあるとは言え、我々の大部分にとってはちょっと大変過ぎます。

著者などの過去の知見に基づき Debian システムの要点とそれらの設定の簡単な参考となる概論を提供するように勤めました。Debian システムは動く標的なので、システムの状況が変わっているかもしれません。システムに変更を加える前に、各パッケージの最新文書を参照下さい。

[ヒント] ヒント

systemd に準拠するシステムのブートアッププロセスは bootup(7) に詳述されている。 (最新の Debian)

[ヒント] ヒント

UNIX System V Release 4 に準拠するシステムのブートアッププロセスは boot(7) に詳述されている。 (過去の Debian)

コンピューターシステムは、電源投入イベントからユーザーに機能の完備したオペレーティングシステム (OS) を提供するまでブートストラッププロセスを数段通過します。

単純化のため、デフォールトのインストールをした典型的な PC プラットフォームに限定し議論します。

典型的なブートストラッププロセスは4段ロケットのようです。各段のロケットは次の段のロケットにシステムのコントロールを引き継ぎます。

もちろん、これらに関して異なる設定をすることはできます。例えば、自分自身で専用カーネルをコンパイルした場合、ミニ Debian システムのステップをスキップできます。自分自身で確認するまでは、あなたのシステムがこの様になっていると決めつけないで下さい。

[注記] 注記

非伝統的 PC プラットフォームの SUN とか Macintosh システム等では、ROM 上の BIOS やディスク上のパーティション (「ディスクパーティション設定」) が非常に異なっているかもしれません。そのような場合にはプラットフォーム特定の文書をどこかで求めて下さい。

BIOS は電源投入イベントが引き起こすブートプロセスの1段目です。CPU のプログラムカウンターが電源投入イベントで初期化され、読出し専用メモリー (ROM) 上にあるBIOS が特定のメモリーアドレスから実行されます。

BIOS はハードウエアーの基本的な初期化 (POST: 電源投入時自己診断) を行い、システムのコントロールをあなたが提供する次のステップにシステムのコントロールを引き継ぎます。BIOS は通常ハードウエアーによって供給されます。

BIOS 初期画面はどのキーを押すと BIOS 設定画面に入って BIOS の挙動を設定できるかを通常表示しています。よく使われるキーは F1 や F2 や F10 や Esc や Ins や Del です。もし BIOS 初期画面が洒落た画像表示で隠されている場合、Esc 等の何らかのキーをおすとこれを無効にできます。こういったキーはハードウエアーに大いに依存します。

BIOS が起動するコードのハードウエアー上の場所や優先順位は BIOS 設定画面から選択できます。典型的には最初に見つかった選択されたデバイス (ハードディスクやフロッピーディスクや CD-ROM 等) の最初の数セクターがメモリー上にロードされこの初期コードが実行されます。この初期コードは次のいずれでもよろしい。

  • ブートローダーコード

  • FreeDOS のような踏み石 OS のカーネルコード

  • この小さな空間に収まればターゲット OS のカーネルコード

典型的にはプライマリハードディスクの指定されたパーティションからシステムが起動されます。伝統的 PC のハードディスクの最初の2セクターにマスターブートレコード (MBR) が含まれます。ブート選択に含まれるディスクのパーティション情報はこの MBR の最後に記録されています。BIOS から実行される最初のブートローダーコードは残りの部分を占めます。

ブートローダーは BIOS によって起動されるブートプロセスの2段目です。それはシステムのカーネルイメージと initrd イメージをメモリーにロードし、それらにコントロールを引き継ぎます。この initrd イメージはルートファイルシステムイメージで、そのサポートは使われるブートローダー次第です。

Debian システムは通常 Linux カーネルをデフォールトのシステムカーネルとして使っています。現在の 2.6/3.x カーネルにとっての initrd イメージは技術的に言うなら initramfs (初期 RAM ファイルシステム) イメージです。基本的な initrd イメージはルートファイルシステム中の圧縮 cpio アーカイブです。カーネルはこの基本的な initrd イメージをロードする前の非常に初期のブート中に microcode をアップデートすることができます。非圧縮cpio フォーマット中のmicrocode のバイナリーブロッブと基本的な initrd イメージよりなる 組み合わせ initrd イメージを作成することを可能にします。

[ヒント] ヒント

initramfs-tools-core パッケージ中の lsinitramfs(8)unmkinitramfs(8) を用いると initrd イメージファイルの内容を検査できます。詳細は https://wiki.debian.org/initramfs を参照ください。

Debian システムのデフォールトインストールでは、GRUB ブートローダーの1段目のコードを PC プラットホームの MBR の中に置きます。多くのブートローダーと設定の選択肢が利用可能です。


[警告] 警告

grub-rescue-pc パッケージのイメージから作ったブート可能なレスキューメディア (CD かフロッピー) 無しにブートローダーを試してはいけません。これさえあると、ハードディスク上に機能するブートローダーが無くともシステムの起動ができます。

GRUB Legacy のメニューの設定は "/boot/grub/menu.lst" にあります。例えば、次のような内容です。

title           Debian GNU/Linux
root            (hd0,2)
kernel          /vmlinuz root=/dev/hda3 ro
initrd          /initrd.img

GRUB 2 のメニューの設定は "/boot/grub/grub.cfg" にあります。 "/etc/grub.d/*" の雛形と "/etc/default/grub" の設定から "/usr/sbin/update-grub" を使って自動的に作られます。例えば、次のような内容です。

menuentry "Debian GNU/Linux" {
        set root=(hd0,3)
        linux /vmlinuz root=/dev/hda3
        initrd /initrd.img
}

これらの例で、これらの GRUB パラメーターは次の意味です。


[注記] 注記

GRUB legacy プログラムが使うパーティション値は Linux カーネルやユーティリティーツールが使う値より1つ少ない数字です。GRUB 2 プログラムはこの問題を修正します。

[ヒント] ヒント

UUID (「UUID を使ってパーティションをアクセス」参照下さい) は、"/dev/hda3" のようなファイル名に代わるブロックの特定デバイスを確定するのに使え、例えば "root=UUID=81b289d5-4341-4003-9602-e254a17ac232 ro" です。

[ヒント] ヒント

もし GRUB が使われている場合には、カーネルブートパラメーターは /boot/grub/grub.cfg 中に設定されます。 Debian システム上では、/boot/grub/grub.cfg を直接編集するべきではありません。/etc/default/grub 中の GRUB_CMDLINE_LINUX_DEFAULT の値を編集するべきで、update-grub(8) を実行することで /boot/grub/grub.cfg を更新すべきです。

[ヒント] ヒント

チェインロード (連鎖導入) とよばれる技術を使うと、あるブートローダーから他のブートローダーを起動できます。

"info grub" と grub-install(8) を参照下さい。

ミニ Debian システムはブートローダーによって起動されるブートプロセスの3段目です。メモリー上でルートファイルシステムとともにシステムカーネルを実行します。これはオプションの起動プロセスの準備段階です。

[注記] 注記

"ミニ Debian システム" は著者がこの3段目のブートプロセスを本文書中で記述するために作った言葉です。このシステムは一般に initrd とか initramfs システムと呼ばれています。類似のメモリー上のシステムは Debian インストーラーでも使われています。

"/init" スクリプトはこのメモリー上のルートファイルシステムで最初に実行されるプログラムです。それはユーザー空間でカーネルを初期化し次の段階にコントロールを引き継ぐプログラムです。このミニ Debian システムは、メインのブートプロセスが始まる前にカーネルモジュールを追加したり、ルートファイルシステムを暗号化されたファイルシステムとしてマウントする等のブートプロセスの柔軟性を提供します。

  • initramfs-tools で initramfs が作成された場合には "/init" プログラムはシェルプログラムです。

    • "break=init" 等をカーネルブートパラメーターとして与えると、本部分のブートプロセスに割り込み root シェルを獲得できます。この他の割り込み条件は "/init" スクリプトを参照下さい。このシェル環境はあなたの機器のハードウエアーを詳細に検査できるだけ十分洗練されています。

    • このミニ Debian システムで利用可能なコマンドは機能を削ったコマンドで、主に busybox(1) という GNU ツールで提供されます。

  • dracut で initramfs が作成された場合には "/init" プログラムはバイナリーの systemd プログラムです。

    • このミニ Debian システムで利用可能なコマンドは機能を削った systemd(1) 環境です。

[注意] 注意

読出しのみのルートファイルシステム上では、mount コマンドには "-n" オプションを使う必要があります。

通常の Debian システムはミニ Debian システムによって起動されるブートプロセスの4段目です。ミニ Debian システムのシステムカーネルはこの環境ででも実行され続けます。ルートファイルシステムはメモリー上から本当にハードディスク上にあるファイルシステムに切り替えられます。

多くのプログラムを起動する主ブートプロセスを行う init プログラムは、PID=1 で最初のプログラムとして実行されます。init プログラムのデフォールトのファイルパスは "/sbin/init" ですが、"init=/path/to/init_program" のようなカーネルブートパラメーターにより変更できます。

デフォルトの init プログラムは変化してきています:

  • squeeze 以前の Debian は、単純な SysV-スタイル init を使用します。

  • wheezy の Debian は、LSB ヘッダーを用いブート順決めブートスクリプトを並列起動をする改良された SysV-スタイル init を使用します。

  • jessie の Debian は、イベントドリブンで並列初期化のために systemd にデフォルトの init を切り替えました。

[ヒント] ヒント

あなたのシステム上の実際の init コマンドは "ps --pid 1 -f" コマンドで確認できます。

[ヒント] ヒント

Debian jessie 以降 "/sbin/init" は "/lib/systemd/systemd" にシムリンクされています。

表3.3 Debian システムののブートユーティリティーのリスト

パッケージ ポプコン サイズ 説明
systemd V:750, I:858 13484 並行処理のためのイベント依存の init(8) デーモン (sysvinit 代替)
systemd-sysv V:733, I:852 122 systemdsysvinit を置換するのに必要な、マニュアルページとリンク
systemd-cron V:0, I:1 139 cron デーモンと anacron 機能を提供する systemd の unit。
init-system-helpers V:745, I:876 133 sysvinitsystemd 間を切り替える補助ツール
initscripts V:188, I:509 213 システムの始動と停止のためのスクリプト
sysvinit-core V:10, I:13 263 System-V 的な init(8) ユーティリティー
sysv-rc V:334, I:520 121 System-V 的なランレベル変更メカニズム
sysvinit-utils V:729, I:999 131 System-V 的なユーティリティー (startpar(8)bootlogd(8)、…)
lsb-base V:886, I:999 49 Linux Standard Base 3.2 の init スクリプト機能
insserv V:403, I:510 148 LSB init.d スクリプト依存関係を使いブート順序を整理するツール
uswsusp V:5, I:10 714 Linux が提供するユーザースペースソフトウエアーによるサスペンドを使うためのツール
kexec-tools V:1, I:7 271 kexec(8) リブートのための kexec ツール (ワームリブート)
systemd-bootchart V:0, I:0 123 ブートプロセスのパーフォンマンスアナライザー
bootchart2 V:0, I:1 94 ブートプロセスのパーフォンマンスアナライザー
pybootchartgui V:0, I:1 177 ブートプロセスのアナライザー (可視化)
mingetty V:0, I:3 35 コンソール専用 getty(8)
mgetty V:0, I:1 319 インテリジェントモデム用の代替 getty(8)

[ヒント] ヒント

ブートプロセスを高速化する最新のティップは Debian wiki: BootProcessSpeedup を参照下さい。

このセクションは PID=1 (詰まり、init プロセス)の systemd(1) プログラムがどのようにシステムを起動するのかを説明します。

systemd の init プロセスは、SysV 的な手続き定義スタイルではなく宣言定義スタイルで書かれた unit 設定ファイル(systemd.unit(5) 参照 )に従い並列で複数プロセスを起動します。これらは以下に記すような複数のパス (systemd-system.conf(5) 参照)から読み込まれます:

  • "/lib/systemd/system": OS のデフォルトの設定ファイル

  • "/etc/systemd/system": OS デフォルト設定ファイルをオーバーライドするシステム管理者設定ファイル

  • "/run/systemd/system": OS デフォルト設定ファイルをオーバーライドする実行時生成される設定ファイル

相互依存関係は "Wants="、"Requires="、"Before="、"After="、 … ("MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5) 参照) 等の指示定義によって規定される。リソースのコントロールは (systemd.resource-control(5) 参照)によっても定義される。

unit 設定ファイルのサッフィックスにそのタイプを折込みます:

  • *.servicesystemd がコントロールしたりスーパーバイズするプロセスを記述します。systemd.service(5) 参照ください。

  • *.devicesysfs(5) 中に udev(7) デバイスツリーとして暴露されるデバイスを記述します。See systemd.device(5) を参照ください。

  • *.mountsystemd がコントロールしたりスーパーバイズするファイルシステムのマウントポイントを 記述します。systemd.mount(5) を参照ください。

  • *.automountsystemd がコントロールしたりスーパーバイズするファイルシステムの自動マウントポイントを 記述します。systemd.automount(5) を参照ください。

  • *.swapsystemd がコントロールやスーパーバイズするスワップデバイスやファイルを 記述します。systemd.swap(5) を参照ください。

  • *.pathsystemd がパス基準で起動するために監視するパスを 記述します。systemd.path(5) を参照ください。

  • *.socketsystemd がソケット基準で起動するためにコントロールしたりスーパーバイズするソケットを 記述します。systemd.socket(5) を参照ください。

  • *.timersystemd がタイマー基準で起動するためにコントロールしたりスーパーバイズするタイマーを 記述します。systemd.timer(5) を参照ください。

  • *.slicecgroups(7) でリソースを管理します。systemd.slice(5) を参照ください。

  • *.scope はシステムプロセスの集合を systemd のバスインターフェースを用いて管理するためにプログラムで作られます。systemd.scope(5) を参照ください。

  • *.target は他の unit設定ファイルを組み合わせて始動時同期点を作ります。systemd.target(5) を参照ください。

システムの始動 (init) されると systemd プロセスは (通常 "graphical.target" にシムリンクされている) "/lib/systemd/system/default.target を起動しようとします。. 最初に、"local-fs.target" や "swap.target" や "cryptsetup.target" 等のいくつかの特殊ターゲット unit (systemd.special(7) 参照) が引き込まれファイルシステムをマウントします。そして、他のターゲット unit が、ターゲット unit の依存関係で引き込まれます。詳細に関しては bootup(7) を読んで下さい。

systemd はバックワードコンパティビリティー機能を提供します。"/etc/init.d/rc[0123456S].d/[KS]<name>" 中の、SysV-スタイルのブートスクリプトは依然として読み込まれ処理されますし、telinit(8) は systemd の unit 有効化要求に変換されます。

[注意] 注意

擬似実装された runlevel の 2 から 4 は、すべて同じ "multi-user.target" にシムリンクされます。

通常のディスクやネットワークのファイルシテムのマウントオプションは "/etc/fstab" で設定されます。fstab(5)「マウントオプションによるファイルシステムの最適化」を参照下さい。

暗号化されたファイルシステムの設定は "/etc/crypttab" で設定されます。crypttab(5) を参照ください。

mdadm(8) を用いるソフトウエアー RAID は "/etc/mdadm/mdadm.conf" で設定されます。mdadm.conf(5) を参照ください。

[警告] 警告

各ブートアップごとに、全てのファイルシステムをマウントした後で、"/tmp" と "/var/lock" と "/var/run" 中の一時ファイルはクリーンされます。

systemd は init システムを提供するのみならず、ジャーナルのロギングや、ログイン管理や、時間管理や、ネットワーク管理などの汎用システム管理機能を提供します。

systemd(1) はいくつかのコマンドで管理されます:

  • systemctl(1) コマンドは systemd システムとサービス管理をコントロールします (CLI)、

  • systemsdm(1) コマンドは systemd システムとサービス管理をコントロールします (GLI)、

  • journalctl(1) コマンドは systemd ジャーナルの内容照会をします、

  • loginctl(1) コマンドは systemd のログイン管理をコントロールします、

  • systemd-analyze(1) はシステムのブートアップの性能を解析します。

以下は典型的 systemd 管理コマンドの断片です。正確な意味は該当するマンページを参照ください。

表3.5 典型的な systemd 管理コマンド断片の例

操作 タイプ コマンド断片
GUIのサービスマネージャー GUI "systemadm" (systemd-ui パッケージ)
全ターゲットユニット設定をリスト Unit "systemctl list-units --type=target"
全サービスユニット設定をリスト Unit "systemctl list-units --type=service"
全ユニット設定タイプをリスト Unit "systemctl list-units --type=help"
メモリー中の全ソケット unit のリスト Unit "systemctl list-sockets"
メモリー中の全タイマー unit のリスト Unit "systemctl list-timers"
"$unit" 始動 Unit "systemctl start $unit"
"$unit" 停止 Unit "systemctl stop $unit"
サービス特定の設定の再ロード Unit "systemctl reload $unit"
"$unit" 停止と始動 Unit "systemctl restart $unit"
"$unit" 始動と、他全ての停止 Unit "systemctl isolate $unit"
"graphical" に切り替え(GUI システム) Unit "systemctl isolate graphical"
"multi-user" に切り替え(CLI システム) Unit "systemctl isolate multi-user"
"rescue" に切り替え(シングルユーザー CLI システム) Unit "systemctl isolate rescue"
"$unit" に kill 信号を送る Unit "systemctl kill $unit"
"$unit" サービスがアクティブかを確認 Unit "systemctl is-active $unit"
"$unit" サービスが失敗かを確認 Unit "systemctl is-failed $unit"
"$unit|$PID|device" の状態を確認 Unit "systemctl status $unit|$PID|$device"
"$unit|$job" の属性を表示 Unit "systemctl show $unit|$job"
失敗した "$unit" をリセット Unit "systemctl reset-failed $unit"
全ての unit サービスの依存関係をリスト Unit "systemctl list-dependencies --all"
システムにインストールされた unit ファイルをリスト Unit ファイル "systemctl list-unit-files"
"$unit" を有効にする(symlink 追加) Unit ファイル "systemctl enable $unit"
"$unit" を無効にする(symlink 削除) Unit ファイル "systemctl disable $unit"
"$unit" のマスクを外す("/dev/null" へのsymlink を削除) Unit ファイル "systemctl unmask $unit"
"$unit" にマスクをかける("/dev/null" へのsymlink を追加) Unit ファイル "systemctl mask $unit"
デフォールトのターゲット設定を取得 Unit ファイル "systemctl get-default"
"graphical" にデフォールトのターゲットを設定 (GUI システム) Unit ファイル "systemctl set-default graphical"
"multi-user" にデフォールトのターゲットを設定 (CLI システム) Unit ファイル "systemctl set-default multi-user"
ジョブ環境の表示 環境 "systemctl show-environment"
ジョブ環境 "variable"(変数)を "value(値)に設定する" 環境 "systemctl set-environment variable=value"
ジョブ環境 "variable" (変数)の設定を解除する 環境 "systemctl unset-environment variable"
全 unit ファイルとデーモンを再起動 ライフサイクル "systemctl daemon-reload"
システムをシャットダウンする システム "systemctl poweroff"
システムのシャットダウンと再起動 システム "systemctl reboot"
システムのサスペンド システム "systemctl suspend"
システムのハイバーネート システム "systemctl hibernate"
"$unit" のジョブのログを見る ジャーナル "journalctl -u $unit"
"$unit" のジョブのログを見る ("tail -f" スタイル) ジャーナル "journalctl -u $unit -f"
それぞれの初期化ステップにかかった時間を表示する 分析 "systemd-analyze time"
初期化にかかった時間を全ての unit に関してリストする 分析 "systemd-analyze blame"
読み込み "$unit" ファイル中のエラーを検出する。 分析 "systemd-analyze verify $unit"
cgroups(7) を用いてブートプロセスを追跡する Cgroup "systemd-cgls"
cgroups(7) を用いてブートプロセスを追跡する Cgroup "ps xawf -eo pid,user,cgroup,args"
cgroups(7) を用いてブートプロセスを追跡する Cgroup "/sys/fs/cgroup/systemd/" の下の sysfs を読む

ここで、上記の例の中の "$unit" は単一の unit 名 (.service.target といったサフィックスは任意) とか、多くの場合、現在メモリー中の全 unit の主名称に対して fnmatch(3) を用いて"*" や "?" や "[]" 等のシェルスタイルのグロブによる複数 unit 指定であっても良い。

上記例中のシステムの状態を変えるコマンドは必要な管理特権を獲得させるべく "sudo" を通常前置する。

"systemctl status $unit|$PID|$device" の出力は色付きドット ("●") を使い unit の状態が一目瞭然とされる。

  • 白い "●" は "活動停止" や "停止済み" の状態を示す。

  • 赤い "●" は "失敗発生" や "エラー発生" の状態を示す。

  • 緑の "●" は "活動中" や "再起動中" や "起動中" の状態を示す。

デフォルトのインストールでは、多くのネットワークサービス(6章ネットワークアプリケーション を参照) はブート時に systemd によってブート時に network.target の後に起動される。"sshd" も例外ではありません。カスタム化の例としてオンデマンド起動に "sshd" をかえましょう。

最初に、システムがインストールしたサービスの unit を無効化しましょう。

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

古典的 Unix サービスでは indetd スーパーサーバーによるによりオンデマンドでソケット有効化をしていました。systemd では、*.socket*.service unit 設定ファイルを等してこれと等価のことが できます。

聞くソケットを指定するには sshd.socket

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

sshd.socket に対応するサービスファイルの sshd@.service

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

そして、再ロードします。

 $ sudo systemctl daemon-reload

Linux カーネル 2.6以降 では、udev システムがハードウエアーの自動検出と初期化のメカニズムを提供します (udev(7) 参照下さい)。カーネルが各デバイスを発見すると、udev システムは sysfs ファイルシステム (「procfs と sysfs」参照下さい) からの情報を使いユーザープロセスを起動し、modprobe(8) プログラム (「カーネルモジュール初期化」参照下さい) を使ってそれをサポートする必要なカーネルモジュールをロードし、対応するデバイスノードを作成します。

[ヒント] ヒント

もし "/lib/modules/<kernel-version>/modules.dep" が何らかの理由で depmod(8) によって適正に生成されていなかった場合には、モジュールは udev システムによる期待にそってロードされないかもしれません。これを修正するには、"depmod -a" を実行します。

デバイスノード名は "/etc/udev/rules.d/" の中のファイルによって設定できます。現在のデフォールトのルールは、cd とネットワークデバイス以外は非静的なデバイス名となる動的生成名を作る傾向があります。cd やネットワークデバイスと同様のカスタムルールを追加することで USB メモリースティック等の他のデバイスにも静的なデバイス名を生成出来ます。"Writing udev rules" か "/usr/share/doc/udev/writing_udev_rules/index.html" を参照下さい。

udev システムは少々動くターゲットなので、詳細は他のドキュメントに譲り、ここでは最小限の記述に止めます。

[ヒント] ヒント

"/etc/fstab" 中のマウントルールでは、デバイス名が静的なデバイス名である必要がありません。"/dev/sda" 等のデバイス名ではなく UUID を使ってデバイスをマウントできます。「UUID を使ってパーティションをアクセス」を参照下さい。

modprobe(8) プログラムは、ユーザープロセスからカーネルモジュールを追加や削除することで実行中の Linux カーネルの設定を可能にします。udev システム (「udev システム」参照下さい) は、その起動を自動化しカーネルモジュールの初期化を補助します。

"/etc/modules" ファイル中にリストしてプリロードする必要のある (modules(5) 参照下さい) 次に記すような非ハードウエアーや特殊ハードウエアーのドライバーモジュールがあります。

modprobe(8) プログラムのための設定ファイルは、modprobe.conf(5) で説明されているように "/etc/modprobes.d/" ディレクトリーの下にあります。(あるカーネルモジュールが自動ロードされるのを避けるには、"/etc/modprobes.d/blacklist" ファイル中にブラックリストします。)

depmod(8) プログラムによって生成される "/lib/modules/<version>/modules.dep" ファイルは、modprobe(8) プログラムによって使われるモジュール依存関係を記述します。

[注記] 注記

ブート時に modprobe(8) を使ってのモジュールロードの問題に出会った場合には、"depmod -a" として "modules.dep" を再構築をするとこの様な問題が解消できるかもしれません。

modinfo(8) プログラムは Linux カーネルモジュールに関する情報を表示します。

lsmod(8) プログラムは "/proc/modules" の内容を読みやすい形式にして、どのカーネルモジュールが現在ロードされているかを表示します。

[ヒント] ヒント

あなたのシステム上の正確なハードウエアーを特定します。「ハードウエアーの識別」を参照下さい。

[ヒント] ヒント

ブート時に期待されるハードウエアー機能を有効となるように設定もできます。「ハードウエアー設定」を参照下さい。

[ヒント] ヒント

あなたのデバイスのサポートは、カーネルを再コンパイルすれば追加できます。「カーネル」を参照下さい。