Upgrade to 5.3-BETA1: make installkernel - Stop in
/usr/src/sys/modules
Chuck Swiger
cswiger at mac.com
Tue Aug 24 12:26:26 PDT 2004
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
More information about the freebsd-current
mailing list