FreeBSD Y2K compliance on non-compliant hardware

FreeBSD Y2K compliance on non-compliant hardware

Post by Irvine Shor » Sun, 11 Jul 1999 04:00:00



Hi All

I have a number of servers out there that will understand dates in 2000 no
problem, but if left to their own devices the date will roll over to 1900,
not 2000.

There are lots of utils out there that will fix this for Windows and I
believe Linux too. Some kind of a daemon or kernel patch that if it sees the
hardware clock saying something ridiculous it sets the time right.

I've searched the questions archive and the FreeBSD Y2K statement and
although this question has been asked I haven't seen it answered.

Thanks in advance for any comments & suggestions,

--
Regards,

Irvine Short

IS Consulting
196 Longmarket Street,
Cape Town
tel 082 494 3828

 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by Steven G. Kar » Sun, 11 Jul 1999 04:00:00




Quote:> Hi All

> I have a number of servers out there that will understand dates in 2000 no
> problem, but if left to their own devices the date will roll over to 1900,
> not 2000.

> There are lots of utils out there that will fix this for Windows and I
> believe Linux too. Some kind of a daemon or kernel patch that if it sees the
> hardware clock saying something ridiculous it sets the time right.

> I've searched the questions archive and the FreeBSD Y2K statement and
> although this question has been asked I haven't seen it answered.

There is a Y2K statement somewhere at www.freebsd.org.

If you want to keep the machines sync'd now and in the\
future, then use xntpd.

man xntpd.

--
Steve

 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by Irvine Shor » Mon, 12 Jul 1999 04:00:00


Hi Steve

----- Original Message -----

> There is a Y2K statement somewhere at www.freebsd.org.

This doesn't say anything about software fixes for buggy hardware

Quote:

> If you want to keep the machines sync'd now and in the\
> future, then use xntpd.

I had a look at the man page for xntpd but it didn't mention what xntpd
would do if the hardware clock suddenly went 100 years in reverse.

In any case, xntpd only updates the clock periodically as far as I can see
so there could be quite a long time before the clock was set right.

The software fixes for other OS's (if you want to honour them with that
term) run constantly in the background waiting for the hardware clock to
*up and instantly correct it if necessary. They also check for
incorrect leap years etc.

Now, i believe there is such a thing for Linux. Does anyone have any plans
to port it? I might be able to hack it myself, but it certainly wouldn't be
pretty.

 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by Steven G. Kar » Mon, 12 Jul 1999 04:00:00




> Hi Steve
> ----- Original Message -----

>> If you want to keep the machines sync'd now and in the\
>> future, then use xntpd.

> I had a look at the man page for xntpd but it didn't mention what xntpd
> would do if the hardware clock suddenly went 100 years in reverse.

> In any case, xntpd only updates the clock periodically as far as I can see
> so there could be quite a long time before the clock was set right.

xntpd can sync all your systems to 1 specific machine.  This
reduces you to worrying about the hardware clock on 1 machine.
You can test that 1 machine to see if its hardware clock will
become screwing.

Quote:> The software fixes for other OS's (if you want to honour them with that
> term) run constantly in the background waiting for the hardware clock to
>*up and instantly correct it if necessary. They also check for
> incorrect leap years etc.

If the system's BIOS can't handle the date as yyyy/mm/dd, then it
would system to me that you'll have problems if you turn the
machine off, then on.  If the BIOS reports yy/mm/dd, I suspect
that FreeBSD would DTRT but I can't confirm this at the moment.

Quote:> Now, i believe there is such a thing for Linux. Does anyone have any plans
> to port it? I might be able to hack it myself, but it certainly wouldn't be
> pretty.

Happy hacking ;-)  Report back here with the outcoming.
--
Steve
 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by Irvine Shor » Mon, 12 Jul 1999 04:00:00


Well, I had a few quiet moments alone with a HP NetServer 4/100 LC and tried
a few things.

I let the date roll over to 2000 with the machine off, and when it booted up
DOS reported 1980.

I turned the date back and tried it again with FreeBSD running, and it
rolled over correctly to 2000. I rebooted again, this time into the setup
and it read 1900.

So, it seems that FreeBSD if it sees 1900 assumes it is 2000, which is all
well and good. I have a little DOS program that puts the real-time clock
through it's paces and this particular one is fine as far as leap years are
concerned, so in this case we're OK.

Does anyone know what FreeBSD will do if it encounters a RTC that screws up
leap years?





> > Hi Steve
> > ----- Original Message -----

> >> If you want to keep the machines sync'd now and in the\
> >> future, then use xntpd.

> > I had a look at the man page for xntpd but it didn't mention what xntpd
> > would do if the hardware clock suddenly went 100 years in reverse.

> > In any case, xntpd only updates the clock periodically as far as I can
see
> > so there could be quite a long time before the clock was set right.

> xntpd can sync all your systems to 1 specific machine.  This
> reduces you to worrying about the hardware clock on 1 machine.
> You can test that 1 machine to see if its hardware clock will
> become screwing.

> > The software fixes for other OS's (if you want to honour them with that
> > term) run constantly in the background waiting for the hardware clock to
> >*up and instantly correct it if necessary. They also check for
> > incorrect leap years etc.

> If the system's BIOS can't handle the date as yyyy/mm/dd, then it
> would system to me that you'll have problems if you turn the
> machine off, then on.  If the BIOS reports yy/mm/dd, I suspect
> that FreeBSD would DTRT but I can't confirm this at the moment.

> > Now, i believe there is such a thing for Linux. Does anyone have any
plans
> > to port it? I might be able to hack it myself, but it certainly wouldn't
be
> > pretty.

> Happy hacking ;-)  Report back here with the outcoming.
> --
> Steve

 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by Justin Trip » Tue, 13 Jul 1999 04:00:00


There were a few suggestions made for this problem, but I think some
clarification needs to be made.  Two different situations can occur
that could cause the date to incorrectly roll over.

1. The computer is on.

2. The computer is off.

If the computer is on, it does not matter whether or not the hardware
CMOS clock can roll over or not.  Most unix operating systems (and probably
most operating systems), maintain their own clock in the kernel of the OS.
The CMOS clock is left to its own devices to do whatever it wants.  So, if
your computer is on Dec 31, 1999, and it is running a Y2K unix, then the
kernel clock will roll over.  You will not even need to know what the CMOS
clock is doing until your next reboot.  With the stability of some unix
boxes, this could be a while.  (I usually get about 110 days between reboots
on a FreeBSD box -- and all of the reboots have been due to power failure of
my local utility company).

The next reboot could be a problem -- but actually the BSD box uses the CMOS
clock just to get started.  Once the OS is running you can set the date to
anything that fits in time_t (1970-2038).  There are a few things that can
be done to fix the problem.  

1. Does the CMOS clock work in 2000?  This is not the same question as if it
rolls over.  That is a separate issue.  If the CMOS clocks works, then
have the machine from a cron job periodically update the CMOS clock with
the value of the system clock (kernel clock).  If rollover does not work,
this will fix the problem if you need the clock set into 2000.  This is a good
thing to do anyway, if the machine runs xntpd anyway since the system clock
would be more accurate than the CMOS clock and it would reduce the amount of
drift that would need to be corrected after a reboot.

You probably could use adjkerntz -a to do this.

2. Nothing works -- CMOS don't roll over and it will work in 2000.  No problem.
I have a 486 that does not even have a CMOS clock.  When it boots it always
thinks it 1994.  The fix is to use the xntpd package.  You need a machine to
serve as a time server -- xntpd is both server and client, so it is not too
hard to setup.  When your clock-challenged machine boots, you need to reset
the date to something useful as soon as possible.  xntpd attempts to slowly
and carefully reset the date.  As a result of this, if the time is too
far off 1000 seconds or more (i.e. 16 minutes) it automatically gives up.
So, you need to be more radical in setting the time.  ntpdate can set the
time to a more reasonable value.  So use ntpdate <ntp server> and follow that
up with xntpd and your machine will have the time of whatever the time
server has.

So you need ntp which can be obtained from the port collection or
www.ntp.org.

Now if the computer is going to be off for the roll over, then you can use
slighty different methods.

1. Does CMOS work in 2000?  If so, and you know that the machine will be
off (The University I work for is requiring that all machines be powered down
Dec28 through Jan 2) -- then there is no reason why you could not set the
date a head and then fix it with xntpd/ntpdate at boot time.  This would be
following suggestion 2 from above.

2. If the clock does not work, then you would definitely need to suggestion
2 from above.

Note that networking is required to use ntp.

I am not sure that you will want a patch or something that enforces some
policy based on time that seems ridiculous.  Y2K probably seemed ridiculous
to those who wrote the code that is buggy for us now.  But since the unix
Epoch starts in 1970, anytime before then can be mapped to atleast 1970.

                                .justin.

: Hi All

: I have a number of servers out there that will understand dates in 2000 no
: problem, but if left to their own devices the date will roll over to 1900,
: not 2000.

: There are lots of utils out there that will fix this for Windows and I
: believe Linux too. Some kind of a daemon or kernel patch that if it sees the
: hardware clock saying something ridiculous it sets the time right.

: I've searched the questions archive and the FreeBSD Y2K statement and
: although this question has been asked I haven't seen it answered.

: Thanks in advance for any comments & suggestions,

: --
: Regards,

: Irvine Short

--
------------------------------------------------------------------------

Configurable Computing Laboratory Research Assistant      CB 461 x8-7206
Electrical and Computer Engineering Department  Brigham Young University

 
 
 

FreeBSD Y2K compliance on non-compliant hardware

Post by David Malo » Thu, 15 Jul 1999 04:00:00



>I had a look at the man page for xntpd but it didn't mention what xntpd
>would do if the hardware clock suddenly went 100 years in reverse.

If the machine is up and running at the time the kernel clock should
roll over correctly as I think the kernel keeps time independantly
of the RTC. Nothing but the kernel is interested in the BIOS clock,
which is the thing which might roll back 100 years - but I think
the next time the kernel writes the date back into the BIOS and
the RTC it should set it correctly.

The kernel time should definitely tick forward if you're running
xntpd, and if a machine has to reboot you should set the clock from
several sources using ntpdate when you reboot to ensure that the
clock is close enough to correct for xntpd to do its job>

        David.