Você diz que testou o netconsole configurando-o no servidor host. Você quer dizer que você configurou um syslogd de escuta lá e usou o netcat no cliente para enviar mensagens para ele? Se sim, então não parece que você testou o netconsole.
Você verificou a configuração do netconsole, com todos os endereços mac corretos? A documentação é agradável e detalhada. Depois de carregar o módulo com os atributos apropriados, você pode testá-lo escrevendo para / dev / kmsg como root:
# echo my kernel message > /dev/kmsg
Alternativamente, aciona um memdump ou falha com o sysrq . Netconsole deve pegar isso e enviá-lo para o seu destino. O tcpdump é muito útil para verificar que tipo de pacotes são enviados enquanto você testa. Algo parecido com isso o ajudaria a começar (observe -e, que incluirá endereços de ethernet):
# tcpdump -i eth0 -n -e port 514
Você mencionou que deseja capturar pânicos. A natureza desses pânicos pode ser tal que eles matem completamente o sistema antes que o netconsole (ou kexec / kdump) seja capaz de fazer qualquer coisa (como foi o caso dos recentes segundos bissextos), ou você poderia obter entradas de log bem-sucedidas .
Em uma nota secundária, uma alternativa ao netconsole é usar o kexec + kdump recursos do kernel. Após pânico "gerenciável", o kernel irá kexec um kernel habilitado para o kdump que carregará um initrd mínimo, e então gravará o dump do kernel no disco. Depois, ele pode ser analisado por ferramentas como crash .