第673回の「カーネルのクラッシュ情報を取得する」では，カーネルクラッシュ時に情報を収集する仕組みを有効化しました。得られた情報は活用しないと意味がありません。今回はその中身を解析する方法を紹介します。

デバッグパッケージのインストール

第673回では，意図的にシステムをクラッシュさせることで，dmesgとvmcoreを取得しました。カーネルが今際の際に次につながる情報を残してくれたのです。「⁠しかしながらあのクラッシュが最後のpanicだとは思えない。もし，同じカーネルが続けて使われるとしたら，あのpanicの同類が，また世界のどこかへ現れてくるかもしれない……」

最初に行うべきなのは，前回紹介したように問題発生時のdmesgを読むことです。これである程度，状況の絞り込みは行えますし，運が良ければ原因がわかることもあります。しかしながら，dmesgだけだと「問題が起きた場所」はわかっても，「⁠なぜそこで問題が起きたのか」まではわからないことも多いです。そこで利用できるのがクラッシュダンプです。これは現象発生したあと，実際にpanicが発生したタイミングでのカーネルメモリーの内容が保存されています。つまり，実行中のタスクは何かや，他のタスクの状態，各種変数の内容などを一通り確認できるのです。

というわけで第673回で取得した，クラッシュダンプの内容を精査しましょう。第673回ではsysrq-triggerを用いて意図的にクラッシュさせて，/var/crash/以下にdmesgとクラッシュダンプ（vmcoreファイル）を取得していました。今回解析するのはこのクラッシュダンプのほうです。解析にはcrashコマンドを利用します。crashはカーネルダンプの調査に特化した，gdbのラッパーツールです。

ただしカーネルをデバッガで調査するのであれば，vmlinuxやstripされていないカーネルモジュール群が必要です。実はこれらのファイルは非常にサイズが大きいため，通常のリポジトリには置かれていません。デバッグシンボル用のリポジトリを取り込む必要があります。まずは次のコマンドで，リポジトリを有効化してください。

$ sudo apt install ubuntu-dbgsym-keyring
$ sudo tee /etc/apt/sources.list.d/ddebs.list << EOF
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)          main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-updates  main restricted universe multiverse
deb http://ddebs.ubuntu.com/ $(lsb_release -cs)-proposed main restricted universe multiverse
EOF
$ sudo apt update

ちなみに上記はUbuntu 18.04 LTS以降でのみ有効です。18.04より前にはubuntu-dbgsym-keyringパッケージがないため，リポジトリにある鍵を別途取り込むようにしてください。また今回の手順はUbuntuのリリースカーネルにのみ有効です。Mainlineビルドや，その他サードパーティのカーネルの場合は，別の手段でデバッグシンボル付きカーネルを入手してください（※1⁠）⁠。

※1

サイズの都合で，公式のMainlineビルドにおいてはデバッグパッケージは提供されていません。Mainlineビルドのクラッシュダンプを解析したいなら，まずは自分でカーネルを再ビルドするところからはじめましょう。

さて，今回は現在実行中のカーネルのデバッグパッケージをインストールしましょう。

$ sudo apt install linux-image-$(uname -r)-dbgsym

おそらく1GiBほどのサイズをダウンロードすることになるので注意してください。またクラッシュダンプ取得時のカーネルバージョンが，実行中のカーネルではない「$(uname -r)」の部分を適宜書き換えてください。クラッシュダンプのカーネルバージョンは，たとえばdmesgファイルの以下の部分で確認可能です。

[ 6262.530045] CPU: 3 PID: 111191 Comm: tee Kdump: loaded Tainted: G S       C  E     5.11.0-22-generic #23-Ubuntu

ここの「5.11.0-22-generic」が「$(uname -r)」のそれに該当します。

ちなみにcrashコマンドとデバッグパッケージさえ用意できるなら，「⁠クラッシュが発生したマシン」である必要はありません。運用中のサーバーはそのままクラッシュ情報収集したら，再度運用に戻して，別のマシンで解析することも可能です。

なお，別のアーキテクチャーの解析は，Ubuntuのcrashコマンドではできません。たとえば，Raspberry Piで発生したクラッシュダンプは，x86マシンでは解析できないのです。ただしこれはUbuntuのcrashコマンドのビルド方法に起因するものであり，crashコマンドを自前でクロスビルドするなら，別アーキテクチャーのダンプを解析することは可能です。