Date: Sat, 28 Apr 2007 08:21:16 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-current@freebsd.org, Tom Cumming <tcumming123@gmail.com>, Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: Panic on boot. How do I get a kernel dump. Message-ID: <20070427222116.GG840@turion.vk2pj.dyndns.org> In-Reply-To: <20070427180021.GA57409@xor.obsecurity.org> References: <de193d070704231519h671193emdd5f8673246559ad@mail.gmail.com> <20070426204602.GA81382@keltia.freenix.fr> <de193d070704261535k11e5de1eh12842a4ab340a971@mail.gmail.com> <20070427012401.GZ2445@obelix.dsto.defence.gov.au> <20070427013742.GA51877@troutmask.apl.washington.edu> <20070427014317.GA17436@xor.obsecurity.org> <20070427030017.GA52347@troutmask.apl.washington.edu> <20070427031124.GA18527@xor.obsecurity.org> <de193d070704270831y6f57e559xfaf036338c263100@mail.gmail.com> <20070427180021.GA57409@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--OBd5C1Lgu00Gd/Tn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Apr-27 14:00:21 -0400, Kris Kennaway <kris@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. --=20 Peter Jeremy --OBd5C1Lgu00Gd/Tn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGMndc/opHv/APuIcRAkxVAJ4yamtEozvYTbvFxfoQdZDiw/WM6wCdEYII sOndB7H6J/W9F0dY/qOzrpY= =afFe -----END PGP SIGNATURE----- --OBd5C1Lgu00Gd/Tn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070427222116.GG840>