From owner-freebsd-hackers Mon Jul 27 13:10:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA27823 for freebsd-hackers-outgoing; Mon, 27 Jul 1998 13:10:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27759 for ; Mon, 27 Jul 1998 13:10:23 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id WAA10805; Mon, 27 Jul 1998 22:09:35 +0200 (MET DST) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Mon, 27 Jul 1998 22:09:35 +0200 (MET DST) Mime-Version: 1.0 To: David Wolfskill Cc: mike@smith.net.au, freebsd-hackers@FreeBSD.ORG Subject: Re: Checking RAM References: <199807271842.LAA25740@pau-amma.whistle.com> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 27 Jul 1998 22:09:34 +0200 In-Reply-To: David Wolfskill's message of "Mon, 27 Jul 1998 11:42:01 -0700 (PDT)" Message-ID: Lines: 68 X-Mailer: Gnus v5.5/Emacs 19.34 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id NAA27780 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Wolfskill writes: > >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?). If you're running a DEVFS/SLICE system, disk slices and partitions will be probed in a manner similar to "real" devices and output from this process will appear in dmesg.boot: sd0: probing for MBR.. rejected.. Slice includes MBR sd0: probing for disklabel. . part a, start=0, size=131072 part b, start=131072, size=1048576 part d, start=3932160, size=4958600 part e, start=1179648, size=131072 part f, start=1310720, size=524288 part g, start=1835008, size=1048576 part h, start=2883584, size=1048576 sd1: probing for MBR.. rejected.. Slice includes MBR sd1: probing for disklabel. . part e, start=0, size=524288 part f, start=524288, size=1572864 part g, start=2097152, size=10560565 sd2: probing for MBR.. part 1, start=63, size=2104452 sd2s1: attaching disklabel.. part e, start=0, size=524288 part f, start=524288, size=1580164 In the non-SLICE case, I don't see any other solution than 'cat /etc/fstab' and a few judicious disklabel(8) runs. As to "what cards go in what slots", it's only relevant for PCI cards. You'll notice PCI devices have "on pcix.xx.x" at the end of the probe line: de0: rev 0x22 int a irq 15 on pci0.9.0 vga0: rev 0x70 int a irq 9 on pci0.10.0 ahc0: rev 0x00 int a irq 12 on pci0.11.0 ahc1: rev 0x00 int a irq 11 on pci0.12.0 The first number ('0'in 'pci0') is the bus number; the second is the slot number. In my case, the ordering of the cards is highly relevant, since the order in which the SCSI adapters are probed determines the order in which the disks are attached. DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message