Eu estou tentando adicionar o kdump na minha plataforma Openstack, que é implementada pelo MAAS e JUJU.
Eu fiz várias maneiras de fazer a instalação e teste do Kernel Crash Dump. Todos os testes usam a versão Ubuntu OS 14.03 LTS.
(1) Instale o kdump manualmente em máquinas host de acordo com o guia ubuntu kernel-crash-dump. Quando eu ia emitir os comandos sudo sysctl -w kernel.sysrq=1 e echo c > /proc/sysrq-trigger com permissão de root, o console ficou preso e mostrou algumas mensagens como a imagem do console anexado. Eu esperei por um longo tempo, em seguida, reinicie-o, nenhum log de acidente foi escrito.
(2) Usando charme JUJU: de acordo com as etapas do JUJU crash dump charm, implantei o ubuntu na máquina host com juju deploy ubuntu e usei a GUI JUJU para implantar o despejo de memória e adicionar relação. Desta vez, ele mostra mais detalhes, mas fica preso em CR2: 0000000000000000 como a segunda imagem anexada abaixo.
De outros Q & amp; Uma informação no google, o próximo passo esperado para fazer após o console preso deve ser
<blink>
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
...
(3) Eu só uso o MAAS para implantar o sistema operacional Ubuntu na máquina. E instale o kdump manualmente com o guia kernel-crash-dump do ubuntu em (1). E o teste ainda fica preso como "primeira" imagem anexada.
Além disso, altero a senha da conta do Ubuntu executando sudo passwd ubuntu para fazer testes via permissão de conta do Ubuntu, uma vez que ela foi criada pelo MAAS ( whoami mostra a conta do Ubuntu como root). Mas mostra o resultado da "segunda" imagem anexada.
(4) Instale o sistema operacional do servidor Ubuntu e o kernel-crash-dump manualmente na máquina host.
O teste foi bem-sucedido e o log de falhas foi gerado em /var/crash conforme o esperado.
Cada vez que a configuração do kdump foi verificada antes do teste por comandos como o exemplo abaixo e tudo parece bem:
<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
Ainda estou confuso sobre o motivo pelo qual o Ubuntu OS implementado pelo MAAS e o JUJU não podem executar o teste do kdump e não tenho a menor ideia de depurar.
Obrigado.