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

[Chuck Swiger]

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