Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Jul 1998 11:42:01 -0700 (PDT)
From:      David Wolfskill <dhw@whistle.com>
To:        dhw@whistle.com, mike@smith.net.au
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: Checking RAM
Message-ID:  <199807271842.LAA25740@pau-amma.whistle.com>
In-Reply-To: <199807271825.LAA00633@dingo.cdrom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Mon, 27 Jul 1998 11:25:51 -0700
>From: Mike Smith <mike@smith.net.au>

>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807271842.LAA25740>