web-dev-qa-db-ja.com

Kdumpテストは、MAASおよびJUJUによってデプロイされたマシンでは機能しません

MAASとJUJUによってデプロイされているOpenstackプラットフォームにkdumpを追加しようとしています。

カーネルクラッシュダンプのインストールとテストを行う方法をいくつか行いました。すべてのテストではUbuntu OS 14.03 LTSバージョンを使用しています。

（1）ubuntuカーネルクラッシュダンプガイドに従って、ホストマシンにkdumpを手動でインストールします。 root権限でSudo sysctl -w kernel.sysrq=1およびecho c > /proc/sysrq-triggerコマンドを発行しようとすると、コンソールが動かなくなり、添付されているコンソールイメージのようなメッセージがほとんど表示されませんでした。しばらく待ってから再起動しましたが、クラッシュログは書き込まれませんでした。

kdump testing stuck console 1

（2）JUJUチャームを使用する：JUJUクラッシュダンプチャームの手順に従って、juju deploy ubuntuを使用してホストマシンにubuntuをデプロイし、JUJU GUIを使用してクラッシュダンプをデプロイし、関係を追加しました。今回は詳細を表示しますが、下の2番目の添付画像のようにCR2: 0000000000000000で止まります。

kdump testing stuck console 2

Googleの他のQ＆A情報から、コンソールが動かなくなった後に行うと予想される次のステップは、

<blink>
[    0.000000] Initializing cgroup subsys cpuset 
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
...

（3）私はMAASのみを使用してマシンにUbuntu OSをデプロイします。 （1）のubuntu kernel-crash-dumpガイドを使用してkdumpを手動でインストールします。そして、テストはまだ「最初の」添付画像のように行き詰まっています。

さらに、Sudo passwd ubuntuを実行してUbuntuアカウントのパスワードを変更し、MAASによって作成されたため、Ubuntuアカウントの権限を介してテストを実行します（whoamiは、ルートとしてUbuntuアカウントを示します）。ただし、「2番目」の添付画像の結果が表示されます。

（4）UbuntuサーバーOSとkernel-crash-dumpをホストマシンに手動でインストールします。テストは成功し、予想どおり/var/crashにクラッシュログが生成されました。

以下の例のようなコマンドによるテストの前にkdump構成がチェックされ、すべてが正常に見えるようになるたびに：

<blink>
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.13.0-77-generic root=UUID=8e8764a1-3d79-4f6e-945e-f30e42ea5f5a ro crashkernel=384M-:128M

# cat /sys/kernel/kexec_loaded
0
# cat /sys/kernel/kexec_crash_loaded
1

# kdump-config show
DUMP_MODE:        kdump
USE_KDUMP:        1
KDUMP_SYSCTL:     kernel.panic_on_oops=1
KDUMP_COREDIR:    /var/crash
crashkernel addr: 0x2c000000
current state:    ready to kdump

 kexec command:
  /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-3.13.0-77-generic root=UUID=8e8764a1-3d79-4f6e-945e-f30e42ea5f5a ro irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic

MAASとJUJUによって展開されたUbuntu OSがkdumpテストを実行できず、デバッグするアイデアがないのに、まだ混乱しています。

ありがとう。

serverjujumaasopenstack
3
Peter Lai

JuJu/MAASを使用して自分でこの問題を再現した後、MAASデプロイメントがかなりの数のパッケージをインストールしていることがわかりました。

Installing package: curl
Installing package: cpu-checker
Installing package: bridge-utils
Installing package: rsyslog-gnutls
Installing package: cloud-utils
Installing package: cloud-image-utils
Installing package: tmux

一部のパッケージは、initrdファイルをはるかに大きなサイズに再作成します。

-rw-r--r-- 1 root root 24964912 Apr 18 16:32 /boot/initrd.img-3.13.0-85-generic
-rw-r--r-- 1 root root 24978648 Jun  7 09:32 /boot/initrd.img-3.13.0-87-generic

そのため、kdump-toolsによって追加されたデフォルトのcrashkernel = 384M-：128Mパラメータが小さすぎます。 /etc/default/grub.d/kexec-tools.cfgを変更した後

から

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M"

に

GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:256M"

あなたがする必要があります

update-grub

gRUB設定を更新します。再起動後、カーネルクラッシュをテストし、問題なくvmcoreを生成できるようになります。

2
Yuh-Jye Chang