Kdump 测试不适用于 MAAS 和 JUJU 部署的机器

Kdump 测试不适用于 MAAS 和 JUJU 部署的机器

我正在尝试在由 MAAS 和 JUJU 部署的 Openstack 平台上添加 kdump。

我尝试了几种方法来安装和测试 Kernel Crash Dump。所有测试均使用 Ubuntu OS 14.03 LTS 版本。

(1) 根据 ubuntu kernel-crash-dump 指南在主机上手动安装 kdump。当我要发出命令sudo sysctl -w kernel.sysrq=1echo c > /proc/sysrq-trigger以 root 权限运行时,控制台卡住了,并显示了一些消息,如附加的控制台图像。我等了很长时间,然后重新启动它,没有写入崩溃日志。

kdump 测试卡在控制台 1

(2) 使用 JUJU charm:根据 JUJU crash dump charm 中的步骤,我在主机上部署了 ubuntu,juju deploy ubuntu并使用 JUJU GUI 部署崩溃转储并添加关系。这次它显示了更多详细信息,但它卡住了,CR2: 0000000000000000就像下面第二张附图一样。

kdump 测试卡在控制台 2

从谷歌的其他问答信息来看,控制台卡住后下一步应该做的是

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

(3) 我只使用 MAAS 在机器上部署 Ubuntu 操作系统。并使用 (1) 中的 ubuntu kernel-crash-dump 指南手动安装 kdump。测试仍然像“第一个”附图一样卡住。

此外,我通过执行sudo passwd ubuntuUbuntu 帐户权限测试来更改 Ubuntu 帐户的密码,因为它是由 MAAS 创建的(whoami显示 Ubuntu 帐户为 root)。但它显示了“第二张”附图的结果。

(4)在主机上手动安装 Ubuntu 服务器操作系统和 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 操作系统无法执行 kdump 测试,也不知道如何调试。

谢谢。

答案1

在使用 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,而不会出现问题。

相关内容