make installworld fails on RELEASE6.4 amd64

[Ian Smith]

On Tue, 17 Mar 2009 13:05:17 +0700 (ICT) Olivier Nicole <on at cs.ait.ac.th> wrote:
 > > > I am facing a problem that I cannot solve when trying to reinstall
 > > > wolrd on 6.4 amd 64.
 > > More about this issue.
 > 
 > Regarding adjkerntz -i.
 > 
 > Places that are ahead of UTC don't need to do the adjkerntz -i after
 > rebooting in single user.

That's certainly not my experiance here (UTC+11 currently).  That got 
well burnt into my brain after y2k with FreeBSD 2.2.6, having to patch 
/etc/rc (on advice) to deal with a BIOS that thought 2000 was 1994 :)

 > Suppose you are in a time zone at UTC +7.
 > 
 > Boot in multiuser:
 > 
 > Wall clock=7:00
 > CMOS clock=7:00
 > TZ time=   7:00
 > UTC=       0:00

Right.  It appears that /etc/wall_cmos_clock exists there, yes?

 > >From 7:00 to 7:30 you build world, file created will have a creation
 > date of 0:00 to 0:30 UTC.

Well yes as UTC, but with wall_cmos_clock everything will show these 
files as local time (07:xx), just as any other files created multiuser.

 > Reboot in single user:
 > 
 > Wall clock=7:30
 > CMOS clock=7:30
 > UTC=       7:30 (no adjkerntz)

That's exactly WHY you want to run adjkerntz -i then, before anything 
that creates files is run, ie mergemaster, installworld .. but it only 
makes any difference if /etc/wall_cmos_clock does exist then of course.

So if you'd run adjkerntz -i, times would show the same as in multiuser.

 > Make install world, the install will be done with a UTC at 7:30, that
 > is after the build time of 0:00 to 0:30.
 > 
 > Reboot in multiuser:
 > 
 > Wall clock=7:45
 > CMOS clock=7:45
 > TZ time=   7:45
 > UTC=       0:45
 > 
 > Now if you look at the newly installed world, it will be in the
 > future, ahead by 7 hours: a file installed at 7:35 will be listed with
 > a time of 14:35. That is odd, but it works.

Sorta works, if you don't mind file (and log) timestamps not reflecting 
reality.  I'm fussy about chronology.  And then there's that 7 hour wait 
until those files become dated in the past, and so can be 'updated'.

 > Hence country ahead of UTC don't need adjkerntz -i

Sorry, but this demonstrates exactly why you DO need to run that when 
(ever) working single user, if you want file/log datestamps consistent.

I can't comment on i386/amd64 differences, but it's necessary on i386.

cheers, Ian