From owner-freebsd-hackers Mon Jul 27 11:44:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11929 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 11:44:29 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11821 for ; Mon, 27 Jul 1998 11:43:59 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.8/8.8.7) id LAA25740; Mon, 27 Jul 1998 11:42:01 -0700 (PDT) (envelope-from dhw) Date: Mon, 27 Jul 1998 11:42:01 -0700 (PDT) From: David Wolfskill Message-Id: <199807271842.LAA25740@pau-amma.whistle.com> To: dhw@whistle.com, mike@smith.net.au Subject: Re: Checking RAM Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199807271825.LAA00633@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Mon, 27 Jul 1998 11:25:51 -0700 >From: Mike Smith >> However, as a follow-on to a discussion I was having with someone else >> (where I was doing a bunch of whining about the challenges I was having >> in "automatically" being able to determine the configuration of a given >> FreeBSD box), the random idea came up that *IF* the kernel could stash >> away the results of its probing in some way that might be amenable to >> access by suitably-privileged processes at times arbitrarily distant >> from re-boot (i.e, scannning logs & output of dmesg won't do the job), >> this *might* be sufficiently useful to warrant some effort. >Something like /var/run/dmesg.boot, perhaps? Yes, that's an excellent start -- thanks! However, unless I'm even less clueful than usual, that needs some augmentation if someone should be reasonably expected to take that file & be able to reconstruct the machine on which the file was created (assuming, say, "dump" backup images for all filesystems). For example, information about disk partitioning would seem to be necessary, as well as interpreting the "dmesg" output so someone could determine what cards go in what slots (assuming it makes a difference?). Please recall that the intended purpose is to be able to reconstruct the environment, assuming that (for whatever reason(s)) access to the original machines is not available (either for poking & prodding or logging in). Of course, I'm certainly open to comments like "this isn't really feasible" -- but it seems to me that it's just part of normal disaster recovery preparedness... and I'd think that folks have addressed the issue in some form previously.... Thanks again, david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message