Bug 164711

Summary:	BIOS time is treated as UTC even when it's not
Product:	[Fedora] Fedora	Reporter:	Florin Andrei <florin>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED WORKSFORME	QA Contact:	Ben Levenson <benl>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	davej, tsp.redhat.com, wtogami, xplusaks
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-02-27 05:44:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Florin Andrei 2005-07-30 20:09:09 UTC

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
ZONE="America/Los_Angeles"
UTC=false
ARC=false

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):
kernel-smp-2.6.12-1.1398_FC4

How reproducible:
Always

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

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 20:17:48 UTC

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 11:24:13 UTC

Same problem here, running vanilla FC4 on a DELL Dimension 4700.

Comment 3 Florin Andrei 2005-08-08 06:11:08 UTC

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 10:28:44 UTC

Same happening on kernel-smp-2.6.12-1.1387_FC4

Comment 5 Dave Jones 2005-08-26 09:29:32 UTC

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 09:00:09 UTC

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 13:09:13 UTC

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 18:25:41 UTC

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.

RADIM

Comment 9 Anil Kumar Sharma 2006-02-17 19:13:42 UTC

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 18:01:22 UTC

Seems fine for me now. I'm not sure what changed that made the bug go away.

Comment 12 Karel Zak 2007-03-14 20:47:53 UTC

Well, can we close this bug report?

Comment 13 petrosyan 2008-02-27 05:44:00 UTC

Since there was no reply for almost a year and the bug reporter says that the
bug is fixed I am closing this bug.