設定をテストするため 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/)。

システムクラッシュの原因を究明するには、GNU Debugger (GDB) と良く似た対話式のプロンプト crash ユーティリティーを使用することができます。稼働中の 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 番目のカーネルの起動に問題がある場合は、起動初期のブートログを確認する必要があります。問題のあるマシンに対するシリアルコンソールを有効にすることで、このログを取得することができます。

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

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

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

デフォルトでは makedumpfile はレベル 7 に設定されていて、進捗バー、共通メッセージ、およびエラーメッセージの出力が含まれます。このレベルを 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、ヒープダンプ、ログファイルなど) を送付する 」を参照ください。

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

災害対策計画を作成するためには、通常、ダンプ完了までの時間を把握している必要がありますが、所要時間は、ディスクにコピーされるメモリーの量や、メモリーとストレージのインターフェースのスピードに大きく左右されます。

テストがどのようなタイミングで行われても、システムは典型的な負荷をかけた状態で稼働させておく必要があります。そうでないと、除外されるページによって、完全に負荷がかかった実稼働システムにおける 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 に関しては現在、Kdump Helper および Kernel Oops Analyzer の 2 つの Labs があります。

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

デフォルトのパラメーターは多くの場合、十分に機能しますが、カーネルと同様にモジュールはパラメーターを指定して動作をカスタマイズすることができます。ユーザー空間ツールは、実行中のカーネルに現在ロードされているモジュールを一覧表示することができます。また、利用可能なパラメーターに使用できる全モジュールやモジュール固有の情報をクエリーできます。さらには、実行中のカーネルに対してモジュールを動的にロード/アンロード (削除) することも可能です。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,

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 ストレージデバイスの使用に関する詳しい情報は、https://access.redhat.com/solutions/624423「How to format a USB key」 と https://access.redhat.com/solutions/39373「How to manually mount a USB flash drive in a non-graphical environment 」 を確認してください。

以下の手順では、コピー先のファイルと同じパス名を指定しなければ、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 ディスクイメージの検証」 と 「ブートローダーの検証」 の指示にのみしたがってください。カーネルはデフォルトで起動するように 変更しないでください。Red Hat Network がデフォルトのカーネルを最新バージョンに自動的に変更します。カーネルを手動でインストールするには、「アップグレードの実行」 に進みます。

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

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

# rpm -ivh kernel-kernel_version.arch.rpm

次のステップでは、初期 RAM ディスクイメージが作成されているかどうかを検証します。詳細は、「初期 RAM ディスクイメージの検証」 を参照してください。

初期 RAM ディスクイメージの仕事は、IDE、SCSI、または RAID などのブロックデバイスモジュールをプレロードすることです。そうすることで、それらのモジュールが通常配備されている root ファイルシステムがアクセス可能になりマウントできるようになります。Red Hat Enteprise 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 は、ライブのカーネルパッチソリューションで、プロセスをリブートまたは再起動することなしに、実行中のカーネルにパッチを当てることができます。kpatch は、長時間のタスク完了、ユーザーのログオフ、計画ダウンタイムなどを待機せずに、システム管理者が重要なセキュリティーパッチをカーネルに即座に適用することができます。セキュリティーや安定性を犠牲にすることなく、システムの稼働時間中に制御できるようになります。

ライブのカーネルパッチ機能は、RPM パッケージとして提供されるカーネルモジュール (kmod) で実装されます。kpatch ユーティリティーは、ライブカーネルパッチ用のカーネルモジュールをインストールおよび削除するのに使用します。

Premium サブスクリプションを契約されているお客様は、Red Hat サポートが提供する迅速化された修正ソリューションの一部として、ライブのカーネルパッチをリクエストしていただけます。

Premium サブスクリプションを契約されているお客様で、再起動を必要とする hotfix カーネルを通常使用する場合は、ダウンタイムを必要としない kpatch kmod をリクエストすることが可能です。kpatch パッチは、hotfix カーネルと同じ方法で、修正が含まれるエラータがリリースされてから 30 日間サポートされます。

お客様は、Red Hat カスタマーポータル から直接サポートケースを起票して、適切かつ迅速な修正オプションについて相談していただけます。

kpatch は、汎用のカーネルアップグレードメカニズムではありません。システムをすぐに再起動できない場合など、単純なセキュリティーおよびバグ修正の更新を適用する場合に使用します。

パッチを読み込み中または読み込み後に、SystemTap または kprobe を使用 しないでください。パッチは、プローブが削除されるまで、適用されない可能性があります。

cat /sys/kernel/debug/tracing/trace を実行して ftrace 出力ファイルに直接アクセス しないでください。代わりに、trace-cmd ユーティリティーがサポートされています。

kpatch を使用時には、システムを一時停止またはハイバネート しないようにしてください。一時停止またはハイバネートすると、短期間パッチが一時的に無効になってしまいます。

kpatch のコンポーネントは以下の通りです。

# yum install kpatch

# yum install kpatch-patch-7.0-1.el7.x86_64.rpm

# kpatch list
Loaded patch modules:
kpatch_7_0_1_el7
Installed patch modules:
kpatch-7-0-1-el7.ko (3.10.0-121.el7.x86_64)
kpatch-7-0-1-el7.ko (3.10.0-123.el7.x86_64)

# yum update kpatch-patch-7.0-2.el7.x86_64.rpm

# kpatch unload kpatch_7_0_2_el7

# kpatch uninstall kpatch_7_0_2_el7

# kpatch uninstall --kernel-version 3.10.0-121.el7.x86_64 kpatch_7_0_2_el7

kpatch ユーティリティーは、ftrace を使用して、カーネル機能へのポインターの任意の再マッピングを有効にします。カーネルのライブパッチをシステムに適用すると、以下が発生します。

図4.1 kpatch の仕組み

カーネルのライブパッチを提供するサードパーティーまたはプロプライエタリーのツールをいつくか利用できますが、Red Hat がサポートするのは kpatch と、Red Hat サポート契約から提供される RPM モジュールに限定されます。Red Hat は、サードパーティーのライブパッチにサポートを提供しませんが、エンジニアリングと公式な Red Hat kpatch への依頼は常に受け付けています。

サードパーティーのライブパッチに対する任意の Red Hat のレビューについては、以下の基準を満たしているかどうかを判定するため、ソースコードの提供が必要です。

根本原因の特定が必要なため、調査の開始時にカーネルのライブパッチのベンダーと話すことを Red Hat では推奨しています。これにより、ベンダーの許可が得られた場合はソースコードを提供できるようになります。また、Red Hat サポートが調査に乗り出す前に、ベンダーのサポート組織が原因特定のために協力できることになります。

サードパーティーのカーネルのライブパッチでシステムを実行している場合は、Red Hat が提供し、サポートしているソフトウェアでこの問題を再現するよう依頼する権利を Red Hat は保有しています。再現できない場合は、同じ挙動が見られるかどうかを確認するために、ライブパッチが適用されていないテスト環境にデプロイされたのと同様のシステムとワークロードが必要になります。

サードパーティーソフトウェアのサポートポリシーに関する情報は、https://access.redhat.com/articles/1067 のナレッジベースにある 「Red Hat グローバルサポートサービスは、サードパーティーのソフトウェア、ドライバー、そして認定されていないハードウェアおよびハイパーバイザー、もしくはゲストのオペレーティングシステムについてどのようなサポートを提供していますか?」 を参照してください。

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

チューニング可能なカーネルを修正するには、以下の 3 つの方法があります。

チューニング可能なものは、カーネルのサブシステムによっていくつかのグループに分けられます。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)

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

この機能は、'direct_access' ブロックデバイス操作を実装するファイルシステムで利用可能で、'-o' でファイルシステムをマウントするか、または /etc/fstab のオプションセクションに '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 の動作をカスタマイズするために起動時のみに使用されます。