Re: problems during upgrade to RELENG_5

On Wed, Aug 25, 2004 at 02:09:19PM +0200, Harti Brandt wrote:
> On Wed, 25 Aug 2004, Tim Hawkins wrote:
> 
> TH>On Tuesday 24 August 2004 17:36, Ruslan Ermilov wrote:
> TH>
> TH>I had the same problem without using make includes, the result of an 
> TH>installworld failure. I had to copy the version of genatmtree from /usr/obj 
> TH>to userland in order to be able to rebuild world to fix it. 
> TH>
> TH>I also had the same problem with "make" where I could not rebuild anything 
> TH>untill I had copied /usr/obj version to userland
> 
> Perhaps osreldate.h gets clobbered too early in the install process. If 
> the install process breaks at some point osreldate may contain the new 
> FreeBSD version already. If the user then removes /usr/obj and buildworlds 
> again, the tools won't get build because Makefile.inc1 gets the wrong 
> BOOTSTRAPPING version.
> 
> Just a guess.
> 
Yes, I remember this exactly happening to some users.  But it does
not change the fact: their build systems were broken as a result,
and a working and consistent build system is a strong prerequisite
for a successful buildworld.

In the past, there was no such thing like OSRELDATE, and we could
upgrade from any supported __FreeBSD_version system.  Some developers
didn't like this, and insisted on a more granular bootstrapping
procedure: i.e., if you've just upgraded your world and kernel, and
try to "make buildworld" again using the same sources, it shouldn't
bootstrap anything in the bootstrap-tools stage.  This is what is
implemented right now, and the drawback is that it made broken build
systems much more fragile (read: if your /usr/include/osreldate.h
doesn't match reality, chances are very high now that buildworld
will fail).  For those with broken build systems, we still have an
opportunity to cheat by setting OSRELDATE to 0.

For anyone upgrading a lot of different __FreeBSD_version machines
in the cluster (there's no 100% guarantee it will work), I recommend
putting OSRELDATE=0 to /etc/make.conf on the build machine.  Chuck,
if you're reading this, it affects you as well.  The guarantee in
this case would probably be 99%.

By setting OSRELDATE=0, you're telling your buildworld/buildkernels:
"Hey, you two, you and your "install" counterparts should be able to
run on the lowest supported __FreeBSD_version system."  Unfortunately,
this doesn't do the magic -- there're still a lot of things to
consider: bootstrap-tools are bootstrapped using the build host's
environment, using its /usr/include and /usr/lib.  If, for example,
your build host has libc with some new syscall, and some of the
bootstrap-tools use this syscall, the resulting static binary (yes,
all of the bootstrap-tools are statically linked to be agnostic to
in-place library upgrades), and your install host's kernel doesn't
know about it, running such a tool will result in ENOSYS.

By considering all of this, let me tell this once again: it's much
more safer to use the build host to install stuff, by NFS mounting
remote /, /usr, and /var partitions read-write, and installing with
DESTDIR pointing to a remote root.


Cheers,
-- 
Ruslan Ermilov
ru_at_FreeBSD.org
FreeBSD committer