From owner-freebsd-hackers  Fri Oct 31 16:56:23 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id QAA17443
          for hackers-outgoing; Fri, 31 Oct 1997 16:56:23 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from eng.svic.com ([207.88.47.170])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA17423;
          Fri, 31 Oct 1997 16:56:17 -0800 (PST)
          (envelope-from elh@eng.svic.com)
Received: from xy.svic.com (xy [192.168.4.6])
	by eng.svic.com (8.8.5/8.8.5) with ESMTP id QAA02711;
	Fri, 31 Oct 1997 16:56:12 -0800 (PST)
Received: from xy.svic.com by xy.svic.com (8.8.5) id QAA00276; Fri, 31 Oct 1997 16:56:12 -0800 (PST)
Message-Id: <199711010056.QAA00276@xy.svic.com>
To: "John S. Dyson" <toor@dyson.iquest.net>
cc: dg@root.com, bugs@FreeBSD.ORG, hackers@FreeBSD.ORG, elh@svic.com,
        elh@spnet.com
Subject: Re: 2.2.5 installation bug on 1gig machines 
In-reply-to: Your message of "Fri, 31 Oct 1997 19:46:23 EST."
             <199711010046.TAA00336@dyson.iquest.net> 
Date: Fri, 31 Oct 1997 16:56:12 -0800
From: Ed Hudson <elh@svic.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


folks,

	thanks for the suggestions and clarifications.

	however, am i incorrect in my assumption that
	i can from another (2.2.5) machine rebuild
	the boot floppy w/o bounce buffers (and w/o any of 
	the isa controllers that depend upon it) ?

	(in this case, internal access to the machine is
	the choice of last resort).

	btw, if i recollect correctly, i upgraded this
	machine from 2.2.1 to 2.2.2, all with the 1gig
	installed (2.2.2 just couldn't see the whole
	gig until i modified the kernel configuration
	and rebuilt).

	also, as a generic workaround, it would probably be
	usefull if at boot time i could say something like:

		boot: fd(0,a)/kernel -c MAXMEM=16384K

	thx,

		-elh

>    The problem with this is that the memory is already sized before
> 'userconfig' is called (it needs to be that way for various reasons). This
> basically means that we can't limit the memory during an install. You'll
> have to physically pull out some of the memory and/or replace it with
> lower density SIMMs until you've finished the installation and built a
> customized kernel.
> 
> -DG
> 
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project