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 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:
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. Jakub ?
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. RADIM
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.