Comment 13 for bug 1492570

Hi Martin, halfdog,

Just to be precise, I didn't author kernel_crashdump, just adapted it to the use of kdump-tools instead of custom scripts.

Here is the content of /var/crash after a clean install & addition of the linux-crashdump meta-package that will install the necessary bits to enable kernel crash dumps (i.e. makedumpfile, kexec-tools, kdump-tools & a few more).

# find /var/crash
/var/crash
/var/crash/kexec_cmd

This is the content of /var/crash just after the kernel dump capture and reboot, but BEFORE /usr/share/apport/kernel_crashdump gets executed ( boot was stopped by the 'debug break=init' boot parameter) :

(initramfs) find /root/var/crash
/root/var/crash
/root/var/crash/201509160921
/root/var/crash/201509160921/dmesg.201509160921
/root/var/crash/201509160921/dump.201509160921
/root/var/crash/kexec_cmd

This is the content of /var/crash AFTER kernel_crashdump execution :

$ find /var/crash
/var/crash
/var/crash/linux-image-3.13.0-62-generic 3.13.0-62.102-201509160921.crash
/var/crash/201509160921
/var/crash/201509160921/dmesg.201509160921
/var/crash/201509160921/dump.201509160921
/var/crash/kexec_cmd

The comment means that, starting with Raring, there is no longer any /var/crash/vmcore generated but rather what we see above, which is /var/crash/{timestamp}/dump.{timestamp}

Now looking at the tests & what I modified, I can see the misleading bits.

vmcore & vmcore.log tests are part of the test_kernel_crashdump_kexec which tests the Pre-Raring way of gathering crash dumps, still in use in Lucid & Precise.

Post-Raring installs use kdump-tools, so their related tests are test_kernel_crashdump_kdump() which will test the /var/crash content listed above.