Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Aug 2004 21:40:09 +0300
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Chuck Swiger <cswiger@mac.com>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: Upgrade to 5.3-BETA1: make installkernel - Stop in /usr/src/sys/modules
Message-ID:  <20040824184009.GD38418@ip.net.ua>
In-Reply-To: <412B884F.1000004@mac.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040824184009.GD38418>