A recipe for disaster (aka crash dump analysis)

[Tim Gardner]

Kees Cook wrote:
> Hi Tim,
> 
> On Thu, Feb 19, 2009 at 07:57:50AM -0700, Tim Gardner wrote:
>> I'm about to start a wiki page that describes how to install the
>> necessary infrastructure for Jaunty crash dump acquisition and analysis.
>> One file that would make analysis much easier is to have available the
>> original uncompressed, unstripped vmlinux. I propose modifying the
>> Jaunty server package such that it is stored in /lib/modules/`uname -r`.
>> Any objections (or better ideas) ? IMHO servers are not typically disk
>> space limited, so the extra couple of MB doesn't seem like an undue
>> burden. Plus, I'm lazy and don't really want to produce yet another
>> package like linux-image-server-debug.
> 
> We used to have linux-image-debug-*:
> $ apt-cache search linux-image-debug
> ...
> linux-image-debug-2.6.24-23-server - Linux kernel debug image for version 2.6.24 on x86/x86_64
> linux-image-debug-generic - Linux kernel debug image for generic kernel image
> linux-image-debug-server - Linux kernel debug image for server kernel image
> 
> We should just put that back, and use a Recommends to pull it in with
> the regular kernel.  Producing the -debug kernels should (hopefully)
> be trivial -- it just copies out vmlinux before doing the strip/compress.
> In fact, if you worked with pitti, perhaps you could get dh_strip to do the
> work and have the -dbgsym packages built for the kernel instead, for free.
> 
> I disagree that servers aren't diskspace limited -- think of little
> routers, etc.
> 
> Why is this only for servers?  Don't we want crash dumps for desktop too?
> 
> -Kees
> 

Hmm, you missed the part about me being lazy :)

So, if I produce linux-image-debug packages, then the argument about
being server specific is moot (as is the disk space issue). There is
already a linux-crashdump meta package, which I could abstract to be
flavour specific as well as add the linux-image-debug dependency. Do you
think that would be sufficient?

rtg
-- 
Tim Gardner tim.gardner at canonical.com