Peter Jeremy wrote: > On 2007-Apr-27 14:00:21 -0400, Kris Kennaway <kris_at_obsecurity.org> wrote: >> On Fri, Apr 27, 2007 at 08:31:16AM -0700, Tom Cumming wrote: >>> One possibility is to hard code dumpdev in the kernel, then boot that >>> kernel. >> I don't know many different ways I can say "there is no way to do it". > > I think Tom is saying that he needs to do something that _used_ to be > possible. Normally the Project is careful to avoid regressions so > this was a surprise to me as well. (It looks like it's demise wasn't > clearly spelt out at the time). > > Since dumpdev is now intertwined with geom and the geom tasting is > quite late in the boot process, I agree that the current crashdump > code does not seem amenable to use early in the boot process. > > Having a kernel crash before it reaches userland is not unheard of. > Whilst it may be possible to debug this using DDB or remote GDB in > some cases, I can think of two cases where this is not practical: > 1) It is a production server that can't be left down for extended periods. > 2) It is a remote system without remote console access. > > Lets put the original question slightly differently: How can the > kernel state be saved if the kernel crashes before it's possible to > invoke dumpon(8)? IMHO, "there is no way to do it" is not a > satisfactory answer for the reasons above. > Implement network crashdumps. This involves writing a new, separate, stripped down network stack, dealing with network configuration headaches, etc. It it will address the problem, though, albeit with a lot of development effort and pain. ScottReceived on Fri Apr 27 2007 - 20:29:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:09 UTC