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
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. vmcore. log:
- Should it be necessary to install kdump-tools? Without kdump-tools, I see the following in /var/crash/
"/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: SYSCTL= "kernel. panic_on_ oops=1"
- Changed USE_KDUMP from 0 to 1.
- Uncommented: #KDUMP_
- 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