kdump doesn't log crash

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
0
down vote

favorite












I have an Ubuntu Desktop system that is frequently crashing (once every 2-3 days maybe?). It was originally running 17.10 (and was crashing on this system) and when 18.04 came out I thought that upgrading might fix the frequent crashes which it didn't.



So I thought I would try to follow the instructions in this Ubuntu guide to enable kdump/linux-crashdump. Following the steps in the guide, everything seems to be correct (kdump-config show says ready to kdump, dmesg | grep -i crash shows reserving memory for crash dump, etc). However when it comes to the "testing crash dump mechanism" portion of the guide, the crash gets successfully triggered by echo c > /proc/sysrq-trigger but the line Saving vmcore from kernel crash never shows up and the system never reboots. Even if I manually reboot the machine, there is no dump file in /var/crash (which I confirmed is the location where the crash files are supposed to be).



I tried increasing the crashkernel size from 128M (the default) to 256M which I saw as a recommendation on some wikis/blog posts/whatever, but that didn't seem to do anything either.



Any thoughts on how to get some insight into these Kernel crashes?



For reference, here is the output from the three verification commands in the guide:



$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ dmesg | grep -i crash
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
[ 0.000000] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 65468MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-20-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-20-generic
current state: ready to kdump

kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash vt.handoff=1 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz






share|improve this question






















  • You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
    – waltinator
    May 18 at 13:55














up vote
0
down vote

favorite












I have an Ubuntu Desktop system that is frequently crashing (once every 2-3 days maybe?). It was originally running 17.10 (and was crashing on this system) and when 18.04 came out I thought that upgrading might fix the frequent crashes which it didn't.



So I thought I would try to follow the instructions in this Ubuntu guide to enable kdump/linux-crashdump. Following the steps in the guide, everything seems to be correct (kdump-config show says ready to kdump, dmesg | grep -i crash shows reserving memory for crash dump, etc). However when it comes to the "testing crash dump mechanism" portion of the guide, the crash gets successfully triggered by echo c > /proc/sysrq-trigger but the line Saving vmcore from kernel crash never shows up and the system never reboots. Even if I manually reboot the machine, there is no dump file in /var/crash (which I confirmed is the location where the crash files are supposed to be).



I tried increasing the crashkernel size from 128M (the default) to 256M which I saw as a recommendation on some wikis/blog posts/whatever, but that didn't seem to do anything either.



Any thoughts on how to get some insight into these Kernel crashes?



For reference, here is the output from the three verification commands in the guide:



$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ dmesg | grep -i crash
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
[ 0.000000] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 65468MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-20-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-20-generic
current state: ready to kdump

kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash vt.handoff=1 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz






share|improve this question






















  • You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
    – waltinator
    May 18 at 13:55












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I have an Ubuntu Desktop system that is frequently crashing (once every 2-3 days maybe?). It was originally running 17.10 (and was crashing on this system) and when 18.04 came out I thought that upgrading might fix the frequent crashes which it didn't.



So I thought I would try to follow the instructions in this Ubuntu guide to enable kdump/linux-crashdump. Following the steps in the guide, everything seems to be correct (kdump-config show says ready to kdump, dmesg | grep -i crash shows reserving memory for crash dump, etc). However when it comes to the "testing crash dump mechanism" portion of the guide, the crash gets successfully triggered by echo c > /proc/sysrq-trigger but the line Saving vmcore from kernel crash never shows up and the system never reboots. Even if I manually reboot the machine, there is no dump file in /var/crash (which I confirmed is the location where the crash files are supposed to be).



I tried increasing the crashkernel size from 128M (the default) to 256M which I saw as a recommendation on some wikis/blog posts/whatever, but that didn't seem to do anything either.



Any thoughts on how to get some insight into these Kernel crashes?



For reference, here is the output from the three verification commands in the guide:



$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ dmesg | grep -i crash
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
[ 0.000000] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 65468MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-20-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-20-generic
current state: ready to kdump

kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash vt.handoff=1 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz






share|improve this question














I have an Ubuntu Desktop system that is frequently crashing (once every 2-3 days maybe?). It was originally running 17.10 (and was crashing on this system) and when 18.04 came out I thought that upgrading might fix the frequent crashes which it didn't.



So I thought I would try to follow the instructions in this Ubuntu guide to enable kdump/linux-crashdump. Following the steps in the guide, everything seems to be correct (kdump-config show says ready to kdump, dmesg | grep -i crash shows reserving memory for crash dump, etc). However when it comes to the "testing crash dump mechanism" portion of the guide, the crash gets successfully triggered by echo c > /proc/sysrq-trigger but the line Saving vmcore from kernel crash never shows up and the system never reboots. Even if I manually reboot the machine, there is no dump file in /var/crash (which I confirmed is the location where the crash files are supposed to be).



I tried increasing the crashkernel size from 128M (the default) to 256M which I saw as a recommendation on some wikis/blog posts/whatever, but that didn't seem to do anything either.



Any thoughts on how to get some insight into these Kernel crashes?



For reference, here is the output from the three verification commands in the guide:



$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ dmesg | grep -i crash
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1
[ 0.000000] Reserving 256MB of memory at 512MB for crashkernel (System RAM: 65468MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash crashkernel=384M-:256M vt.handoff=1

$ kdump-config show
DUMP_MODE: kdump
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x
/var/lib/kdump/vmlinuz: symbolic link to /boot/vmlinuz-4.15.0-20-generic
kdump initrd:
/var/lib/kdump/initrd.img: symbolic link to /var/lib/kdump/initrd.img-4.15.0-20-generic
current state: ready to kdump

kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic root=UUID=20a96099-e38b-4dd7-b006-33c087b6f73b ro quiet splash vt.handoff=1 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz








share|improve this question













share|improve this question




share|improve this question








edited May 18 at 7:26









David Foerster

25.9k1361106




25.9k1361106










asked May 18 at 3:01









syazdani

586




586











  • You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
    – waltinator
    May 18 at 13:55
















  • You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
    – waltinator
    May 18 at 13:55















You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
– waltinator
May 18 at 13:55




You can use journalctl -b -1 -e to see the system log messages jsut before the crash. However, power fails, CPU overheating, CPU failures, etc can crash the system before anything gets logged.
– waltinator
May 18 at 13:55















active

oldest

votes











Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1037625%2fkdump-doesnt-log-crash%23new-answer', 'question_page');

);

Post as a guest



































active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes










 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1037625%2fkdump-doesnt-log-crash%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

pylint3 and pip3 broken

Missing snmpget and snmpwalk

How to enroll fingerprints to Ubuntu 17.10 with VFS491