Il test Kdump non funziona sui computer distribuiti da MAAS e JUJU

4

Sto cercando di aggiungere kdump sulla mia piattaforma Openstack che è distribuita da MAAS e JUJU.

Ho fatto diversi modi per eseguire l'installazione e il test di Kernel Crash Dump. Tutti i test utilizzano la versione di Ubuntu OS 14.03 LTS.

(1) Installa kdump manualmente sui computer host in base alla guida di ubuntu kernel-crash-dump. Quando stavo per emettere i comandi sudo sysctl -w kernel.sysrq=1 e echo c > /proc/sysrq-trigger con il permesso di root, la console si è bloccata e mostrava pochi messaggi come l'immagine della console allegata. Ho aspettato per molto tempo, quindi riavvio, non è stato scritto alcun registro degli arresti anomali.

(2) Usando l'incantesimo JUJU: in base ai passaggi del fascino di arresto anomalo di JUJU, ho distribuito ubuntu sul computer host con juju deploy ubuntu e ho utilizzato la GUI JUJU per distribuire il dump di arresto anomalo e aggiungere una relazione. Questa volta mostra più dettagli, ma rimane bloccata su CR2: 0000000000000000 come la seconda immagine allegata di seguito.

Da altre informazioni su Q & amp; A in google, il passo successivo che dovrebbe fare dopo la console bloccata dovrebbe essere

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

(3) Uso solo MAAS per distribuire il sistema operativo Ubuntu sulla macchina. E installa manualmente kdump con la guida di ubuntu kernel-crash-dump in (1). E i test rimangono bloccati come "prima" immagine allegata.

Inoltre, cambio la password dell'account Ubuntu eseguendo sudo passwd ubuntu per eseguire test tramite il permesso dell'account di Ubuntu poiché è stato creato da MAAS ( whoami mostra l'account Ubuntu come root). Ma mostra il risultato della "seconda" immagine allegata.

(4) Installa il SO del server Ubuntu e il kernel-crash-dump manualmente sul computer host. Il test è stato positivo e il registro degli arresti anomali è stato generato su /var/crash come previsto.

Ogni volta che kdump config è stato controllato prima del test con comandi come nell'esempio sotto e tutto sembra a posto:

<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

Sono ancora confuso sul motivo per cui il sistema operativo Ubuntu distribuito da MAAS e JUJU non è in grado di eseguire i test di kdump e non ha alcuna idea di eseguire il debug.

Grazie.

    
posta Peter Lai 08.03.2016 - 04:27

1 risposta

1

Dopo aver riprodotto questo problema utilizzando JuJu / MAAS, ho scoperto che la distribuzione di MAAS installa alcuni pacchetti:

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

Alcuni pacchetti ricreano il file initrd in una dimensione molto più grande:

-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

Quindi il parametro crashkernel = 384M-: 128M predefinito aggiunto da kdump-tools è diventato troppo piccolo. Dopo ho cambiato /etc/default/grub.d/kexec-tools.cfg

da

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

Per

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

Devi fare

update-grub

per aggiornare la configurazione di grub. Dopo il riavvio, ora dovresti essere in grado di testare il tuo crash del kernel e generare vmcore senza problemi.

    
risposta data Yuh-Jye Chang 08.06.2016 - 04:32

Leggi altre domande sui tag