Results 1 to 6 of 6
Since I installed Crux, my hardware clock has been misbehaving. I thought the problem was merely with the Crux version of hwclock, but now I get the same misbehaviour in ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 07-08-2009 #1
[SOLVED] My hardware clock has gone haywire!
The clock tells the right time in UTC; I've checked with hwclock -r. My time zone is GB, so my system time ought to be set one hour later (British Summer Time). But Crux - and now Debian too - think the clock is set to local time, so they don't correct it. The version of hwclock that Debian uses includes the time system being used in its display and it says "BST" not "UTC".
I have tried resetting the clock with hwclock --set --date=(correct UTC time) --utc, but this makes no difference. So all my timestamps are one hour out (not that it matters very much on a home computer) but I'm going crazy trying to work out what has gone wrong."I'm just a little old lady; don't try to dazzle me with jargon!"
- 07-08-2009 #2
I had to laugh when I saw this hazel because I've been having the same issue! I thought it was just me! I've not had the time to delve into it too much but I think it has something to do with having more than one distro on a drive and going between the two. I have Ubuntu first on this HD and never run into the clock issue until I boot into it. An easy workaround I've found:
Just set correct hardware time in the bios, then when CRUX is booted, set correct local time (if it is off) with the date command. This usually fixes things until I go back into Ubuntu.
- 07-08-2009 #3
I have the same problem with Gentoo and I have tried every work-around I could find, it just won't stick. I think I'm gonna give up on that part and just use NTP to set my time automagically on boot.
- 07-08-2009 #4
I don't really need to set the clock in the bios because it already tells the correct time - it just isn't interpreted correctly. I have now put a call to msntp into the Crux boot script to reset my system time. And I have inactivated the line in rc.shutdown that would reset the hardware clock from the system clock. I'll freeze the hardware clock out of my system altogether if it refuses to behave! We'll see if that solves the problem.
I'm glad it's not just me! But I don't understand how a computer can behave like this. Aren't computers supposed to be completely logical?"I'm just a little old lady; don't try to dazzle me with jargon!"
- 07-08-2009 #5
Cracked it! Here is the output of hwclock -r run in debug mode:
hwclock from util-linux-ng 2.15.1 hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. Using direct I/O instructions to ISA clock. Last drift adjustment done at 1246555140 seconds after 1969 Last calibration done at 1246555140 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2009/07/08 18:27:42 Hw clock time : 2009/07/08 18:27:42 = 1247077662 seconds since 1969 Wed Jul 8 19:27:42 2009 -0.515978 seconds
I think the trouble started when I booted Crux for the first time. There was no /etc/adjtime file to tell hwclock what sort of time the hardware clock was keeping, and Crux doesn't store this information anywhere else as most distros do. So it guessed at local time (its default) and everything went downhill from there.
Once I realised that the clock was wrong, I went into the bios and corrected it. Crux boots to the correct time now and I bet Debian will too.
Those of you who have the same problem, try running hwclock -rD so you can see what time the hardware clock is actually showing, not just a "corrected" version. And if it's wrong, go into the bios and correct it."I'm just a little old lady; don't try to dazzle me with jargon!"
- 07-08-2009 #6