Crash tool saying core file is not the same version as debug kernel but they are

Latest response

I have a core file from a VM.

Crash tool will not read it:

crash /usr/lib/debug/lib/modules/2.6.18-308.el5/vmlinux /opt/crash/vmss.core

crash 7.1.0-3.el6
[SNIP...]
GNU gdb (GDB) 7.6
[SNIP...]
This GDB was configured as "x86_64-unknown-linux-gnu"...
crash: /usr/lib/debug/lib/modules/2.6.18-308.el5/vmlinux and /opt/crash/vmss.core do not match!

It would seem this is incorrect, uname -r on the host shows: 2.6.18-308.el5
This is verified here:

strings /usr/lib/debug/lib/modules/2.6.18-308.el5/vmlinux | grep "Linux version"

Linux version 2.6.18-308.el5 (mockbuild@ca-build10.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Sat Feb 25 12:40:07 EST 2012

strings /opt/crash/vmss.core | grep "Linux version"

Linux version 2.6.18-308.el5 (mockbuild@ca-build10.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Sat Feb 25 12:40:07 EST 2012

These are identical.

Any ideas?

Responses

Woah, sorry about the markup, it wont let me edit it. Just assume I am not shouting the commands :).

Unless the new site-update removed the capability, you should be able to go back and edit your post in such a way that MarkDown doesn't try to be "helpful".

In MarkDown, the # character is interpreted as an style heading, to avoid such interpretation, usually possible to do so by indenting your content (typically with a leading two- or four-spaces) or offset your code-block with a token that MarkDown interprets as "everything between this and the next token is to be interpreted literally". Something like:

# crash /path/to/file
output line 1
output line 2
output line 3

Probably a silly question: why are you trying to use a generalized debugger rather than a tool designed for processing a kernel-dump (e.g., the crash utility)?

N/m... Lost the use of crash in the (mis)formatting: only noticed the gdb callout.

I can edit the post but not the content as it says I don't have permissions to do so which seams a little odd.

The commands are using the standard crash debugging tool, I use it a lot. But have only ever seen this error when accidentally using the wrong kernel level for the debug path, but in this case I haven't, they match fine.

And strings can read the core file suggesting it potentially inst a corruption issue?

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.