Re: Upgrade to 5.3-BETA1: make installkernel - Stop in /usr/src/sys/modules

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.

> Let's say I have one build machine, three multihomed firewall boxes which 
> only get updated for critical security problems which affect (IPFW, kernel, 
> SSH), and several other FreeBSD systems running mail, WWW, etc which I 
> update more frequently as downtime is less critical, and running more 
> user-oriented services means more exposure.
> 
> Let's say they all started out at 4.1.  I wait, update the build machine 
> regularly by following RELENG_4, and say around 4.3 decide I'm happy and 
> want to update all but the firewall machines via NFS.  More time passes, 
> and the build machine gets up to 4.5 when a raft of OpenSSL/OpenSSL patches 
> breaks loose.  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.
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,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer