Linux カーネルは、モノリシックとして設計されています。しかし、各ユースケースで必要とされる追加またはオプションのモジュールでコンパイルされています。つまり、動的に読み込まれる カーネルモジュール を使用してカーネル機能を拡張することができます。カーネルモジュールは、以下のものを提供できます。

モジュールは、カーネル自体と同様に、その動作をカスタマイズするパラメーターを受けることができます。いずれのパラメーターも、ほとんどの場合に正しく動作します。カーネルモジュールに関連して、ユーザー空間ツールは以下の操作を行うことができます。

kmod パッケージにより提供される、このようなユーティリティーの多くは、動作の実行時にモジュールの依存関係を考慮します。そのため、手動で依存関係を追跡する必要はほとんどありません。

最新のシステムでは、必要に応じて、さまざまなメカニズムによりカーネルモジュールが自動的に読み込まれます。ただし、モジュールを手動で読み込むか、削除しないといけない場合もあります。たとえば、どちらのモジュールも基本的な機能は提供できるものの、いずれかのモジュールが好まれる場合か、モジュールが、予期しない動作をしている場合などです。

特定のカーネルモジュールは、複数の他のカーネルモジュールに依存する場合があります。/lib/modules/<KERNEL_VERSION>/modules.dep ファイルには、各カーネルバージョンに対するカーネルモジュールの依存関係の完全な一覧が含まれます。

依存関係ファイルは、kmod パッケージの一部である depmod プログラムにより生成されます。kmod によるユーティリティーの多くは、操作を実行する際にモジュールの依存関係を考慮に入れるため、手動 で依存関係を追跡する必要はほとんどありません。

lsmod コマンドを実行すると、現在カーネルに読み込み済みの全カーネルモジュールを一覧表示できます。 以下に例を示します。

# lsmod
Module                  Size  Used by
tcp_lp                 12663  0
bnep                   19704  2
bluetooth             372662  7 bnep
rfkill                 26536  3 bluetooth
fuse                   87661  3
ebtable_broute         12731  0
bridge                110196  1 ebtable_broute
stp                    12976  1 bridge
llc                    14552  2 stp,bridge
ebtable_filter         12827  0
ebtables               30913  3 ebtable_broute,ebtable_nat,ebtable_filter
ip6table_nat           13015  1
nf_nat_ipv6            13279  1 ip6table_nat
iptable_nat            13011  1
nf_conntrack_ipv4      14862  4
nf_defrag_ipv4         12729  1 nf_conntrack_ipv4
nf_nat_ipv4            13263  1 iptable_nat
nf_nat                 21798  4 nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat
[output truncated]

lsmod 出力では、3 つのコラムを表示します。

最後に、lsmod 出力は /proc/modules 擬似ファイルの内容ほど詳細ではないので、はるかに読み取りやすくなっている点に留意してください。

カーネルモジュールに関する詳しい情報は、modinfo <MODULE_NAME> コマンドを使用して表示できます。

# modinfo e1000e
filename:       /lib/modules/3.10.0-121.el7.x86_64/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        2.3.2-k
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation,

Linux カーネルの機能を拡張する最適な方法は、カーネルモジュールを読み込むことです。以下の手順では、modprobe コマンドを使用して、カーネルモジュールを検出し、現在実行しているカーネルに読み込む方法を説明します。

時折、実行中のカーネルから特定のカーネルモジュールをアンロードする必要性に駆られることがあります。以下の手順では、modprobe コマンドを使用して、現在読み込まれているカーネルから、システムの実行時にカーネルモジュールを見つけてアンロードする方法を説明します。

以下の手順では、ブートプロセス中に自動的に読み込まれるようにカーネルモジュールを設定する方法を説明します。

以下の手順では、システムの起動プロセス中にカーネルモジュールが自動的に読み込まれないように拒否リストに追加する方法を説明します。

Red Hat Enterprise Linux 7 には UEFI セキュアブート機能が含まれているので、Red Hat Enterprise Linux 7 は UEFI セキュアブートが有効になっているシステム上でインストールし、実行できます。Red Hat Enterprise Linux 7 では、UEFI システムでセキュアブートを使用する必要がないことにご留意ください。

セキュアブートが有効な場合は、UEFI オペレーティングシステムのブートローダー、Red Hat Enterprise Linux カーネル、およびすべてのカーネルモジュールを秘密鍵で署名し、それに対応する公開鍵で認証する必要があります。それらが署名・認証されてなければ、システムは起動プロセスを終了できません。

Red Hat Enterprise Linux 7 ディストリビューションには、以下が含まれます。

また、署名された第 1 ステージのブートローダーと署名されたカーネルには、組み込み Red Hat 公開鍵が含まれています。これらの署名済みバイナリーおよび組み込み鍵により、Red Hat Enterprise Linux 7 は UEFI セキュアブート対応のシステムで、UEFI ファームウェアが提供する Microsoft UEFI セキュアブート認証局キーを使用してインストール、ブート、および実行できます。

以下のセクションでは、セキュアブートが有効になっている UEFI ベースのビルドシステム上で Red Hat Enterprise Linux 7 に使用する、プライベートで構築されたカーネルモジュールへの自己署名に必要な手順を説明しています。また、カーネルモジュールの展開を希望するターゲットシステムに公開鍵をインポートするのに利用可能なオプションについても説明しています。

カーネルモジュールに署名して読み込むには、以下を行う必要があります。

# keyctl list %:.system_keyring
3 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# keyctl list %:.system_keyring
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...

# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...

カーネルの設定項目を使用することで、Red Hat Enterprise Linux の起動時に、またはシステムを実行中にオンデマンドで動作をカスタマイズできます。ハードウェアのパラメーターによっては、起動時のみに指定され、システムが実行し始めると変更できないものもありますが、ほとんどの場合は必要に応じて変更でき、次の起動に向けてパーマネント設定ができます。

カーネルの設定項目を修正するには、以下の 3 つの方法があります。

設定項目は、カーネルのサブシステムによっていくつかのグループに分けられます。Red Hat Enterprise Linux システムにおける設定項目には、以下のクラスがあります。

カーネル引数の別名を持つカーネルコマンドラインパラメーターは、Red Hat Enterprise Linux の動作をカスタマイズするために起動時のみに使用されます。

Linux カーネルモジュールのソースチェッカー (ksc) は、所定のカーネルモジュール内におけるホワイトリスト以外の記号を確認するツールです。Red Hat パートナーもこのツールを使用して、Red Hat Bugzilla データベースにバグを報告することで、ホワイトリストに含まれる記号のレビューを要求できます。

# ksc -k e1000e.ko
Checking against architecture x86_64
Total symbol usage: 165	Total Non white list symbol usage: 74

# ksc -k /path/to/module

Invalid architecture, (Only kernel object files are supported)

「file system dax」または「fs dax」として知られるファイルの Direct Access により、アプリケーションは、デバイスへのアクセスをバッファーするためにページキャッシュを使用することなく、dax 対応のストレージデバイスへのデータの読み取りおよび書き込みが可能となります。

この機能は、ext4 ファイルシステムまたは xfs ファイルシステムを使用する場合に限り利用でき、-o dax でファイルシステムをマウントするか、/etc/fstab のマウントエントリーの options セクションに dax を追加すると有効になります。

コードの実例を含む詳しい情報は、kernel-doc パッケージを参照してください。これは、/usr/share/doc/kernel-doc-<version>/Documentation/filesystems/dax.txt に保存されていて、'<version>' が対応するカーネルバージョン番号になります。

メモリー保護キーは、ページベースの保護を強化するメカニズムを提供しますが、アプリケーションが保護ドメインを変更した時にページテーブルを修正する必要はありません。これは、各ページテーブルエントリーで以前無視されていた 4 ビットを「保護キー」に割り当て、可能なキーを 16 個提供することで有効となります。

メモリー保護キーは、いくつかの Intel CPU チップセットのハードウェア機能です。プロセッサーがこの機能をサポートしているかどうかは、pku in /proc/cpuinfo の存在を確認します。

$ grep pku /proc/cpuinfo

この機能をサポートするために、CPU は各キーに対して 2 つの別々のビット (Access Disable と Write Disable) を持つ、ユーザーがアクセス可能な新しいレジスター (PKRU) を提供します。この新しいレジスターの読み取りおよび書き込み用の新しい命令が 2 つ (RDPKRU と WRPKRU) 存在します。

プログラミングの実例を含む詳しい情報は、kernel-doc パッケージが提供する /usr/share/doc/kernel-doc-*/Documentation/x86/protection-keys.txt を参照してください。

Kernel Adress Space Layout Randomization (KASLR) は 2 つの部分で構成され、これらが共に機能して Linux カーネルのセキュリティーを強化します。

カーネルテキストの物理アドレスと仮想アドレスの場所が、個別にランダム化されます。カーネルの物理アドレスは 64 TB の任意の場所に配置できますが、カーネルの仮想アドレスは、[0xffffffff80000000, 0xffffffffc0000000] の間の 1 GB 領域に制限されます。

メモリー管理の KASLR には 3 つのセクションがあり、これらのセクションの開始アドレスは特定のエリアでランダム化されます。したがって、悪意のコードが、カーネルアドレス領域にその記号が置かれていることを知る必要がある場合に、KASLR は悪意のコードにカーネルの実行を挿入またはリダイレクトしないようにすることができます。

メモリー管理の KASLR には、以下の 3 つのセクションがあります。

KASLR コードが Linux カーネルにコンパイルされ、デフォルトで有効になりました。明示的に無効にするには、nokaslr カーネルオプションをカーネルコマンドラインに追加します。

Red Hat Enterprise Linux には以下のカーネルパッケージが含まれています。

カーネルをアップグレードする前に、予防的な前準備手順の実行をお薦めします。

まず、問題が発生した場合に備えてシステム用に機能するブートメディアがあることを確認します。ブートローダーで新しいカーネルをブートするように正しく設定されていない場合には、このメディアを使って Red Hat Enterprise Linux をブートすることができます。

USB メディアは多くの場合、ペンドライブ、サムディスク または キー などと呼ばれるフラッシュデバイスの形式、または、外部接続のハードディスクとして提供されています。このタイプのほとんどすべてが VFAT ファイルシステムとしてフォーマットされています。ただし、ext2、ext3、ext4 または VFAT としてフォーマットされているメディア上でブート可能な USB メディアを作成することができます。

ディストリビューションのイメージファイル、または最低限ブートメディア (minimal boot media) イメージを USB メディアに転送することができます。デバイスには十分な空き領域があることを確認してください。約 4 GB がディストリビューション DVD イメージ用に必要で、約 700 MB がディストリビューション CD イメージ用に、そして約 10 MB が最低限ブートメディアイメージ用に必要です。

Red Hat Enterprise Linux のインストール DVD、またはインストール CD-ROM#1 からの boot.iso ファイルのコピーと、約 16 MB の空き領域を持つ VFAT ファイルシステムでフォーマットした USB ストレージデバイスが必要になります。

USB ストレージデバイスの使用方法は『How to format a USB key』 および『How to manually mount a USB flash drive in a non-graphical environment solution』を参照してください。

以下の手順では、コピー先のファイルと同じパス名を指定しなければ、USB ストレージデバイス上にある既存のファイルは影響を受けません。USB ブートメディアを作成するには、root ユーザーとして以下のコマンドを実行します。

別の方法として、フロッピードライブがあるシステム上でブートディスクを作成するには、mkbootdisk パッケージをインストールして、root として mkbootdisk コマンドを実行します。このパッケージをインストールした後に使用法について確認するには、man mkbootdisk の man ページを参照してください。

どのカーネルがインストールされているかを判定するには、シェルプロンプトでコマンド yum list installed "kernel-*" を実行します。出力では、システムのアーキテクチャーに応じて、以下のパッケージのすべてか、または一部が示されます。 バージョン番号は異なる場合があります。

# yum list installed "kernel-*"
kernel.x86_64                   3.10.0-54.0.1.el7           @rhel7/7.0
kernel-devel.x86_64             3.10.0-54.0.1.el7           @rhel7
kernel-headers.x86_64           3.10.0-54.0.1.el7           @rhel7/7.0

この出力から、カーネルのアップグレード用にダウンロードすべきパッケージを判断します。シングルプロセッサーのシステムでは、必要なパッケージは kernel パッケージのみです。異なるパッケージの説明は、「カーネルパッケージの概要」 を参照してください。

システム用に更新されたカーネルが利用可能かを判定する手段は数種類あります。

yum を使用して Red Hat Network から更新されたカーネルをダウンロードしてインストールする場合は、「初期 RAM ファイルシステムイメージの確認」 および 「ブートローダーの確認」 の手順のみに従ってください。カーネルはデフォルトで起動するように変更 しないでください。カーネルはデフォルトで起動するように変更しないでください。カーネルを手動でインストールするには、「アップグレードの実行」 に進みます。

必要なパッケージをすべて取り込んだ後は、既存カーネルをアップグレードします。

シェルプロンプトで、カーネル RPM パッケージを格納しているディレクトリーに移動します。rpm コマンドに -i 引数を使用して古いカーネルを残します。-U オプションは現在インストールしてあるカーネルを上書きして、ブートローダーの問題を起こすので、これは 使用しないでください。以下に例を示します。

# rpm -ivh kernel-kernel_version.arch.rpm

次の手順では、初期 RAM ファイルシステムイメージが作成されているかどうかを検証します。詳細は、「初期 RAM ファイルシステムイメージの確認」 を参照してください。

初期 RAM ファイルシステムイメージの仕事は、IDE、SCSI、RAID などのブロックデバイスモジュールをプレロードすることです。そうすることで、それらのモジュールが通常配備されている root ファイルシステムがアクセス可能になりマウントできるようになります。 Red Hat Enterprise Linux 7 システムでは、パッケージマネージャーの Yum、PackageKit、または RPM のいずれかを使用して新しいカーネルをインストールする場合は、常に Dracut ユーティリティーがインストールスクリプトにより呼び出され、initramfs (初期 RAM ファイルシステムイメージ) を作成します。

/etc/sysctl.conf ファイルまたは別の sysctl 設定ファイルを変更してカーネル属性を変更し、変更した設定がブートプロセスの初期段階で使用される場合には、dracut -f コマンドを使用して、初期 RAM ファイルシステムイメージの再構築が必要な場合があります。たとえば、ネットワーク関連の変更を受けて、ネットワークにアタッチされたストレージから起動する場合などです。

IBM eServer System i（ 「IBM eServer System i 上の初期 RAM ファイルシステムイメージとカーネルの検証」を参照）以外のすべてのアーキテクチャー上では、dracut コマンドを実行すると initramfs を作成できます。ただし、initramfs は手動で作成する必要はありません。このステップは、カーネルとその関連パッケージが Red Hat 配布の RPM パッケージからインストールされているか、またはアップグレードされている場合には自動的に実行されます。

現在のカーネルバージョンに該当する initramfs が存在していること、それが grub.cfg 設定ファイル内で正しく指定されているかを検証するには、以下の手順にしたがいます。

IBM eServer System i 上の初期 RAM ファイルシステムイメージとカーネルの検証

IBM eServer System i のマシンでは、初期 RAM ファイルシステムとカーネルファイルは１つのファイルに統合してあり、これは addRamDisk コマンドで作成されます。カーネルとその関連パッケージがインストールされているか、または Red Hat 配布の RPM パッケージでアップグレードされている場合は、このステップは自動的に実行されるので、手動で実行する必要はありません。このファイルが作成されていることを確認するには、root で以下のコマンドを実行して /boot/vmlinitrd-kernel_version ファイルがすでに存在することを確認します。

# ls -l /boot/

kernel_version は、先程インストールしたカーネルバージョンと一致する必要があります。

初期 RAM ファイルシステムイメージへの変更を戻す方法

たとえば、システムの設定を間違えたことで起動しなくなったような場合は、以下の手順に従って初期 RAM ファイルシステムイメージに加えた変更を戻す必要があります。

上記の手順は、sysctl.conf ファイルで vm.nr_hugepages を間違って設定してしまった場合などに便利です。sysctl.conf ファイルは initramfs に含まれているため、新たな vm.nr_hugepages 設定は initramfs で適用されてしまい、initramfs が再構築されてしまいます。ただし、設定が間違っているので、新規の initramfs は破損しており、新規に構築されるカーネルは起動しないため、上記の手順を使用した設定の修正が必要になります。

初期 RAM ファイルシステムイメージのコンテンツの一覧表示

initramfs に含まれるファイルを一覧表示するには、root で以下のコマンドを実行します。

# lsinitrd

/etc ディレクトリーにあるファイルだけを表示するには、以下のコマンドを使用します。

# lsinitrd | grep etc/

現行カーネルの initramfs に保存されている特定ファイルのコンテンツを出力するには、-f オプションを使用します。

# lsinitrd -f filename

たとえば、sysctl.conf のコンテンツを出力するには、以下のコマンドを実行します。

# lsinitrd -f /etc/sysctl.conf

カーネルのバージョンを指定するには、--kver オプションを使用します。

# lsinitrd --kver kernel_version -f /etc/sysctl.conf

たとえば、カーネルバージョン 3.10.0-327.10.1.el7.x86_64 に関する情報を一覧表示するには、以下のコマンドを使用します。

# lsinitrd --kver 3.10.0-327.10.1.el7.x86_64 -f /etc/sysctl.conf

yum コマンドまたは rpm コマンドで、カーネルをインストールしてください。

rpm を使用してカーネルをインストールすると、カーネルパッケージはブートローダー設定ファイル内にその新しいカーネル用のエントリーを作成します。

いずれのコマンドも、/etc/sysconfig/kernel 設定ファイルに以下の設定を含める場合にのみ、新しいカーネルがデフォルトのカーネルとして起動するよう設定することに留意してください。

DEFAULTKERNEL=kernel
UPDATEDEFAULT=yes

DEFAULTKERNEL オプションは、デフォルトのカーネルパッケージタイプを指定します。UPDATEDEFAULT オプションは、新規カーネルパッケージがデフォルトで新しいカーネルにするかを指定します。

kpatch ユーティリティーは、Red Hat リポジトリー提供の RPM モジュールを含む、Red Hat がサポートする唯一のカーネルライブパッチユーティリティーです。Red Hat は、Red Hat 提供でないライブカーネルパッチはサポートしません。

サードパーティーのライブパッチのサポートは、パッチを提供しているベンダーにお問い合わせください。

サードパーティーのライブパッチを実行しているシステムの場合、Red Hat は、Red Hat が同梱し、サポートしているソフトウェアの複製を求める権利を有します。これが可能でない場合、Red Hat は、同じ動作が発生するかどうかを確認するために、ライブパッチを適用せずに、お使いのテスト環境で同じようなシステムとワークロードの展開を求めます。

サードパーティソフトウェアサポートポリシーの詳細は、「Red Hat グローバルサポートサービスは、サードパーティーのソフトウェア、ドライバー、そして認定されていないハードウェアおよびハイパーバイザー、もしくはゲストのオペレーティングシステムについてどのようなサポートを提供していますか?」を参照してください。

ライブのカーネルパッチ機能は、RPM パッケージとして提供されるカーネルモジュール (.ko ファイル) として実装されます。

すべてのお客様は、通常のチャンネルから提供されるカーネルライブパッチにアクセスできます。ただし、延長サポートサービスにサブスクライブしていないお客様は、次のマイナーリリースが利用可能になると、現行のマイナーリリースに対する新しいパッチへのアクセスを失うことになります。たとえば、標準のサブスクリプションを購入しているお客様は、RHEL 8.3 がリリースされるまで RHEL 8.2 のライブパッチのみを行うことができます。

カーネルのライブパッチのコンポーネントは、以下のようになります。

kpatch カーネルパッチソリューションは、livepatch カーネルサブシステムを使用して、古い機能の出力先を新しい機能に変更します。ライブカーネルパッチがシステムに適用されると、以下が発生します。

図6.1 カーネルライブパッチの仕組み

カーネルパッチモジュールは RPM パッケージに含まれ、パッチが適用されたカーネルバージョンに固有のものとなります。各 RPM パッケージは、徐々に蓄積されていきます。

以下のサブセクションでは、指定のカーネルに対して、将来のすべての累積パッチの更新を受け取る方法を説明します。

カーネルパッチモジュールが配信され、RPM パッケージを通じて適用されているため、累計のカーネルパッチモジュール更新は、他の RPM パッケージの更新と似ています。

前提条件

手順

関連情報

システム管理者が、Red Hat Enterprise Linux カーネルライブパッチソリューション関連の不足の悪影響に遭遇した場合は、このメカニズムを無効化する選択肢があります。以下のセクションでは、ライブパッチソリューションを無効にする方法を説明します。

カーネルドライバーのブラックリスト化により、それらの読み込みや使用が禁止されます。/etc/sysconfig/kdump ファイルでドライバーを追加すると、kdump initramfs がブラックリストに指定したモジュールを読み込まなくなります。

カーネルドライバーをブラックリストに登録すると、oom killer またはその他のクラッシュカーネルの障害を防ぐことができます。カーネルドライバーをブラックリストに指定するには、/etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 変数を更新し、以下のブラックリストオプションのいずれかを指定できます。

設定をテストするため kdump を有効にしてシステムを再起動し、サービスが実行されているか確認します。

~]# systemctl is-active kdump
active

次に、シェルプロンプトで以下のコマンドを入力します。

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

このコマンドにより、Linux カーネルは強制的にクラッシュして address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが設定で選択した場所にコピーされます (デフォルトでは /var/crash/)。

システムクラッシュの原因を確認するには、crash ユーティリティーを使用します。これにより、GDB (GNU Debugger) と非常によく似たインタラクティブなプロンプトを利用できます。稼働中の Linux システムだけでなく netdump、diskdump、xendump、kdump などで作成したコアダンプなども対話形式で分析することができます。

yum install crash

debuginfo-install kernel

crash /usr/lib/debug/lib/modules/<kernel>/vmlinux \ /var/crash/<timestamp>/vmcore

~]# crash /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux \
/var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore

crash 5.0.0-23.el6
Copyright (C) 2002-2010  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/2.6.32-69.el6.i686/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2010-08-25-08:45:02/vmcore  [PARTIAL DUMP]
        CPUS: 4
        DATE: Wed Aug 25 08:44:47 2010
      UPTIME: 00:09:02
LOAD AVERAGE: 0.00, 0.01, 0.00
       TASKS: 140
    NODENAME: hp-dl320g5-02.lab.bos.redhat.com
     RELEASE: 2.6.32-69.el6.i686
     VERSION: #1 SMP Tue Aug 24 10:31:45 EDT 2010
     MACHINE: i686  (2394 Mhz)
      MEMORY: 8 GB
       PANIC: "Oops: 0002 [#1] SMP " (check log for details)
         PID: 5591
     COMMAND: "bash"
        TASK: f196d560  [THREAD_INFO: ef4da000]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash>

crash> log
... several lines omitted ...
EIP: 0060:[<c068124f>] EFLAGS: 00010096 CPU: 2
EIP is at sysrq_handle_crash+0xf/0x20
EAX: 00000063 EBX: 00000063 ECX: c09e1c8c EDX: 00000000
ESI: c0a09ca0 EDI: 00000286 EBP: 00000000 ESP: ef4dbf24
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process bash (pid: 5591, ti=ef4da000 task=f196d560 task.ti=ef4da000)
Stack:
 c068146b c0960891 c0968653 00000003 00000000 00000002 efade5c0 c06814d0
<0> fffffffb c068150f b7776000 f2600c40 c0569ec4 ef4dbf9c 00000002 b7776000
<0> efade5c0 00000002 b7776000 c0569e60 c051de50 ef4dbf9c f196d560 ef4dbfb4
Call Trace:
 [<c068146b>] ? __handle_sysrq+0xfb/0x160
 [<c06814d0>] ? write_sysrq_trigger+0x0/0x50
 [<c068150f>] ? write_sysrq_trigger+0x3f/0x50
 [<c0569ec4>] ? proc_reg_write+0x64/0xa0
 [<c0569e60>] ? proc_reg_write+0x0/0xa0
 [<c051de50>] ? vfs_write+0xa0/0x190
 [<c051e8d1>] ? sys_write+0x41/0x70
 [<c0409adc>] ? syscall_call+0x7/0xb
Code: a0 c0 01 0f b6 41 03 19 d2 f7 d2 83 e2 03 83 e0 cf c1 e2 04 09 d0 88 41 03 f3 c3 90 c7 05 c8 1b 9e c0 01 00 00 00 0f ae f8 89 f6 <c6> 05 00 00 00 00 01 c3 89 f6 8d bc 27 00 00 00 00 8d 50 d0 83
EIP: [<c068124f>] sysrq_handle_crash+0xf/0x20 SS:ESP 0068:ef4dbf24
CR2: 0000000000000000

crash> bt
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
 #0 [ef4dbdcc] crash_kexec at c0494922
 #1 [ef4dbe20] oops_end at c080e402
 #2 [ef4dbe34] no_context at c043089d
 #3 [ef4dbe58] bad_area at c0430b26
 #4 [ef4dbe6c] do_page_fault at c080fb9b
 #5 [ef4dbee4] error_code (via page_fault) at c080d809
    EAX: 00000063  EBX: 00000063  ECX: c09e1c8c  EDX: 00000000  EBP: 00000000
    DS:  007b      ESI: c0a09ca0  ES:  007b      EDI: 00000286  GS:  00e0
    CS:  0060      EIP: c068124f  ERR: ffffffff  EFLAGS: 00010096
 #6 [ef4dbf18] sysrq_handle_crash at c068124f
 #7 [ef4dbf24] __handle_sysrq at c0681469
 #8 [ef4dbf48] write_sysrq_trigger at c068150a
 #9 [ef4dbf54] proc_reg_write at c0569ec2
#10 [ef4dbf74] vfs_write at c051de4e
#11 [ef4dbf94] sys_write at c051e8cc
#12 [ef4dbfb0] system_call at c0409ad5
    EAX: ffffffda  EBX: 00000001  ECX: b7776000  EDX: 00000002
    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7776000
    SS:  007b      ESP: bfcb2088  EBP: bfcb20b4  GS:  0033
    CS:  0073      EIP: 00edc416  ERR: 00000004  EFLAGS: 00000246

crash> ps
   PID    PPID  CPU   TASK    ST  %MEM     VSZ    RSS  COMM
>     0      0   0  c09dc560  RU   0.0       0      0  [swapper]
>     0      0   1  f7072030  RU   0.0       0      0  [swapper]
      0      0   2  f70a3a90  RU   0.0       0      0  [swapper]
>     0      0   3  f70ac560  RU   0.0       0      0  [swapper]
      1      0   1  f705ba90  IN   0.0    2828   1424  init
... several lines omitted ...
   5566      1   1  f2592560  IN   0.0   12876    784  auditd
   5567      1   2  ef427560  IN   0.0   12876    784  auditd
   5587   5132   0  f196d030  IN   0.0   11064   3184  sshd
>  5591   5587   2  f196d560  RU   0.0    5084   1648  bash

crash> vm
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
   MM       PGD      RSS    TOTAL_VM
f19b5900  ef9c6000  1648k    5084k
  VMA       START      END    FLAGS  FILE
f1bb0310    242000    260000 8000875  /lib/ld-2.12.so
f26af0b8    260000    261000 8100871  /lib/ld-2.12.so
efbc275c    261000    262000 8100873  /lib/ld-2.12.so
efbc2a18    268000    3ed000 8000075  /lib/libc-2.12.so
efbc23d8    3ed000    3ee000 8000070  /lib/libc-2.12.so
efbc2888    3ee000    3f0000 8100071  /lib/libc-2.12.so
efbc2cd4    3f0000    3f1000 8100073  /lib/libc-2.12.so
efbc243c    3f1000    3f4000 100073
efbc28ec    3f6000    3f9000 8000075  /lib/libdl-2.12.so
efbc2568    3f9000    3fa000 8100071  /lib/libdl-2.12.so
efbc2f2c    3fa000    3fb000 8100073  /lib/libdl-2.12.so
f26af888    7e6000    7fc000 8000075  /lib/libtinfo.so.5.7
f26aff2c    7fc000    7ff000 8100073  /lib/libtinfo.so.5.7
efbc211c    d83000    d8f000 8000075  /lib/libnss_files-2.12.so
efbc2504    d8f000    d90000 8100071  /lib/libnss_files-2.12.so
efbc2950    d90000    d91000 8100073  /lib/libnss_files-2.12.so
f26afe00    edc000    edd000 4040075
f1bb0a18   8047000   8118000 8001875  /bin/bash
f1bb01e4   8118000   811d000 8101873  /bin/bash
f1bb0c70   811d000   8122000 100073
f26afae0   9fd9000   9ffa000 100073
... several lines omitted ...

crash> files
PID: 5591   TASK: f196d560  CPU: 2   COMMAND: "bash"
ROOT: /    CWD: /root
 FD    FILE     DENTRY    INODE    TYPE  PATH
  0  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
  1  efade5c0  eee14090  f00431d4  REG   /proc/sysrq-trigger
  2  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
 10  f734f640  eedc2c6c  eecd6048  CHR   /pts/0
255  f734f640  eedc2c6c  eecd6048  CHR   /pts/0

crash> exit
~]#

クラスター化された環境で kdump を使用する場合には、何に注意したら良いですか?

「RHEL 6 および 7 の High Availability アドオンで使用できるように kdump を設定する」の記事で、High Availability アドオンを使用しているシステム管理者が利用可能なオプションを説明しています。

起動初期に kdump が失敗します。 どのようにしてブートログをキャプチャーするのですか?

2 番目のカーネルの起動に問題がある場合は、起動初期のブートログを確認する必要があります。 問題のあるマシンに対するシリアルコンソールを有効にすることで、このログを取得することができます。

「RHEL7 でシリアルターミナルを設定する」の記事で、起動初期のブートメッセージへアクセスするために必要な設定が説明されています。

デバッグ用に、どのようにして makedumpfile からのメッセージを増やすのですか?

makedumpfile が失敗する時には、何が悪いのかを理解するためにログのレベルを増やさなければならない場合があります。これはダンプレベルを設定するのとは異なる操作です。 ログのレベルについては、/etc/kdump.conf の core_collector 行の内容を編集して、makedumpfile に対する message_level オプションを増やします。

デフォルトで makedumpfile はレベル 1 に設定されており、これは、出力を進捗インジケーターに制限します。このメッセージレベルを 31 に設定すると、すべてのデバッグ情報を有効にできます。メッセージレベル 31 では、進捗インジケーター、共通メッセージ、エラーメッセージ、デバッグメッセージ、およびレポートメッセージの詳細を出力します。

core_collector 設定の行は、設定時には以下のようになっているはずです。

core_collector makedumpfile -l --message-level 1 -d 31

どのようにして Dracut をデバッグするのですか?

dracut が initramfs の構築に失敗することがあります。その場合には、問題を切り分けるために dracut のログレベルを増やす必要があります。

/etc/kdump.conf を編集して dracut_args 行を変更し、必要なすべての dracut 引数と共にオプション -L 5 を含めます。

dracut_args で他のオプションを設定していない場合は、次のような結果になるはずです。

dracut_args -L 5

仮想マシンで利用可能なダンプの手法は何ですか?

多くの場合、クラッシュやパニックの後にマシンからメモリーダンプを取得するには kdump の仕組みがあれば十分です。これは、ベアメタルのインストールと同じように設定することができます。

ただし、場合によっては、ハイパーバイザーと直接連携してクラッシュダンプを取得する必要がある場合があります。ハイパーバイザーを使用したクラッシュダンプの取得方法として libvirt には pvpanic と virsh dump という 2 つの仕組みがあります。これらの手法は 『仮想化の導入および管理ガイド』 に記載されています。

pvpanic の仕組みについては、『仮想化の導入および管理ガイド』の「パニックデバイスの設定」に記載されています。

virsh dump コマンドについては、『仮想化の導入および管理ガイド』の「ドメインのコアのダンプファイルの作成」で説明されています。

Red Hat サポートサービスに大きなサイズのダンプをアップロードする場合はどうしたらいいですか ?

分析のため、Red Hat グローバルサポートサービスにカーネルクラッシュのダンプファイルを送信していただく必要がある場合があります。ただし、ダンプファイルのサイズはフィルターで特定の情報に絞り込んだ場合でも非常に大きくなる可能性があります。新しいサポートケースの起票時に、250 MB を超えるファイルは Red Hat カスタマーポータルからは直接アップロードできないため、Red Hat では大きなサイズのファイルのアップロード用に FTP サーバーを用意しています。

FTP サーバーのアドレスは dropbox.redhat.com で、ファイルは /incoming/ ディレクトリーにアップロードしてください。ご使用の FTP クライアントを passive モードに設定しておく必要があります。 ご使用のファイアウォールでこのモードを使用できない場合は origin-dropbox.redhat.com サーバーを active モードでご利用ください。

アップロードするファイルは必ず gzip などで圧縮し、ファイル名にはわかりやすい名前を付けてください。ファイル名にサポートケース番号を使用されることをお薦めします。必要なファイルをすべてアップロードしたらサポートケース担当のエンジニアへ正確なファイル名とその SHA1 または MD5 チェックサムをお知らせください。

詳細な説明については「Ret Hat サポートチームにファイル (vmcore、rhev logcollector、sosreport、ヒープダンプ、ログファイルなど) を送付する」を参照ください。

クラッシュダンプが完了するまでに、どれくらい時間がかかりますか?

この情報は、障害復旧計画の目的で、ダンプ完了の所要時間を把握するために、多くの場合に必要となります。ただし、この時間の長さは、ディスクにコピーされるメモリー量と、RAM とストレージ間のインターフェースの速度に大きく左右されます。

テストがどのようなタイミングで行われても、システムは典型的な負荷をかけた状態で稼働させておく必要があります。そうでないと、除外されるページによって、完全に負荷がかかった実稼働システムにおける kdump の動作で誤った見解が提示される可能性があります。特にこの違いは、大量のメモリーが使用されている状況でより顕著に見られます。

ダンプの所要時間を評価する場合に、ストレージインターフェースもプランニング時に考慮する必要があります。ネットワーク制約事項が原因で、ローカルに接続された SATA ディスクと比べると、ssh などを使用した接続ダンプは完了までに長く時間がかかる可能性があります。

インストール時に Kdump をどのように設定するのですか?

キックスタートまたは対話型の GUI を使用すれば、わずかなオプションを指定するだけでインストール時に kdump を設定することができます。

anaconda インストール GUI を使用した kdump の設定については、『インストールガイド』の「Kdump」セクションに詳しい説明が記載されています。

kickstart 構文は以下の通りです。

%addon com_redhat_kdump [--disable,enable] [--reserve-mb=[auto,value]]
%end

キックスタートに対するこのアドオンにより、kdump 機能の無効化/有効化や、オプションとして予約メモリーサイズの定義 (自動のデフォルトオプションを明示的に呼び出す、またはメガバイト単位で数値を指定する) が可能になります。 なお、スイッチ全体が省略された場合も、デフォルトオプションが呼び出されます。

キックスタートを使用してシステムのデプロイメントを自動化する方法の詳細は、『インストールガイド』の「キックスタートを使ったインストール」を参照してください。

キックスタートアドオン構文の詳細については、『インストールガイド』の「キックスタート構文の参考資料」を参照してください。

Portal Labs は簡単な Web アプリケーションで、システム管理者がさまざまなシステムタスクを実施するのに役立ちます。現在、Kdump に焦点を当てているラボが 2 つあります。Kdump Helper および Kernel Oops Analyzer

整合性サブシステムは、システムのデータの整合性を維持するカーネルの一部を構成します。このサブシステムは、ユーザーが特定のシステムファイルに望ましくない変更を行うことを防ぎ、システムを初期状態に維持するのに役立ちます。

カーネル整合性サブシステムは、2 つの主要なコンポーネントで構成されています。

IMA と EVM のどちらにも、追加機能を備えた多くの機能拡張が含まれます。以下に例を示します。

カーネル整合性サブシステムは、TPM (Trusted Platform Module)を使用して、システムセキュリティーをさらに強化できます。TPM は、重要な暗号化機能についての TNC (Trusted Computing Group) による仕様です。TPM は通常、プラットフォームのマザーボードに接続される専用ハードウェアとして実装され、ハードウェアチップの保護された改ざん防止領域から暗号化機能を提供することで、ソフトウェアベースの攻撃を防ぎます。TPM 機能の一部は次のとおりです。

Integrity Measurement Architecture (IMA) は、カーネル整合性サブシステムに属するコンポーネントです。IMA は、アクセス前にファイルのハッシュを測定し、保存し、評価することにより、ローカルファイルのコンテンツを維持することを目的としています。これにより、信頼性のないデータの読み取りおよび実行を防ぐことができ、システムのセキュリティーが強化されます。

Extended Verification Module (EVM) は、ファイルの拡張属性 (xattr) の変更を監視するカーネル整合性サブシステムに属するコンポーネントです。Integrity Measurement Architecture (IMA) を含む多くのセキュリティー指向のテクノロジーは、コンテンツハッシュなどの機密ファイル情報を拡張属性に保存します。EVM は、この拡張属性と特別な鍵から別のハッシュを作成します。これはシステムの起動時に読み込まれます。結果のハッシュは、拡張属性が使用されるたびに検証されます。たとえば、IMA がファイルを評価する場合です。

信頼できる 鍵および 暗号化された鍵 は、カーネルキーリングサービスによって使用されるカーネルが生成する可変長の対称鍵です。このタイプのキーは、暗号化されていない形式でユーザー空間に表示されないため、整合性を検証できます。したがって、それらは Extended Verification Module (EVM) により、実行中のシステムの整合性を検証し、確認するために使用できます。ユーザーレベルのプログラムがアクセス可能なのは、暗号化された ブロブ の形式での鍵のみです。

信頼できる鍵は、Trusted Platform Module (TPM) チップというハードウェアが必要になります。これは、鍵を作成し、暗号化 (保護) するために使用されます。TPM は storage root key (SRK) という 2048 ビットの RSA 鍵を使用して鍵を保護します。

信頼でき、暗号化された鍵についての詳細は、『RHEL 7 セキュリティーガイド』の「Trusted and Encrypted Keys」セクションを参照してください。

Integrity Measurement Architecture (IMA) および Extended Verification Module (EVM) は、さまざまな方法でシステムセキュリティーを強化するカーネル整合性サブシステムのコンポーネントです。IMA および EVM を設定すると、ファイルに署名できるため、システムのセキュリティーを強化できます。

Integrity Measurement Architecture (IMA) の最初の操作段階は、 Measurement フェーズです。ここでは、ファイルのハッシュを作成し、それらをファイルの拡張属性 (xattrs) として保存することができます。以下のセクションでは、ファイルのハッシュを作成し、検証する方法を説明します。