From owner-freebsd-current@FreeBSD.ORG Tue Aug 24 18:40:16 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 9171316A4CF for ; Tue, 24 Aug 2004 18:40:16 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D993F43D39 for ; Tue, 24 Aug 2004 18:40:15 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7OIe6EG047726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Aug 2004 21:40:07 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7OIe9o3038822; Tue, 24 Aug 2004 21:40:09 +0300 (EEST) (envelope-from ru) Date: Tue, 24 Aug 2004 21:40:09 +0300 From: Ruslan Ermilov To: Chuck Swiger Message-ID: <20040824184009.GD38418@ip.net.ua> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3yNHWXBV/QO9xKNm" Content-Disposition: inline In-Reply-To: <412B884F.1000004@mac.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new 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 18:40:16 -0000 --3yNHWXBV/QO9xKNm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 i= s=20 > the host doing an install". In Handbook 19.5.1, the host doing the insta= ll=20 > is not the host which did the build-- the host doing the install is=20 > NFS-mounting the software trees from the host which did the build. >=20 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. > Let's say I have one build machine, three multihomed firewall boxes which= =20 > only get updated for critical security problems which affect (IPFW, kerne= l,=20 > SSH), and several other FreeBSD systems running mail, WWW, etc which I=20 > update more frequently as downtime is less critical, and running more=20 > user-oriented services means more exposure. >=20 > Let's say they all started out at 4.1. I wait, update the build machine= =20 > regularly by following RELENG_4, and say around 4.3 decide I'm happy and= =20 > want to update all but the firewall machines via NFS. More time passes,= =20 > and the build machine gets up to 4.5 when a raft of OpenSSL/OpenSSL patch= es=20 > breaks loose. I buildworld/buildkernel under 4.5 on the build server, te= st=20 > the upgrade process until I am happy with the results, and then use NFS t= o=20 > export /usr/src and /usr/obj, and update not just the 4.3 boxes but the= =20 > older 4.1 machines to 4.5. >=20 > Is doing the equivalent today OK, or is it not supported? >=20 It never been OK. It may occasionally work, but is not guaranteed. 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. 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. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --3yNHWXBV/QO9xKNm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBK4uJqRfpzJluFF4RAkMJAJ4+3KoVGgO7LpA2bQMDX8LWQSKH+QCbBkzq sW6hM8dm4iT6AYv1CsVfRdU= =jt+t -----END PGP SIGNATURE----- --3yNHWXBV/QO9xKNm--