make installworld fails on RELEASE6.4 amd64
on at cs.ait.ac.th
Sun Mar 15 01:31:33 PDT 2009
> I am facing a problem that I cannot solve when trying to reinstall
> wolrd on 6.4 amd 64.
More about this issue.
RELEASE_6.4 i386 is imune of this problem.
I did a make -d A installworld and it seems that it is all about
It's a link to /usr/src/sys/i386/include. This directory is created at
the first installation of FreeBSD.
When CMOS clock is the wall clock and when one is located ahead of UTC
(Thailand is UTC+7), during the first installation of a distribution,
the machine boots with UTC=CMOS clock, hence creating the directory
hierarchy 7 hours ahead of time.
The link /usr/obj/usr/src/sys/boot/i386/boot2/machine is created by
make buildworld, after the first boot of the newly installed system,
after the time zone has been set, so it is created with the right
If one does an installworld between the 7 hours interval, when
installing /usr/src/sys/boot/i386/boot2, it detects that the directory
/usr/src/sys/i386/include pointed by
/usr/obj/usr/src/sys/boot/i386/boot2/machine is newer than the objects
being installed, and it tries to rebuild the object.
My wild guess is that on i386, make installworld looks at the
modification date of the link
/usr/obj/usr/src/sys/boot/i386/boot2/machine; while on amd64 make
installworld looks at the modification date of the directory
/usr/src/sys/i386/include pointed by the link. Hence the different
This is annoying for people leaving ahead of UTC, that will install a
new distribution, cvsup the release, build and installworld, during
the interval of 7 hours. I think that users behing UTC will not be
What I did is: during the installation of the distrubition I set back
the CMOS clock to UTC time, and when FreeBSD was done installing from
the CD, I reset the CMOS clock to the wall clock. It worked, but it's
not very nice.
I am curious to have experts opinion on the different behaviour of
make regarding the modification date of the link
More information about the freebsd-questions