Bug 164711 - BIOS time is treated as UTC even when it's not
BIOS time is treated as UTC even when it's not
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2005-07-30 16:09 EDT by Florin Andrei
Modified: 2008-02-27 00:44 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-27 00:44:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Florin Andrei 2005-07-30 16:09:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
First off, I am not positive whether this is a kernel issue, but everything seems to point in that direction.
The problem started recently, around the same time as the release of the 1398 kernel version.

This is the setup:

[root@services ~]# cat /etc/sysconfig/clock

However, when the system boots up, time is off by several hours, pretty much like something believes the BIOS clock is UTC.
As soon as ntpdate kicks in, time is restored properly. As a result, there's a large jump in the log timestamps before and after ntpdate.

Of course, if ntpdate is not configured, time is off by several hours and stays that way.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. just boot up my fully updated FC4 system

Actual Results:  time is off by many hours until ntpdate runs successfully, or it stays off if ntpdate is not configured or misconfigured or fails

Expected Results:  well duh

Additional info:
Comment 1 Florin Andrei 2005-07-30 16:17:48 EDT
Sorry, my bad, it's not the kernel. I've another system that's fully updated
except the kernel (still on 1390) and it has the same problem.
Comment 2 Thomas Sprinkmeier 2005-08-05 07:24:13 EDT
Same problem here, running vanilla FC4 on a DELL Dimension 4700.
Comment 3 Florin Andrei 2005-08-08 02:11:08 EDT
Happens pretty much every time when installing a new system.
On a mail relay, Postfix stays somehow confused and does not get back to the
normal time even though ntpdate seems to bring back the system clock. As a
result, email header times are wrong.

The more I look at it, the worse it gets. Please fix.
Comment 4 Anil Kumar Sharma 2005-08-09 06:28:44 EDT
Same happening on kernel-smp-2.6.12-1.1387_FC4
Comment 5 Dave Jones 2005-08-26 05:29:32 EDT
I'm not convinced this is a kernel problem either, unfortunatly I have no idea
what could be the cause.  Maybe the glibc folks have some ideas.

Jakub ?
Comment 6 Jakub Jelinek 2005-08-27 05:00:09 EDT
glibc has nothing to do with the UTC correction of the hw clock.
That's what /sbin/hwclock is supposed to do.  On startup /etc/rc.d/rc.sysinit
calls it to set system clock from hw clock and on (clean) shutdown
/etc/rc.d/init.d/halt runs it again to set hw clock from system clock.
Comment 7 Karel Zak 2005-08-29 09:09:13 EDT
Do you see any error message when you run hwclock command? Can you found
something usefull in system logs?
Comment 8 Radim Cernej 2006-02-17 13:25:41 EST
Happens to me too, DELL Optiplex GX280.  I remember that when playing with
command line hw-clock commands, one had to use a speacial option for DELLs,
otherwise the command was failing / did nothing.  It is possible that Rehdat's
GUI does not specify this option, causing the problem we see.

Comment 9 Anil Kumar Sharma 2006-02-17 14:13:42 EST
Resolved for me since ... long back ... no special effors, nor fully updated box
except kernel (now 2.6.15-1.1831_FC4smp), gcc-4.0.2-8, kde-3.5.0, alsa-*-1.0.10,
and few packages. 
Comment 11 Florin Andrei 2007-02-14 13:01:22 EST
Seems fine for me now. I'm not sure what changed that made the bug go away.
Comment 12 Karel Zak 2007-03-14 16:47:53 EDT
Well, can we close this bug report?
Comment 13 petrosyan 2008-02-27 00:44:00 EST
Since there was no reply for almost a year and the bug reporter says that the
bug is fixed I am closing this bug.

Note You need to log in before you can comment on or make changes to this bug.