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.

(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.

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.