You are not logged in.
Pages: 1
I just recently installed Arch Linux i686. I thought I got the time set correctly when I first installed Arch, but now I notice that the system time is incorrect. I live in Tucson, Arizona. Arizona (execpt for the Navajo Indian reservation) is on MST (GMT-7) year round, no DST. I dual boot this machine to both Windows and Linux, so the hardware clock is set to local time. When I boot to Windows, the correct time is displayed. in /etc/rc.conf, I have
HARDWARECLOCK="localtime"
TIMEZONE="Ameria/Phoenix"
When I boot Arch, and type the date command, it displays localtime - 7 hours. Also, if a create a new file and do a "ls -l" command, the timestamp on the file is localtime - 7 hours. It appears that Arch thinks the hardwareclock is set to UTC, even though I have HARDWARECLOCK="localtime" specified.
How can I fix this?
(I did a pacman update a week ago and it looked like it installed a new kernel. Maybe this is when the incorrect system time started. Not sure.)
Charles Bailey
Offline
Welcome to the forum, logic_guy76!
In last case you can use ntp service to get exact time.
Offline
I tried changing /etc/rc.conf to HARDWARECLOCK="UTC" and rebooted. No change in the time displayed.
Then I tried changing /etc/rc.conf to TIMEZONE="America/New_York" and rebooted. Now it displayed a different time, 3 hours later, and said the time zone was EDT. OK, that was expected. I changed back to TIMEZONE="America/Phoenix" and once again it displayed MST as the time zone, but off by 7 hours as before. I tried setting HARDWARECLOCK="localtime" and rebooted again. No change in the time displayed. It seems that, no matter what I specify for HARDWARECLOCK, Arch assumes the clock is set to UTC. Has the syntax for this keyword changed?
Charles Bailey
Offline
I have similar problems with my clock. It's set in CEST but four hours in the future.
Offline
this should see you right:
never trust a toad...
::Grateful ArchDonor::
::Grateful Wikipedia Donor::
Offline
Check the time zone Windows is using, just to cover all the bases. If Windows is using US/Pacific, a common default setting, and you've set your clock in Windows to one hour faster than Pacific time so it displays local time correctly...
Look in /usr/share/zoneinfo for alternative names to your timezones. I see "US/Mountain" can be used. You might have to correct for DST twice a year.
Offline
I'm having the same exact problem. My clock has been set to localtime because of a Windows dual boot for awhile now and had been working without issue that whole time. Just overa a week ago I noticed that the clock started showing localtime - 4 (I'm in EDT) instead of localtime like it's supposed to.
As logic_guy asked has some syntax changed somewhere for using localtime? Is the kernel the right package to introduce this type of problem or is something else responsible for parsing the rc.conf file settings? I can always start randomly reverting packages to see what's at fault here, but it'd be nice to have an idea of where to start.
In response to toad's suggestion, I have OpenNTPd setup and, I belive, functioning correctly, but the clock is still wrong. Any help would be greatly appreciated.
Offline
I'm seeing the same issue that logic_guy & xerox1101 are having. I've always had HARDWARECLOCK="localtime" & TIMEZONE="America/Los_Angeles" and didn't have an issue. Now sense an update or two my close is 7 hours behind. I'm trying to figure out what package update changed my clock setting to UTC & not localtime.
sCrIpt mUnKeE
Offline
I went into the BIOS setup and checked the actual hardware clock. It was running at localtime - 7 hrs. Somehow, with the experimenting I was doing with UTC, etc, the hardware clock got changed. I manually set it to the correct time (had an "atomic" self-setting clock sitting next to the computer). Booted Arch again. Now the date command displayed a time that was, more or less, in the ballpark; but, instead of being off by 7 hours (UTC vs MST), it was off by about 20 minutes. Strange. Shut down, went into BIOS setup again, set the hardware clock again (which apparently got changed during the shutdown), and rebooted Arch. Now the system time was off by about 4 minutes. Went through another interation. Now the system time was really close, off by about 4 seconds.
That was last night. Booted up the PC again a few minutes ago. Checked the hardware clock first; it was still really close. Booted Arch and checked the system time. It was off by about 10 minutes from what the hardware clock in the BIOS setup had displayed just seconds before. This is strange.
I'll try installing openntpd, as "Toad" suggested yesterday and see if things settle down.
Offline
I also observed strange things with the time. Same settings and symptoms described in the thread (though my timezone is Europe/Madrid). It happened a couple of times that it was +2 hours ahead of the real time. However, just issuing the command "ntpdate pool.ntp.org" (as root) fixed the issue both times and it has not come back again lately. I wonder if I have to boot Windows first for it to get screwed again.
EDIT: Just booted it again and it's off by 6 minutes when yesterday it was fine. There is something strange going on here...
EDIT 2: Forgot to say that my desktop, that I use all the time, is not affected (it has Windows installed too), it just seems to be the netbook. Very strange...
Last edited by Bogart (2009-09-07 21:23:02)
Offline
Here's a time setting command I just learned about: hwclock. It might come in handy.
You can read the hardware clock from within a running system.
$ hwclock -r
Mon 07 Sep 2009 07:12:51 PM EDT -0.484452 second
You can also set the system time from the hardware clock
$ sudo hwclock -s
Last edited by thisoldman (2009-09-07 23:13:15)
Offline
Today my clock was off by 3 minutes (since yesterday). So definitely something is messing with the hardware clock. I'm inclined to think it has to do with power management, but that's just a guess. A couple of questions:
- Is everybody experiencing this problem using a laptop?
- By any chance is everyone using KDE-4.3?
Offline
PC was powered off all last night. I powered it on this morning and immediately went into BIOS setup and checked the hardware clock before booting anything. It was still within a second or two of the correct local time. So, the hardware clock is running OK. I booted Arch and checked the system time with the date command. It was off by about 13 minutes. I immediately checked the hardware clock again with "hwclock -r" (thanks, thisoldman, for the pointer to this command). It was now also off by 13 minutes. Thus, it appears that, when booting Arch, it doesn't just initially set the system time to the hardware clock. It first makes some adjustment to the hardware clock and then sets the system time to this adjusted value.
Why does it do this? How does it decide what adjustment to make to the hardware clock?
Offline
The Arch boot sequence, from the wiki page, http://wiki.archlinux.org/index.php/Boot:
1 Grub or Lilo
2 Kernel and memory management functions loaded into memory
3 init called - follows instructions from /etc/inittab
4 /etc/rc.sysinit is called.
Early in rc.sysint , from my x86-64 Arch on a dual AMD cpu, the realtime-clock driver is loaded. In my case, it's rtc-cmos. Bugs have been reported in various places about this driver. I don't know which version of the driver, or which kernels might be affected. The driver is for PC-style computers; without it ACPI would not function.
Then, the hwclock may be adjusted for system drift depending on use of localtime or UTC.
After the local filesystems are mounted, the hwclock may be adjusted again.
You could add lines to rc.sysinit to echo the hwclock time to the screen for the boot sequence using "/sbin/hwclock -r" to see which adjustment instance is causing the errors and then take steps to correct the adjustment or prevent the adjustment from occurring.
Edited for clarity and typos.
Last edited by thisoldman (2009-09-09 02:17:27)
Offline
I bet the problem isn't the DE or WM. I bet it's certain Intel Chips on laptops.
Offline
i'm using kdemod 4.3 and have the same issue, also my Motherboard is a Gigabyte eith a P35 intel chipset
Offline
Hi all,
this issue was discussed on the French forum, it seems a fix was found.
Translation :
- Start archlinux
- set up the system time (with date)
- run as root :echo "0.0 0 0.0" > /var/lib/hwclock/adjtime hwclock -r hwclock -w --localtime hwclock -r
"hwclock -r" is for info only, it displays the BIOS time without changes.
- reboot
of course, all this with "localtime" in your /etc/rc.conf
Last edited by nowahn (2009-09-26 20:18:15)
take time to daydream, inspiration comes ...
Offline
Hi all,
this issue was discussed on the French forum, it seems a fix was found.
Translation :
- Start archlinux
- set up the system time (with date)
- run as root :echo "0.0 0 0.0" > /var/lib/hwclock/adjtime hwclock -r hwclock -w --localtime hwclock -r
"hwclock -r" is for info only, it displays the BIOS time without changes.
- reboot
of course, all this with "localtime" in your /etc/rc.conf
You usually need not reset adjtime. Simply deleting /var/lib/hwclock/adjtime will suffice (and is more secure). It will be restored with proper values at the next reboot (actually by the "hwclock --set" command).
See man hwclock: "The Adjust Function" for more info on this.
Last edited by bernarcher (2009-09-11 12:02:39)
To know or not to know ...
... the questions remain forever.
Offline
Yes, that seemed to be the problem. The first value in /var/lib/hwclock/adjtime was like 360, so every day it would add 6 minutes to the hwclock on boot. After removing it, setting the time correctly and rebooting it's turned into 0, so I hope it just stays like that.
Thanks for the fix.
Offline
I installed openntpd and configured it to query 3 servers in the .us server pool. Added openntpd to the startup daemons. Things have settled down now and both the hardware and system clocks are right on.
Offline
I installed openntpd and configured it to query 3 servers in the .us server pool. Added openntpd to the startup daemons. Things have settled down now and both the hardware and system clocks are right on.
Sure, by using some NTP daemon (or a command in rc.local) it will fix the time. But what's happening is this: Every day your clock will be screwed by that wrong /var/lib/hwclock/adjtime value, and immediately after it will be fixed again by some NTP daemon. Not a big problem, but I think it's better to fix that file (by just removing it, it will be created correctly again at boot time) and fix the problem in a more elegant way.
Offline
Hi all,
this issue was discussed on the French forum, it seems a fix was found.
Translation :
- Start archlinux
- set up the system time (with date)
- run as root :echo "0.0 0 0.0" > /var/lib/hwclock/adjtime hwclock -r hwclock -w --localtime hwclock -r
"hwclock -r" is for info only, it displays the BIOS time without changes.
- reboot
of course, all this with "localtime" in your /etc/rc.conf
yes do it this way people. :-)
Offline
I installed openntpd and configured it to query 3 servers in the .us server pool. Added openntpd to the startup daemons. Things have settled down now and both the hardware and system clocks are right on.
I know that it is a hardware forum, but once we started talking abotu openntpd: how do I set it up to adjust time, when the network connection is established?
The problem is that yesterday, when I booted my laptop the clock was -4 hours off. And, although ntpd was running, I had to synchronize the time manually. The thing is that I am using wicd and, therefore, the network is not present when ntpd starts...
Thanks.
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
Pages: 1