Comment 12 for bug 710733

I performed some more testing today on a Natty desktop. I'm able to generate a crash dump. However, I've been getting intermittent failures. Like you mention, changing maxsize doesn't seem to help. It was just a coincidence that crash dump worked for the first time, after I increased maxsize. In all the failures, the system hangs performing the following during the dump file creation:

"Copying data : [N%] <- The percentage when the hang happens varies.

I had to perform some steps in addition to what's listed on the CrashdumpRecipe wiki. To get crash dump working(Although intermittently), I performed the following:

1. Installed linux-crashdump and kdump-tools.
 - Should it be necessary to install kdump-tools? Without kdump-tools, I see the following in /var/crash/vmcore.log:

"/root/usr/bin/makedumpfile: error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory"

 - I noticed makedumpfile lives in /usr/bin/ and not /root/usr/bin.
 - I tried creating a sym link in /root/usr/bin to point to the real makedumpfile in /usr/bin, but I still got the same error.
 - I performed an ldd on makedumpfile in /usr/bin, and all the libraries where found.
 - Again, I tried these things before I installed kdump-tools. Once kdump-tools is installed, the lib load error goes away.

2. I manually created the /var/crash directory.

3. Edited /etc/default/apport; Changed enabled from 0 to 1.

4. Edited /etc/default/kdump-tools:
 - Changed USE_KDUMP from 0 to 1.
 - Uncommented: #KDUMP_SYSCTL="kernel.panic_on_oops=1"
 - Without kdump-tools installed, this file doesn't exist.

5. Edited /etc/default/kexec. Changed LOAD_KEXEC from false to true, but this didn't seem to make a difference.

6. Removed 'quiet splash' from the boot parameters(So I could see where it was hanging).

To trigger a panic, I perform:
echo c | sudo tee /proc/sysrq-trigger