Date: Tue, 14 Feb 2006 02:43:08 -0500 From: Vinny Abello <vinny@tellurian.com> To: Chuck Swiger <cswiger@mac.com> Cc: freebsd-stable@freebsd.org Subject: Re: clock reverts to epoch on boot? Message-ID: <7.0.1.0.2.20060214022950.0966af58@tellurian.com> In-Reply-To: <7.0.1.0.2.20060213222648.08a4a9a0@tellurian.com> References: <7.0.1.0.2.20060213212221.04c7da20@tellurian.com> <43F14537.8080907@mac.com> <7.0.1.0.2.20060213220336.08433b78@tellurian.com> <7.0.1.0.2.20060213221518.08c60e10@tellurian.com> <43F14DA3.8070602@mac.com> <7.0.1.0.2.20060213222648.08a4a9a0@tellurian.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:28 PM 2/13/2006, Vinny Abello wrote:
>At 10:25 PM 2/13/2006, Chuck Swiger wrote:
>>Vinny Abello wrote:
>>[ ... ]
>> > Nevermind. I just answered my own question. I should have RTFM more
>> > carefully. :)
>>
>>:-)
>>
>> > If CPUTYPE is defined in your /etc/make.conf, make sure to use the
>> > "?=" instead of the "=" assignment operator, so that
>> buildworld can
>> > override the CPUTYPE if it needs to.
>> >
>> > I am thinking if I change to
>> >
>> > CPUTYPE?=pentium4
>> >
>> > I will be ok. Does that sound correct or am I still barking up the wrong
>> > tree?
>>
>>If you weren't having any problems, feel free to experiment. Since you don't
>>gain much by using the machine-specific compiler optimizations for
>>the kernel,
>>it is worth turning them off to see whether the resulting kernel
>>still has the
>>same problem...
>
>Will give it a shot and see what happens. So far buildworld isn't
>using CPU specific optimizations with the CPUTYPE?=pentium4 as
>documented so I have a feeling that will fix my problem. I actually
>started having problems after rebuilding world from this source a
>second time with (what I thought) were more optimized compiler
>settings. Obviously not if they cause it to break. :) My kernel is
>the same from when it was working from the original CVSUP and
>original buildworld so I think I'll be ok with that. I'll rebuild it
>to be safe anyway though. Thanks again for your help! :)
Just following up on this further. It seems the problem was
a little more complex (or simple) than this... I had the same problem
despite what settings I used for CPUTYPE in my make.conf file. As I
stated earlier, booting into single user mode works fine and I have
the correct date. I started looking at what was loading on startup
when going multiuser. I basically commented out my whole
rc.conf.local file except for SSH and then time was correct upon
bootup! I put everything back except for time related programs, but
the problem came back. I uncommented all my time stuff and on a
hunch, I commented out only the line to enable a Backup Exec port
from starting. Having this disabled made it so on every startup my
system time is now correct. I had noticed an error when that agent
was starting since upgrading which I was going to look into. I know
it is actually a Linux binary and relies on Linux compatibility in
FreeBSD. I'm not sure if the binary was just damaged or if my Linux
binary compatibility or some libraries are out of sync. Regardless, I
seem to have found the problem... I need to update to the newest
agent from Veritas/Symantec anyway instead of this port, although I
don't know if that works well either. I'll look into that tomorrow
and look into possibly rebuilding my Linux binary port containing the
libraries as well, although that was really the only reason I had it
installed and my not need it.
What is odd is my kernsecurelevel is set to 2 and the time still gets
massively adjusted, incorrectly somehow to boot. I think that binary
was run in the startup rc scripts prior to kernsecurelevel being
raised from -1 to 2 though. Actually, I'm sure of that now, so nevermind.
Thanks again for the help. I just wanted to post back what I found to
share with others in case someone ever runs into the same oddity.
P.S. I CVSUP'ed STABLE, built the kernel and did buildworld with
CPUTYPE?=prescott which more accurately matches my actual CPU type.
No problems at all to report. :)
Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
"Courage is resistance to fear, mastery of fear - not absence of
fear" -- Mark Twain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7.0.1.0.2.20060214022950.0966af58>