Comment 10 for bug 1492570

Revision history for this message
Martin Pitt (pitti) wrote :

@halfdog: Indeed, the os.walk() looks pretty broken. It can potentially find stuff in subdirs of /var/crash/<timestamp>, and completely discards os.walk's "root" return value. It also uses "vmcore_root" which is just an alias for apport.fileutils.report_dir, which is confusing for reading the code.

@Louis: I subscribed you as he authored the kernel_crashdump tool for kdump-tools. This is still an undisclosed bug, please don't mention any of this outside of this bug report until this gets public.

I was wondering how kdump-tools works in the first place: It seems that there is no /var/crash/vmcore or /var/crash/<timestamp>/vmcore at all, even though the comment says "kdump-tools has moved vmcore to timestamped dir"? Both the test case and kernel_crashdump only handle picking up the "dmesg" file from /var/crash/<timestamp>/, but no .log file nor actual vmcore file? Is this missing from kernel_crashdump and the test, or intended and the commentary is just wrong? This isn't clear from https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool .

Can you please do an "ls -lR /var/crash" after a typical crash that is handled by kdump-tools, and show the result here?