Kernel Crash Dumps

[Peter M. Petrakis]

On 03/03/2011 07:32 PM, Brian Murray wrote:
> On Thu, Mar 03, 2011 at 05:29:17PM -0500, Peter M. Petrakis wrote:
>>
>>
>> On 03/03/2011 04:46 PM, Brian Murray wrote:
>>> In reviewing the kernel debugging documentation I came across the
>>> instructions for saving a crash dump for a kernel panic[1].  I tried
>>> following them and I'm unable to generate a crash dump.  Additionally,
>>> that page hadn't been touched in quite some time.  I've also found a bug
>>> report[2] about another person having an issue getting crash dumps.
>>>
>>> So my question is - is there something wrong with the documentation?
>>> the crash dump process? or me?
>>
>> It's not you, the system has to be rebooted first. The older
>> versions of the instructions say to reboot, but the 10.04
>> ones don't and neither does the "just install this package"
>> line at the top of the page.
> 
> I rebooted multiple and tested it multiple times.
>

Well then we have a different problem. I recall recently
someone using Natty was also trying to get crashdump
working and found that they were getting a real panic
in the kexec kernel. Perhaps you're seeing the same thing?

>> This may have also been fixed in the meantime, I noticed
>> that /var/crash isn't being created, make sure that exists
>> after the reboot.
> 
> /var/crash would not exist if you were running a stable release of
> Ubuntu as apport crash reporting is turned off then.

Huh? That's where the raw dump is supposed to be written, regardless
of whether it's a stable release or if apport is even installed.

See /usr/share/initramfs-tools/scripts/init-bottom/0_kdump

Examining the apport.conf script, there might be a bug in it.

start on runlevel [2345]
stop on runlevel [!2345]

env enabled=1

pre-start script
    . /etc/default/apport
    [ "$enabled" = "1" ] || [ "$force_start" = "1" ]

    mkdir -p -m 1777 /var/crash
...

Is the local filesystem even mounted yet?

So we need more details from you. Are you actually able to kexec
into the crash kernel upon panic? How far does it get? Does it
hang forever? Please confirm you kernel cli args, it should look
something like this.

BOOT_IMAGE=/boot/vmlinuz-2.6.32-manz10-server root=UUID=8c0f013f-aa69-40fb-afc1-b6d6edc648d7 ro crashkernel=384M-2G:64M,2G-:128M console=tty0 console=ttyS0,115200n8

Finally, even if it is correctly configured, kernels executing
in a panic context aren't one size fits all. You may have to
start ejecting device drivers and be prepared for indepth
kernel debugging.

Peter