FS#26613 - System clock set incorrectly on every boot

Attached to Project: Arch Linux
Opened by Max Pray (synthead) - Tuesday, 25 October 2011, 13:45 GMT
Last edited by Ionut Biru (wonder) - Saturday, 29 October 2011, 13:50 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


On my Toshiba NB505 netbook, the system clock is approximately 6 hours off every time it goes through the Arch init scripts, even when doing a soft reboot. The hwclock daemon is first in my rc.conf's $DAEMONS array. I am not using an NTP daemon of any kind, but after the system boots (with the incorrect time), I am able to use ntpdate to sync with time.nist.gov and get the correct time.

initscripts 2011.10.2-1
linux 3.0.7-1
This task depends upon

Closed by  Ionut Biru (wonder)
Saturday, 29 October 2011, 13:50 GMT
Reason for closing:  Not a bug
Comment by Alexander F. Rødseth (xyproto) - Tuesday, 25 October 2011, 14:07 GMT
Could the clock battery be empty?
Comment by Max Pray (synthead) - Wednesday, 26 October 2011, 02:24 GMT
The computer is less than a week old. The system time sticks too: if I observe the incorrect time at boot, power it off, wait a while, then reboot into the BIOS settings, I can observe that the clock has advanced in time by the correct amount.
Comment by Max Pray (synthead) - Wednesday, 26 October 2011, 02:31 GMT
After a reboot:

$ sudo hwclock --show
Tue 25 Oct 2011 02:29:24 PM EDT -0.594851 seconds
$ date
Tue Oct 25 14:29:27 EDT 2011
$ sudo ntpdate time.nist.gov
25 Oct 22:29:21 ntpdate[1320]: step time server offset 28674.054351 sec
$ sudo hwclock --show
Tue 25 Oct 2011 02:31:33 PM EDT -0.063816 seconds
$ date
Tue Oct 25 22:29:33 EDT 2011
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 26 October 2011, 07:07 GMT
Thanks. Could it be related to the HARDWARECLOCK setting in /etc/rc.conf or a BIOS setting related to the clock?
Comment by René Herman (rene) - Wednesday, 26 October 2011, 23:35 GMT
I see that "EDT" is UTC-4 which means that the "approximately 6 hours" bit is somewhat peculiar but...

I would expect that you have told arch to keep your CMOS clock on UTC whereas you do not in fact expect this? If you have HARDWARECLOCK="UTC" in /etc/rc.conf you have. Perhaps that an incorrect TIMEZONE= line one line down accounts for the two additional hours of difference.

(note by the way that keeping the hw clock on UTC instead of localtime IS very much advised).

If this is not the issue, perhaps you by now have a very strange /etc/adjtime. Deleting it to start anew might also do something.

EDIT: that would be /var/lib/hwclock/adjtime instead of /etc/adjtime these days.
Comment by Max Pray (synthead) - Friday, 28 October 2011, 23:38 GMT
What do you mean by expect this? Could this be my CMOS clock getting in the way somehow?

Here's my related lines in /etc/rc.conf:

And /var/lib/hwclock/adjtime:
0.000000 0 0.000000

I deleted it, but after restarting the daemon, the file contains the same data. I assume that this means it hasn't adjusted any clock skew.
Comment by René Herman (rene) - Saturday, 29 October 2011, 01:31 GMT
First, before I confuse you, by "CMOS clock", "hardware clock" or "hw clock" is meant the same thing: the piece of battery-backed hardware on your motherboard that keeps time.

I meant that I suspected that you told arch to keep your CMOS clock on UTC (which you have, through that HARDWARECLOCK="UTC" line) but that you expected the time in your BIOS and/or in a dual-boot Windows copy to be the local time. Both your BIOS and (by default) Windows expect the CMOS clock to be set to local time, and will display whatever it is set to. If you keep your CMOS clock on UTC, BIOS and Windows will therefore display a "wrong" value (better, will display UTC).

(here's a few reasons why you still want to keep it on UTC: http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html)

Be all that as it may... let's just try and see if there's actually a problem because I can't tell your level of expertise from the above. If you boot into arch linux, do:

sudo ntpdate time.nist.gov
sudo hwclock --systohc --utc

Your CMOS clock will now be set to correct UTC time. If your local time is EDT (UTC-4) then your BIOS should after this show you a time 4 hours later than your wristwatch does (*) but if you boot into arch linux again, it should show you the SAME as your wristwatch, since it corrects for the Canada/Eastern timezone. Check with the comand "date".

Anything wrong at this point? If so, there's a problem. But if not, everything is actually working fine...

(*) assuming, of course, that your wristwatch actually keeps proper EDT... ;-/
Comment by Max Pray (synthead) - Saturday, 29 October 2011, 03:22 GMT
sudo hwclock --systohc --utc
This did the trick! That's awesome! :D
I should ask, though: will everyone in Arch need to run this command when they set their clock, or am I a particular case?
Comment by Karol Błażewicz (karol) - Saturday, 29 October 2011, 03:26 GMT
> I should ask, though: will everyone in Arch need to run this command when they set their clock, or am I a particular case?
It's standard, you're not a special case.
Comment by René Herman (rene) - Saturday, 29 October 2011, 13:40 GMT
Standard indeed. There are two in essence independent levels of time keeping on your computer involved here. One the hardware, CMOS clock, time and one the software, system, time.

When you boot your computer, the system time is initialized from the hardware time, but other than that the two clocks run independently. Specifically, if you set your system time -- through whichever method, for example manually or through that ntpdate command above -- this does not automatically trickle down to the hardware time as well. Distributions tend to explicitly sync the CMOS clock to the system time again in their shutdown scripts, but in essence, it's something that always requires the above "hwclock --systohc" command.

That is, "hwclock --systohc --utc" if you keep the hardware clock on UTC, "hwclock --systohc --localtime" if you were to keep it on localtime. As said, the first is much advised but if you desperately want your BIOS to show local time, first run that "hwclock --systohc --localtime" command to set the hardware clock to localtime, and second change to HARDWARECLOCK="localtime" in /etc/rc.conf to tell Arch Linux that the hardwareclock IS on localtime (and reboot).

Good to know you have it fixed. I'll request closure of this report.