From owner-freebsd-stable Thu Aug 15 6:55: 2 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C9E37B400 for ; Thu, 15 Aug 2002 06:54:56 -0700 (PDT) Received: from hermes.pressenter.com (hermes.pressenter.com [209.224.20.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD4C43E84 for ; Thu, 15 Aug 2002 06:54:51 -0700 (PDT) (envelope-from nospam@hiltonbsd.com) Received: from [209.224.35.188] (helo=daggar.sbgnet.net) by hermes.pressenter.com with smtp (Exim 3.16 #1) id 17fL5J-0001no-00 for freebsd-stable@freebsd.org; Thu, 15 Aug 2002 08:54:45 -0500 Date: Thu, 15 Aug 2002 08:54:40 -0500 From: Stephen Hilton To: freebsd-stable@freebsd.org Subject: Re: Need instructions: build kernel on one machine; install on another Message-Id: <20020815085440.45f1d5fc.nospam@hiltonbsd.com> In-Reply-To: <5.1.0.14.2.20020813084802.037d9498@magpie.zpfe.com> References: <5.1.0.14.2.20020813084802.037d9498@magpie.zpfe.com> Organization: HiltonBSD.com X-Mailer: Sylpheed version 0.8.0 (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cheers, This subject of building on one machine and distributing via NFS (/usr/src, /usr/obj) has come up again. Most writers are describing this as a "just works" type thing, but I have had problems in the past, that if still present, could foul up another's attempts to do this. Possibly some clarification is necessary for the list? In the *past* I have installed from my FreeBSD Services 4.5 DVD, then cvsupd and built world on my main "builder" workstation to 4.5-STABLE. This machine has processor optimizations in its make.conf during its update from 4.5-RELEASE to 4.5-STABLE like: /etc/make.conf on PIII "builder" machine --------------------snip---------------------- CPUTYPE=i686 CFLAGS= -O -pipe COPTFLAGS= -O -pipe --------------------snip---------------------- Now "builder" is up to date, and I want to build for a P60 machine on my LAN. I change the /etc/make.conf on "builder" to this processor type: --------------------snip---------------------- CPUTYPE=i586 CFLAGS= -O -pipe COPTFLAGS= -O -pipe --------------------snip---------------------- I cd to /usr/obj and chflags and rm -rf its contents, then cd /usr/src and make cleandir twice. "builder" is ready to build for the P60 box, so I run buildworld and buildkernel KERNCONF=P60kernel. Now I NFS mount from "P60" to "builder" (/usr/obj /usr/src) and on "P60" from /usr/src I invoke the: make installkernel KERNCONF=P60kernel This runs through OK. Now on "P60" I invoke the "make installworld" and it dies very early in the installworld process. I do not have the exact error handy, but it seems to involve basic build/install tools failing due to hosed processor optimizations for a PIII in tools that are being used to installworld on a P60 processor. The same P60 box will update fine if I put the src on it and run the buildworld/kernel/installworld process locally. And another PIII based system will work fine when I tune the make.conf's and do the update via NFS mounting to "builder". Is this a know problem (at least by me :-), and has it been corrected in more recent versions (4.6 or "better"). If not, possibly an addition to this thread might help someone else save some time in the future? I have read in other threads that the processor optimizations via make.conf are not that important for performance enhancement at this time, but that GCC 3.1 will change this in the near future (FreeBSD 5). If this problem that I have had in the past with using processor optimizations on a "builder" machine, then NFS mounting client machines to for updating is valid, would this not become a more commen problem seen on the lists? Regards, Stephen Hilton nospam@hiltonbsd.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message