it-swarm-es.tech

Las pruebas de Kdump no funcionan en máquinas implementadas por MAAS y JUJU

Estoy tratando de agregar kdump en mi plataforma Openstack que implementa MAAS y JUJU.

Hice varias formas de hacer la instalación y prueba de Kernel Crash Dump. Todas las pruebas utilizan la versión Ubuntu OS 14.03 LTS.

(1) Instale kdump manualmente en máquinas Host de acuerdo con la guía ubuntu kernel-crash-dump. Cuando iba a emitir los comandos Sudo sysctl -w kernel.sysrq=1 y echo c > /proc/sysrq-trigger con permiso de root, la consola se atascó y mostró pocos mensajes como la imagen de la consola adjunta. Esperé mucho tiempo y luego lo reinicié, no se escribió ningún registro de bloqueo.

kdump testing stuck console 1

(2) Al usar el encanto JUJU: de acuerdo con los pasos en el encanto del volcado por caída JUJU, implementé ubuntu en la máquina Host con juju deploy ubuntu y usé la GUI JUJU para implementar el volcado por caída y agregar una relación. Esta vez muestra más detalles, pero se atasca en CR2: 0000000000000000 como la segunda imagen adjunta a continuación.

kdump testing stuck console 2

De otra información de preguntas y respuestas en google, el siguiente paso que se espera hacer después de una consola atascada debe ser

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

(3) Solo uso MAAS para implementar Ubuntu OS en la máquina. E instale kdump manualmente con la guía ubuntu kernel-crash-dump en (1). Y la prueba todavía se atasca como la "primera" imagen adjunta.

Además, cambio la contraseña de la cuenta de Ubuntu ejecutando Sudo passwd ubuntu para hacer pruebas a través del permiso de la cuenta de Ubuntu, ya que fue creado por MAAS (whoami muestra la cuenta de Ubuntu como root). Pero muestra el resultado de la "segunda" imagen adjunta.

(4) Instale el sistema operativo del servidor Ubuntu y kernel-crash-dump manualmente en la máquina Host. La prueba fue exitosa y el registro de fallas se generó en /var/crash como se esperaba.

Cada vez que se verificó la configuración de kdump antes de la prueba mediante comandos como el siguiente ejemplo y todo parece estar bien:

<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

Todavía estoy confundido sobre por qué el sistema operativo Ubuntu implementado por MAAS y JUJU no puede ejecutar las pruebas de kdump y no tengo idea de depurar.

Gracias.

3
Peter Lai

Después de reproducir este problema yo mismo usando JuJu/MAAS, descubrí que la instalación de MAAS instala bastantes paquetes:

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

Algunos de los paquetes recrean el archivo initrd a un tamaño mucho mayor:

-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

Entonces, el parámetro predeterminado crashkernel = 384M-: 128M agregado por kdump-tools se volvió demasiado pequeño. Después de cambiar el /etc/default/grub.d/kexec-tools.cfg

de

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

A

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

Necesitas hacer

update-grub

para actualizar su configuración de grub. Después de reiniciar, ahora debería poder probar el bloqueo del kernel y generar vmcore sin problemas.

2
Yuh-Jye Chang