From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 19:26:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE40316A4CE; Tue, 24 Aug 2004 19:26:25 +0000 (GMT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FED343D31; Tue, 24 Aug 2004 19:26:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.160.193.218]) by out003.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040824192621.PJKV26805.out003.verizon.net@[192.168.1.3]>; Tue, 24 Aug 2004 14:26:21 -0500 Message-ID: <412B9648.2060102@mac.com> Date: Tue, 24 Aug 2004 15:26:00 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <200408241641.20389.4711@chello.at> <20040824164442.GE37217@ip.net.ua> <20040824164701.GF37217@ip.net.ua> <412B7C24.3040006@mac.com> <20040824174456.GA38418@ip.net.ua> <412B884F.1000004@mac.com> <20040824184009.GD38418@ip.net.ua> In-Reply-To: <20040824184009.GD38418@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [68.160.193.218] at Tue, 24 Aug 2004 14:26:20 -0500 cc: Christian Hiris <4711@chello.at> cc: freebsd-current@FreeBSD.org Subject: Re: Upgrade to 5.3-BETA1: make installkernel - Stop in /usr/src/sys/modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2004 19:26:26 -0000 Ruslan Ermilov wrote: > On Tue, Aug 24, 2004 at 02:26:23PM -0400, Chuck Swiger wrote: > [...] >> In the section quoted above by ">>> ", you state that "host doing build is >> the host doing an install". In Handbook 19.5.1, the host doing the install >> is not the host which did the build-- the host doing the install is >> NFS-mounting the software trees from the host which did the build. > > Earlier I said that the install host may be different from the build > host if and only if they are running the same __FreeBSD_version. > This is the only guaranteed way to do it. If __FreeBSD_version do > not match, then I suggested an alternative: install from host that > did a build. OK, I believe I understand what you are saying. I gather that the handbook article ought to mention these caveats, too. [ ... ] >> I buildworld/buildkernel under 4.5 on the build server, test >> the upgrade process until I am happy with the results, and then use NFS to >> export /usr/src and /usr/obj, and update not just the 4.3 boxes but the >> older 4.1 machines to 4.5. >> >> Is doing the equivalent today OK, or is it not supported? > > It never been OK. It may occasionally work, but is not guaranteed. It's been working fine for pretty much all of 4.x. Would running "mergemaster -p" on systems before the installkernel stage have helped make this work? > The reason is simple: the bootstrap-tools stage uses __FreeBSD_version > to determine a list of things that need to be bootstrapped. These > tools are used during both buildworld and installworld times. If > you change the OS, the expectations of installworld (that it's > running on the same __FreeBSD_version machine) could be wrong, and > you get what you get -- things may fail to install. The set of > such tools is quite small, the set of tools used during an install > is even smaller, so it's likely that things didn't break for the > duration of the whole RELENG_4 branch. The point still applies: > it's not guaranteed. OK, thanks for your explanation. I thought "mergemaster" was supposed to deal with upgrading the parts of the installed system (missing users, rc scripts, tools like make) which might be needed for the installkernel/installworld to run properly. I also seem to recall that the build system uses the executables from the newly built world when building the kernel; could one use the tools from the new world to handle the installation if the existing tools are not adequate? [ I suspect the answer is "What happens if the tools just built don't run on the kernel (or world) of the install machine because that box doesn't match the kernel/world of the build system?" I see.... ] Well, I've got all of my per-machine config info archived in CVS, so it's not the end of the world even if I do get surprised by something breaking, but being able to upgrade machines via NFS has been very convenient. > Another point: the build host (if you NFS > mount from it) should have its CPUTYPE unset or set to a lowest > common denominator of all CPUs in the cluster, so the code could > be run safely on all (possibly other) CPUs. This is understood, but the point is worth mentioning. -- -Chuck