Red Hat Bugzilla – Bug 164711
BIOS time is treated as UTC even when it's not
Last modified: 2008-02-27 00:44:00 EST
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):
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
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.
Same problem here, running vanilla FC4 on a DELL Dimension 4700.
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.
Same happening on kernel-smp-2.6.12-1.1387_FC4
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.
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.
Do you see any error message when you run hwclock command? Can you found
something usefull in system logs?
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.
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.
Seems fine for me now. I'm not sure what changed that made the bug go away.
Well, can we close this bug report?
Since there was no reply for almost a year and the bug reporter says that the
bug is fixed I am closing this bug.