Kernel crash before dumpon

Lowell Gilbert freebsd-questions-local at
Tue Nov 25 12:02:32 PST 2008

Frank Solensky <frank at> writes:

Wow.  Frank Solensky.  Long time no see.

> I'm trying to get a dump off a machine with a 7.1-beta2 kernel that's
> been crashing during the boot process, following the instructions on
> I've recompiled the kernel with "-g" but no vmcore file appears so I'm
> assuming that the crash occurs before dumpon is executed.
> The page includes the following suggestion on how I might be able to
> proceed:
>         Alternatively, the dump device can be hard-coded via the
>         dump clause in the config(5) line of a kernel configuration
>         file. This approach is deprecated and should be used only
>         if a kernel is crashing before dumpon(8) can be executed.
> I tried adding
>         config dump "/dev/ad4s3b"
> to the configuration file but that option appears to be no longer
> supported: the config command gives an error message of:
>         root/dump/swap specification obsolete
> Is the paragraph above obsolete?  If so, what's the preferred way to
> collect the dump?

Yep, it looks like the config(8) code to handle that has been gone for a
while.  At a quick glance, I can't figure out where the dump device is
chosen, but it's supposedly iterating through devices looking for
something that would work.  Sticking in a device closer to the top of
the search order might help.  I suppose it's possible that just sticking
in an appropriately formatted USB disk might help.

Enabling minidumps would let you get away with a smaller space for
storing the dump, which would be useful if you have some space to throw
at it.  Alternatively, in the same spot I would be tempted to build a
separate disk just for debugging this particular problem, making sure to
leave space for a swap partition close to the front.

Using DDB might be an option, but I suspect that if you're having
trouble getting a dump, you'll have problems dropping to a live debugger
as well.

All of my above advice is a bit shot-in-the-dark; if no one else
suggests anything better, you may want to go to the freebsd-hackers
list, or look at the cvs logs for whoever's modified the dump code in
the last year or so.

Good luck.
Lowell Gilbert, embedded/networking software engineer, Boston area

More information about the freebsd-questions mailing list