Les tests Kdump ne fonctionnent pas sur les machines déployées par MAAS et JUJU
J'essaie d'ajouter kdump sur ma plate-forme Openstack qui est déployée par MAAS et JUJU.
J'ai fait plusieurs façons de faire l'installation et les tests de Kernel Crash Dump. Tous les tests utilisent la version Ubuntu OS 14.03 LTS.
(1) Installez kdump manuellement sur les machines hôtes conformément au guide ubuntu kernel-crash-dump. Quand j'allais lancer les commandes Sudo sysctl -w kernel.sysrq=1 et echo c > /proc/sysrq-trigger avec l'autorisation root, la console est restée bloquée et a affiché peu de messages comme l'image de la console jointe. J'ai attendu longtemps puis redémarré, aucun journal de plantage n'a été écrit.
(2) En utilisant JUJU charm: selon les étapes du JUJU crash dump charm, j'ai déployé ubuntu sur la machine hôte avec juju deploy ubuntu et utilisé l'interface graphique JUJU pour déployer le vidage sur incident et ajouter une relation. Cette fois, il affiche plus de détails, mais il reste bloqué sur CR2: 0000000000000000 comme la deuxième image jointe ci-dessous.
À partir d'autres informations de Q&R dans Google, la prochaine étape qui devrait se produire après la console bloquée devrait être
<blink>
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
...
(3) J'utilise uniquement MAAS pour déployer Ubuntu OS sur la machine. Et installez kdump manuellement avec le guide ubuntu kernel-crash-dump dans (1). Et le test reste bloqué comme la "première" image jointe.
De plus, je change le mot de passe du compte Ubuntu en exécutant Sudo passwd ubuntu pour effectuer des tests via l'autorisation du compte Ubuntu car il a été créé par MAAS (whoami montre le compte Ubuntu en tant que root). Mais il montre le résultat de la "deuxième" image jointe.
(4) Installez manuellement le système d'exploitation du serveur Ubuntu et le kernel-crash-dump sur la machine hôte. Les tests ont réussi et le journal des pannes a été généré le /var/crash comme prévu.
Chaque fois que la configuration de kdump a été vérifiée avant le test par des commandes comme l'exemple ci-dessous et tout semble 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
Je ne comprends toujours pas pourquoi Ubuntu OS déployé par MAAS et JUJU ne peut pas exécuter les tests kdump et n'a aucune idée de déboguer.
Merci.
Après avoir reproduit ce problème moi-même en utilisant JuJu/MAAS, j'ai découvert que le déploiement MAAS installe pas mal de packages:
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
Certains packages recréent le fichier initrd à une taille beaucoup plus 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
Ainsi, le paramètre crashkernel = 384M-: 128M par défaut ajouté par kdump-tools est devenu trop petit. Après avoir changé le fichier /etc/default/grub.d/kexec-tools.cfg
de
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:128M"
À
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT crashkernel=384M-:256M"
Tu as besoin de faire
update-grub
pour mettre à jour votre configuration grub. Après le redémarrage, vous devriez maintenant pouvoir tester votre kernel crash et générer vmcore sans problème.