Linuxカーネルは、CPUやメモリ、ストレージ、ネットワークなどのハードウェアリソースを抽象化し、プロセスへ提供するOSの中核ソフトウェアです。LinuC 201試験の主題2.01では、カーネルイメージの構成からロード可能モジュール（LKM）の管理、/proc/sysやsysctlによる動的パラメータ調整、さらにudevやdmesgを駆使したハードウェアトラブルシューティングまで、運用現場で必須となる中核技術が幅広く問われます。
- カーネルイメージ（vmlinuz）と初期RAMディスク（initramfs）の役割およびビルド工程を理解する
- modprobe、lsmod、modinfo、depmodを用いたカーネルモジュールの依存関係解決と設定変更を実行できる
- /proc/sysとsysctlコマンドの関係を把握し、カーネルパラメータの動的変更と設定永続化を構成できる
- udevの仕組みとudevadmコマンド、カーネルログ（dmesg/journalctl）を用いた障害切り分け手順を習得する
| 項目 | 設定値 |
|---|---|
| ホスト名 | linuc-node01 |
| IPアドレス | 192.168.2.138 |
| ディストリビューション | AlmaLinux release 9.8 (Seafoam Green) |
| カーネルバージョン | Linux 5.14.0-687.42.1.el9_8.x86_64 |
| 公式試験の必須出題範囲 | 主題2.01.3〜2.01.5（カーネル構成要素・コンパイル概念・実行時モジュール管理とsysctl・udev） |
|---|---|
| 現場で役立つ実務拡張 | dummyモジュールを用いた安全なパラメータ動的変更検証、dmesgログとudevadmによるハードウェア障害解析 |
目次
1. Linuxカーネルの構造とイメージファイル
Linuxは「モノリシックカーネル」アーキテクチャを採用しています。すべての主要なOS機能（スケジューラ、メモリ管理、ファイルシステム、ネットワークスタック）が単一のアドレス空間（カーネル空間）で動作します。ただし、あらゆるハードウェアのドライバを1つの巨大なバイナリに組み込むと、メモリ使用量の肥大化や起動時間の悪化を招きます。そこで現代のLinuxでは、必要な機能やデバイスドライバを実行時に動的追加・削除できる「ロード可能カーネルモジュール（LKM: Loadable Kernel Module）」の仕組みを組み合わせて運用します。
1.1 カーネルイメージと初期RAMディスクの構成
システム起動時にブートローダ（GRUB2）から読み込まれるカーネル関連ファイルは、通常/bootディレクトリ配下に格納されています。
$ ls -lh /boot/vmlinuz* /boot/initramfs*
-rw-------. 1 root root 38M 9月 6 10:26 /boot/initramfs-5.14.0-687.42.1.el9_8.x86_64.img
-rw-------. 1 root root 38M 9月 6 11:32 /boot/initramfs-5.14.0-687.42.1.el9_8.x86_64kdump.img
-rwxr-xr-x. 1 root root 15M 8月 28 01:07 /boot/vmlinuz-5.14.0-687.42.1.el9_8.x86_64| ファイル名 | 形式・種別 | 主な役割 |
|---|---|---|
| vmlinuz | 実行可能バイナリ（bzImage形式） | gzipやxzなどで圧縮されたLinuxカーネル本体。先頭に展開用ルーチンが含まれ、メモリ上に自らを解凍して起動します。名称の「z」は圧縮（compressed）を意味します。 |
| initramfs | 圧縮アーカイブ（cpio形式） | ルートファイルシステム（/）をマウントするために必要な最小限のドライバ（ストレージコントローラ、ファイルシステム等）を収めた一時的なメモリファイルシステムです。 |
| System.map | プレーンテキスト | カーネルの関数名や変数名と、メモリ上の物理アドレスの対応表（シンボルテーブル）です。カーネルパニック時のデバッグやクラッシュダンプ解析で参照されます。 |
1.2 カーネルのコンパイル手順とDKMS
ディストリビューション提供の標準カーネルではなく、特定の最適化やパッチ適用を目的にカーネルを手動ビルドする場合、カーネルソースツリー（通常/usr/src/kernels/や任意の作業ディレクトリ）上で以下のコマンドを順番に実行します。
| 実行コマンド | 処理内容 |
|---|---|
make menuconfig（またはxconfig, gconfig） |
カーネル設定ファイル（.config）を作成・編集する対話型設定画面を起動します。ncursesライブラリを使用します。 |
make |
カーネル本体（vmlinuz）およびカーネルモジュールを一括コンパイルします。 |
make modules_install |
コンパイルされたカーネルモジュール（.koファイル群）を/lib/modules/<カーネルバージョン>/配下に配置します。 |
make install |
カーネル本体（vmlinuz）とinitramfsを/bootに配置し、GRUB2の設定ファイルを更新します。 |
サードパーティ製のデバイスドライバ（NVIDIA GPUドライバや独自ストレージドライバなど）を運用する場合、カーネルをバージョンアップするたびに手動でドライバを再コンパイルする作業は運用の大きな負担となります。この問題を解決する仕組みがDKMS（Dynamic Kernel Module Support）です。DKMSを導入しておくと、カーネルパッケージがアップデートされた際に、パッケージマネージャのフック機構経由で自動的に新しいカーネル用のモジュールが再コンパイルされ、稼働環境へ配置されます。
2. カーネルモジュールの管理と依存関係解決
カーネルモジュール（拡張子.koまたは圧縮された.ko.xz）は、カーネルが動作している最中にメモリへ動的にロードしたり、不要になった際に安全にアンロードしたりできる部品です。
2.1 モジュール状態の確認（lsmod と modinfo）
システムで現在ロードされているカーネルモジュールの一覧を確認するには、lsmodコマンドを実行します。
$ lsmod | head -n 8
Module Size Used by
msdos 16384 0
ext4 1163264 0
mbcache 16384 1 ext4
jbd2 208896 1 ext4
rfkill 40960 1
nft_fib_inet 12288 1
nft_fib_ipv4 12288 1 nft_fib_inetlsmodコマンドは、カーネルの仮想ファイル/proc/modulesの内容を整形して出力しています。出力列の意味は以下の通りです。
- Module：モジュール名
- Size：モジュールがメモリ上で占有しているサイズ（バイト単位）
- Used by：参照カウント（使用中のプロセスや他のモジュールの数）と、このモジュールに依存しているモジュール名
特定のモジュールについて、ファイルパス、ライセンス、作成者、依存関係、受け付ける引数（パラメータ）を調べるにはmodinfoコマンドを使用します。対象モジュールがロードされていなくても、モジュール名またはファイルパスを指定して情報を取得できます。
$ modinfo dummy
filename: /lib/modules/5.14.0-687.42.1.el9_8.x86_64/kernel/drivers/net/dummy.ko.xz
alias: rtnl-link-dummy
license: GPL
rhelversion: 9.8
srcversion: 1463FDCAF9560EF809AB785
depends:
retpoline: Y
intree: Y
name: dummy
vermagic: 5.14.0-687.42.1.el9_8.x86_64 SMP preempt mod_unload modversions
parm: numdummies:Number of dummy pseudo devices (int)末尾のparm:フィールドから、このdummyモジュールがnumdummiesという整数値パラメータ（作成するダミー仮想インターフェースの数）を受け付けることが確認できます。
2.2 modprobe と低水準コマンド（insmod / rmmod）の比較
カーネルモジュールのロードとアンロードには、高水準コマンドであるmodprobeと、低水準コマンドであるinsmod / rmmodが存在します。両者の最大の違いは「モジュール間の依存関係を自動的に解決するか否か」にあります。
| 項目 | modprobe | insmod / rmmod |
|---|---|---|
| 引数の指定方法 | モジュール名（例: dummy） |
モジュールファイルの絶対パスまたは相対パス（例: /path/to/dummy.ko） |
| 依存関係の解決 | 自動解決する（依存する親モジュールも自動ロード） | 解決しない（未ロードの依存先があると即座にエラー停止） |
| 設定ファイルの適用 | /etc/modprobe.d/*.confの設定（オプションやエイリアス）を自動反映 |
設定ファイルを一切読み込まない |
| アンロード操作 | modprobe -r <モジュール名>（依存されなくなった親モジュールも連動解除） |
rmmod <モジュール名>（1つずつ手動指定が必要） |
たとえば、実機でファイルシステムのext4モジュールの依存関係を調べると、mbcacheとjbd2に依存していることがわかります。
$ grep -E "ext4\.ko" /lib/modules/$(uname -r)/modules.dep
kernel/fs/ext4/ext4.ko.xz: kernel/fs/mbcache.ko.xz kernel/fs/jbd2/jbd2.ko.xzもしmbcacheやjbd2がロードされていない状態でinsmod ext4.ko.xzを実行すると、シンボル未解決エラーとなりロードに失敗します。一方、modprobe ext4を実行すると、modprobeは依存関係を先読みしてjbd2とmbcacheを順にロードした上で、最後にext4をロードします。運用現場および試験対策において、手動ロードには原則としてmodprobeを使用します。
2.3 依存関係データベースの更新（depmod）
modprobeがモジュール間の依存関係を把握できるのは、カーネルバージョンごとの依存関係定義ファイル/lib/modules/<カーネルバージョン>/modules.dep（およびバイナリ版のmodules.dep.bin）を参照しているためです。
新しいカーネルモジュールを手動でコンパイル・配置した場合、このファイルを最新化しなければmodprobeは新モジュールを認識できません。依存関係データベースを再生成するコマンドがdepmodです。
# 現在稼働中のカーネル向けに依存関係ファイルを再生成
$ sudo depmod -a
# 特定バージョンのカーネル向けに再生成
$ sudo depmod -a 5.14.0-687.42.1.el9_8.x86_642.4 モジュール設定ファイル（/etc/modprobe.d/）
モジュールをロードする際のオプション指定、別名（エイリアス）定義、あるいは特定の脆弱なモジュールや不要なモジュールの読み込みを禁止するブラックリスト設定は、/etc/modprobe.d/ディレクトリ配下の設定ファイル（拡張子.conf）に記述します。
| ディレクティブ | 書式例 | 動作説明 |
|---|---|---|
| options | options dummy numdummies=4 |
対象モジュールがmodprobeでロードされる際に渡すデフォルト引数を指定します。 |
| alias | alias eth0 dummy |
モジュールに別名（エイリアス）を付与します。 |
| blacklist | blacklist nouveau |
他のハードウェア検出等による自動ロードから除外します（手動の明示的ロードは拒絶されません）。 |
| install | install usb-storage /bin/true |
モジュールのロード要求が発生した際、実際のロード処理の代わりに指定したシェルコマンドを実行します。ロードを完全に無効化するセキュリティ対策として多用されます。 |
3. カーネルパラメータの動的変更と永続化（/proc/sys と sysctl）
稼働中のLinuxカーネルの挙動（ネットワークスタックのバッファサイズ、パケット転送の可否、仮想メモリの解放タイミングなど）は、カーネルを再起動することなくリアルタイムに変更できます。この制御を担うのが/proc/sys仮想ファイルシステムとsysctlコマンドです。
3.1 procfsの構造とドット記法の対応関係
/procはディスク上に実体を持たず、カーネルの内部データ構造をファイルツリーとして見せる仮想ファイルシステム（procfs）です。その中でも/proc/sys配下のファイル群は、カーネルパラメータを直接読み書きできるインターフェースとなっています。
sysctlコマンドで扱うドット区切りのパラメータ名と、/proc/sys/配下のファイルパスは1対1で対応しています。ディレクトリの区切り文字「/」が、パラメータ名の「.」に置換されます。
| sysctlパラメータ名 | 対応するprocfsファイルパス | パラメータの意味 |
|---|---|---|
net.ipv4.ip_forward |
/proc/sys/net/ipv4/ip_forward |
IPv4パケットフォワーディング（ルーター機能）の有効/無効（0=無効, 1=有効） |
net.ipv4.icmp_echo_ignore_all |
/proc/sys/net/ipv4/icmp_echo_ignore_all |
外部からのICMP Echo Request（ping）をすべて無視するか（0=応答, 1=無視） |
vm.swappiness |
/proc/sys/vm/swappiness |
スワップ領域を使用する積極性の度合い（0〜100、値が大きいほど積極的にスワップアウト） |
fs.file-max |
/proc/sys/fs/file-max |
システム全体で同時にオープン可能な最大ファイルディスクリプタ数 |
# procfsからの直接読み取り
$ cat /proc/sys/net/ipv4/ip_forward
0
# sysctlコマンド経由での読み取り
$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 03.2 sysctlコマンドによる動的変更
カーネルパラメータを一時的に変更する場合、以下の2つの手法が存在します。どちらの手法を用いても、カーネルのメモリ上の値が即座に書き換わります。
-
sysctl -w コマンドによる書き込み
sysctl -w <パラメータ>=<値>を実行します。変更前の確認と実行が平易に行えます。$ sudo sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1 -
/proc/sys への直接リダイレクト
シェル経由で対象ファイルへ直接数値をechoします。
$ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
3.3 パラメータ設定の恒久化（/etc/sysctl.d/ と sysctl -p / –system）
再起動後もカーネルパラメータの設定を維持するには、設定ファイルにパラメータを記述します。現代のLinuxシステムでは、/etc/sysctl.d/配下に.confファイルを配置する運用が標準です。
# 設定ファイルを作成
$ sudo vi /etc/sysctl.d/99-custom-network.conf
# 記述内容
net.ipv4.ip_forward = 1
net.ipv4.icmp_echo_ignore_all = 1作成した設定ファイルの内容を再起動せずに即座にカーネルへ反映させるには、以下のコマンドを実行します。
# 特定の設定ファイルを指定して反映
$ sudo sysctl -p /etc/sysctl.d/99-custom-network.conf
# システム全体の全設定ファイル（/usr/lib/sysctl.d, /etc/sysctl.d等）を優先順位に従い再ロード
$ sudo sysctl --system引数なしでsysctl -pを実行した場合、デフォルトでは/etc/sysctl.confのみが読み込まれます。ディストリビューションごとの設定ファイル読み込み順序と優先順位（システム標準の/usr/lib/sysctl.d/よりも管理者用の/etc/sysctl.d/が優先される）を理解しておくことが重要です。
4. ハードウェア検出とトラブルシューティング（udev・dmesg）
サーバーに新しいストレージ（NVMe SSDやSCSI HDD）、NIC、USBデバイスを接続した際、カーネルはデバイスを検出し、デバイスファイルを自動生成します。この動的デバイスノード管理を担う仕組みがudevです。
4.1 udevの仕組みとルールファイル
従来の静的な/dev運用とは異なり、現代のLinuxではsysfs（/sys配下に展開されるハードウェア詳細情報ツリー）とdevtmpfs（/dev配下の仮想メモリファイルシステム）が連携し、udevデーモン（systemd-udevd）が動的にデバイスノードを生成・管理します。
| 配置ディレクトリ | 用途・優先順位 |
|---|---|
/etc/udev/rules.d/*.rules |
管理者設定用（最優先で評価）。カスタムのシンボリックリンク作成やパーミッション変更を定義します。 |
/run/udev/rules.d/*.rules |
ランタイム一時設定（2番目に評価）。再起動で破棄されます。 |
/usr/lib/udev/rules.d/*.rules |
OSパッケージ標準設定（最も低い優先順位）。パッケージマネージャが提供する初期ルール群です。 |
同名のルールファイルが複数のディレクトリに存在する場合、上位のディレクトリに配置されたファイルが下位のファイルを上書き（オーバーライド）します。
4.2 udevadmコマンドによるデバイス調査とルール適用
udevのトラブルシューティングやルール作成時に活用するのがudevadmコマンドです。試験および実務で頻出する主要サブコマンドは以下の通りです。
| サブコマンド | 構文例 | 実行目的 |
|---|---|---|
| info | udevadm info -q all -n /dev/sda |
指定したデバイスノードのudevデータベース情報やパス（P:）、属性（E:）を出力します。 |
| info -a | udevadm info -a -n /dev/sda |
親デバイスまで遡ってすべての属性（KERNEL, SUBSYSTEM, ATTR{}）をudevルール記法形式でツリー表示します。 |
| monitor | udevadm monitor --kernel --udev |
カーネルからudevへ送信されるイベント（uevent）をリアルタイムに監視します。USB抜き差し時の挙動確認に最適です。 |
| trigger | udevadm trigger --action=change |
カーネルに対してデバイスイベントを強制再送させ、udevルールを全デバイスへ再適用します。 |
| control | udevadm control --reload |
ルールファイル群を再読み込みします。 |
実機で/dev/sdaのudevルール生成用属性を確認した出力例です。
$ udevadm info -a -n /dev/sda | head -n 12
looking at device '/devices/.../block/sda':
KERNEL=="sda"
SUBSYSTEM=="block"
DRIVER==""
ATTR{alignment_offset}=="0"
ATTR{capability}=="0"
ATTR{discard_alignment}=="0"
ATTR{diskseq}=="1"
ATTR{ext_range}=="256"
ATTR{hidden}=="0"この情報から、udevルールを記述する際はKERNEL=="sda"やSUBSYSTEM=="block"といった条件に合致させれば良いことが論理的に特定できます。
4.3 ハードウェア情報確認と仮想環境での注意点
システムに接続されている物理デバイスの調査には、以下のコマンド群を使用します。
lspci：PCI / PCI Expressバスに接続されたデバイス（NIC、GPU、RAIDカード等）を表示lsusb：USBコントローラおよび接続されたUSBデバイスを表示lshw：システム全体のハードウェア構成（マザーボード、CPU、メモリ、ディスク等）を階層構造で出力
4.4 カーネルログの調査（dmesg と journalctl -k）
OS起動中や運用中にハードウェア障害やカーネルエラーが発生した場合、カーネルの環状バッファ（リングバッファ）に記録されたメッセージを調査します。
# エラー（err）および警告（warn）レベルのカーネルログのみを抽出
$ sudo dmesg --level=err,warn
# systemdのjournalログからカーネルメッセージ（-k）を重大度（-p 4: 警告以上）で絞り込み
$ journalctl -k -p 4 -n 104.5 カーネルクラッシュダンプ（kdump）の概要
カーネルが致命的な障害（カーネルパニック）に遭遇してシステムが停止した際、原因究明のためにメモリ全体の内容をディスクへ退避させる仕組みがkdumpです。
kdumpは、パニック発生時に通常のカーネルから、メモリ上に事前確保されていた独立領域で動作する専用の「キャプチャカーネル（Crash Kernel）」をkexec機構によって瞬時に起動します。キャプチャカーネルが障害発生時のメモリイメージ（vmcore）を/var/crash/配下にダンプ保存します。保存されたvmcoreは、後からcrashコマンドやgdbを用いてスタックトレースを解析し、パニックを引き起こしたカーネル関数やモジュールを特定するために用いられます。
5. 実機で確認するモジュール操作とパラメータ変更の手順
AlmaLinux 9.8の実機（linuc-node01）を使用し、モジュールのパラメータ付きロードからアンロード、さらにsysctlによるネットワークパラメータの動的変更と設定ファイルへの反映手順を段階的に実行します。
-
モジュールの詳細確認と引数付きロード
検証用仮想ネットワークモジュール
dummyを対象に、モジュールが受け付ける引数を確認した上でロードします。# パラメータの確認 $ modinfo dummy | grep parm parm: numdummies:Number of dummy pseudo devices (int) # 2つのダミーデバイスを作成する引数を渡してロード $ sudo modprobe dummy numdummies=2 # ロード状態の確認 $ lsmod | grep dummy dummy 12288 0 # 仮想NICの生成確認 $ ip link show dummy0 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether f2:c7:d7:99:01:a1 brd ff:ff:ff:ff:ff:ff -
モジュールの安全なアンロード
モジュールをアンロードします。他のプロセスやモジュールから使用されていない場合のみ解除されます。
$ sudo modprobe -r dummy $ lsmod | grep dummy # （出力なし：安全にアンロード完了） -
カーネルパラメータの動的変更とprocfsの連動確認
ルーター構築で必須となるIPフォワーディング設定（
net.ipv4.ip_forward）を動的変更し、ファイル実体への即時反映を確認します。# 初期値の確認 $ cat /proc/sys/net/ipv4/ip_forward 0 # sysctlコマンドによる動的変更 $ sudo sysctl -w net.ipv4.ip_forward=1 net.ipv4.ip_forward = 1 # procfs側の値が連動して書き換わっていることを確認 $ cat /proc/sys/net/ipv4/ip_forward 1 -
設定ファイル作成による恒久化と反映テスト
再起動後も値を維持するため、
/etc/sysctl.d/に設定ファイルを配置し、sysctl --systemで再ロードします。# 設定ファイルを作成 $ sudo sh -c 'echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/99-ipforward.conf' # 設定の全反映 $ sudo sysctl --system | grep ip_forward * Applying /etc/sysctl.d/99-ipforward.conf ... net.ipv4.ip_forward = 1
6. LinuC 201試験対策：頻出要点の整理と確認問題
6.1 頻出コマンド・重要設定ファイル一覧
試験直前に見返せるよう、主題2.01（2.01.3〜2.01.5）の重要コマンドとファイルパスを整理しました。
| 区分 | コマンド / パス | 役割・試験における着眼点 |
|---|---|---|
| モジュール表示 | lsmod |
ロード済みモジュール一覧（/proc/modules）を表示。オプションなし。 |
| モジュール詳細 | modinfo <モジュール> |
ファイルパス、ライセンス、パラメータ（parm）等を出力。未ロードでも可。 |
| モジュール操作 | modprobe / modprobe -r |
依存関係を自動解決してロード/アンロード。設定ファイルも適用。 |
| 依存ファイル生成 | depmod -a |
/lib/modules/<version>/modules.depを再生成する。 |
| モジュール設定 | /etc/modprobe.d/*.conf |
options, alias, blacklist, installを定義。 |
| パラメータ操作 | sysctl -a / -w / -p / --system |
カーネルパラメータの全表示、動的変更、ファイル読み込み反映。 |
| パラメータ設定 | /etc/sysctl.d/*.conf |
恒久設定ファイル。net.ipv4.ip_forward = 1のように記述。 |
| デバイス管理 | udevadm info / monitor / trigger |
udevの属性調査、イベント監視、ルール再適用。 |
6.2 試験で差がつく2大盲点（insmod vs modprobe、sysctlの対象差）
-
盲点1: insmod と modprobe の依存関係自動解決の有無
insmodは指定された単一の.koファイルのみを直接カーネル空間へ挿入しようとするため、依存する前提モジュールが未ロードの場合、シンボル未解決エラー（Unknown symbol in module）で直ちに失敗します。これに対し、modprobeはmodules.depを事前参照して依存モジュール群を自動で順次ロードします。記述問題で「依存関係を解決してロードするコマンド」と問われたら必ずmodprobeと回答します。 -
盲点2: sysctl -p と sysctl –system の対象ファイル差
sysctl -pは引数を省略した場合、旧来の単一ファイル/etc/sysctl.confのみを読み込みます。しかし現代のシステムでは/etc/sysctl.d/*.confや/run/sysctl.d/*.conf、/usr/lib/sysctl.d/*.confに設定を分割配置するのが標準です。これらすべてのディレクトリから設定を走査・適用するにはsysctl --systemを実行する必要があります。
6.3 本番形式演習問題
Linuxシステムにおいて、カーネルモジュール「e1000e」を依存関係にあるモジュールも含めて安全にアンロードしたい。実行すべき最も適切なコマンドはどれか。1つ選択せよ。
- A.
rmmod e1000e - B.
modprobe -r e1000e - C.
depmod -d e1000e - D.
insmod -r e1000e
解答・解説を確認する
正解：B
解説：
modprobe -r（または --remove）は、指定したモジュールが他のモジュールから参照されていない場合にアンロードし、同時にそのモジュールにのみ依存していた親モジュールも連動して自動的にアンロードします。
Aのrmmodは指定された単一モジュールのみをアンロードするため、依存関係の連動解除は行われません。Cのdepmodは依存関係データベースを更新するコマンドです。Dのinsmodに-rオプションは存在しません。
カーネルモジュールを手動で新規コンパイルして配置した。modprobeコマンドがこの新モジュールを認識できるよう、依存関係定義ファイル（modules.dep）を更新したい。実行すべきコマンドをオプションなしで入力せよ。
解答・解説を確認する
正解：depmod
解説：
depmodコマンドは、/lib/modules/<カーネルバージョン>/ディレクトリ配下の全モジュールを走査し、モジュール間の依存関係を記録したmodules.dep（およびmodules.dep.bin）を生成・更新します。全モジュールを再スキャンする場合は通常depmod -aを実行しますが、設問ではオプションなしのコマンド名が問われているためdepmodが正解となります。
稼働中のLinuxシステムにおいて、一時的にIPv4のパケットフォワーディングを有効化したい。正しいコマンドの組み合わせとして適切なものを2つ選択せよ。
- A.
sysctl -w net.ipv4.ip_forward=1 - B.
echo 1 > /proc/sys/net/ipv4/ip_forward - C.
sysctl -s net.ipv4.ip_forward=1 - D.
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.conf
解答・解説を確認する
正解：A, B
解説：
稼働中のカーネルパラメータを一時的に（動的に）変更する方法は、sysctl -w パラメータ=値を実行するか、/proc/sys/配下の対応するファイルへ直接値をechoリダイレクトする手法の2通りです。したがってAとBが正解です。
Cの-sオプションはsysctlには存在しません。Dは設定ファイルに追記していますが、sysctl -pを実行するかOSを再起動するまで稼働中のカーネルには反映されないため、「一時的な有効化コマンド」としては不適です。
udevのデバイス管理において、特定のデバイスノード（例: /dev/sdb）に関するudevデータベースの属性情報や親デバイスの属性ツリーを調査したい。使用する管理コマンドの名称を入力せよ。
解答・解説を確認する
正解：udevadm
解説：
udevデーモンの管理・情報取得を行う統合コマンドはudevadmです。udevadm info -q all -n /dev/sdbで指定デバイスのプロパティを照会し、udevadm info -a -n /dev/sdbでudevルール記述に必要な全属性ツリーを取得できます。試験ではコマンド名の綴りだけでなく、info、monitor、trigger、controlなどの主要サブコマンドの役割も問われます。
7. まとめと次回予告
今回はLinuC 201試験の最重要分野の1つである「カーネル構造・モジュール管理と運用トラブルシューティング」を解説しました。
| 学習テーマ | 実務および試験における要点 |
|---|---|
| カーネルとinitramfs | 圧縮カーネルvmlinuzと一時ファイルシステムinitramfsの役割分担、DKMSによるドライバ自動再構築の仕組みを押さえる。 |
| モジュール管理 | modprobeは依存関係を自動解決し、insmodは解決しない。依存関係定義はdepmodがmodules.depに書き込む。設定は/etc/modprobe.d/*.conf。 |
| カーネルパラメータ | /proc/sysのディレクトリ階層とsysctlのドット記法は一致。動的変更はsysctl -w、永続化は/etc/sysctl.d/*.confに記述してsysctl --system。 |
| udevとログ | 動的デバイス管理はudevadm info / monitor / triggerで調査。カーネルログはdmesgまたはjournalctl -kで障害切り分けを実施。 |
次回は第3回「ファイルシステム管理・ソフトウェアRAIDとLVMの設定・運用【主題2.02 (2.02.1〜2.02.3)】」に進みます。PV/VG/LVのコマンド体系、mdadmによるRAIDアレイ構築、ext4/XFSの保守コマンド（tune2fs, xfs_repair）、Btrfsの機能まで、サーバーインフラの土台となるストレージ管理技術を実機ログ付きで整理します。
