Re: Updating sparc64 time_t, hostname not found

At 12:57 AM +0200 3/19/04, Wafa M. Hadidi wrote:
>
>On Friday 19 March 2004 00:28, Garance A Drosihn wrote:
>
>>  The fact that you are seeing this at the earlier stage is probably
>  > very significant, but I am not sure what it means...
>
>Though I am not sure, but here is what I think: some files used
>32_bTT and have been updated to use 64_bTT instead.

But how would that have happened?  Right now you have a system
where the programs are all 32-bTT (because they all work right
when you reboot into the old kernel).  So, how would they get
to be 64-bTT?

>These files lack the ability to detect my installation type
>(32 or 64) and they preassume that 64 is the default during
>the makeworld phase.

Programs only know the time_t they were compiled with, so you
would need to recompile them to get a 64-bTT version.  Besides,
if you had a 32-bTT kernel with 64-bTT applications, then I
suspect you would see timestamps VERY different than 1970.
(I guess I could check that...).

>  > What happens if you reboot into your previous kernel?  Do you
>  > still get the odd time-stamp results from 'ls'?
>
>Rebooting to the old kernel solves everything, ls shows correct
>time-stamps and ntpdate syncs to the right time.

Hmm.  Okay.  Something somehow went wrong with the building of
your kernel, although I don't know how that would happen.  Do you
have KERNCONF set in your /etc/make.conf file?  Do you specify
it when you do 'make buildkernel'/'make installkernel'?

I would say to first get rid of the /boot/kernel that did not
work, and move /boot/kernel.bak to /boot/kernel.  So, you would
be back to starting with the kernel that works.  Either that,
or move /boot/kernel to /boot/kernel.32b, so you won't lose
it in later installs!

Then check /usr/src/sys/sparc64/compile and make sure there are no
left-over kernel folders in there.  Remove anything you have in
there (except maybe a CVS directory, if you have that).
Re-check
     grep __time_t /usr/src/sys/sparc64/include/_types.h

(again) just to make sure it's 32-bit, and then redo the:
     cd /usr/src
     make cleanworld
     make buildworld
     make buildkernel
     make installkernel
     reboot

steps, and see if that kernel works any better for you.  I do not
know why you should have to do all of this, but there was something
which did not work the way I expected it to work.  I'm just trying
to get rid of whatever that might be...

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu