Problemas de registro de Kernel Panic para depuración

Estoy ejecutando Ubuntu 12.04 en AWS / EC2 y tengo una gran cantidad de hosts funcionando. Estoy tratando de habilitar el volcado del kernel, pero cuando simulo un kernel panic, no hay ningún archivo .crash escrito en ninguna parte del sistema de archivos.

Seguí las instrucciones aquí: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe

Y las cosas parecen estar configuradas correctamente:

# cat /proc/cmdline 
root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M

# dmesg |grep crash
[    0.000000] Command line: root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M
[    0.000000] Reserving 64MB of memory at 832MB for crashkernel (System RAM: 1708MB)
[    0.000000] Kernel command line: root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M

# cat /sys/kernel/kexec_crash_loaded
1

Pero cuando ejecuto:

# echo c | sudo tee /proc/sysrq-trigger

El sistema se reinicia como se esperaba, pero no se genera ningún archivo de 'bloqueo' de ningún tipo. ¿Qué podría estar haciendo mal?

Asegúrese de que kdump initscript esté habilitado. Los paquetes kexec_crash se basan en un initscript para omitir la rutina de inicio normal. Determina si la invocación actual de o no initfue una invocada por un bloqueo, y la usa para determinar si el estado de ejecución anterior debe ser volcado o no antes de realizar un reinicio verdadero.

Dicho esto, si su sistema de prueba no es lo suficientemente pequeño como para caber en 64Mb sin que note que cualquier otro bloqueo está reduciendo su memoria total, esto probablemente no sea lo que está sucediendo.

Lo principal que debe buscar es si el segundo initestá disparando. Inmediatamente después de bloquear el sistema, debería ver secuencias de inicio initscript en la consola que no están precedidas por un reinicio .

• Si esto no está sucediendo, su núcleo de bloqueo no se está disparando en absoluto.
• Si esto está sucediendo y se le deja caer en un mensaje, su initscript no está haciendo su trabajo. (o no está habilitado o no detecta el estado posterior al bloqueo)
• Si esto sucede, el segundo initincendio, el sistema se reinicia, initcomienza de nuevo y, a pesar de todo esto, todavía no tiene ningún archivo ... debe solucionar los problemas que ocurren justo antes de que el inducto de kdump emita el reinicio. Irónicamente, uno de los mejores métodos es desactivar el initscript y ejecutar los comandos a mano. (precaución: ¡asegúrese de que sus servicios puedan caber en la memoria del kernel de bloqueo antes de intentar esto!)