On my laptop, it seems that at every boot the clock is offseted by my timezone.
Date/Time properties shows "System clock uses UTC" unchecked. This is a dual- boot with WinXP, so I must keep the bios clock on local time. Yet, it seems that when I boot the bios clock is read as UTC nevertheless.
Before I begin a long and painful adventure in pulling apart with what's happening with systemd/initscripts, anyone has any clues where I should look?
On Tue, 2011-05-31 at 16:26 -0400, Sam Varshavchik wrote:
On my laptop, it seems that at every boot the clock is offseted by my timezone.
Date/Time properties shows "System clock uses UTC" unchecked. This is a dual- boot with WinXP, so I must keep the bios clock on local time. Yet, it seems that when I boot the bios clock is read as UTC nevertheless.
I have a similar problem with Fedora 14. It displays time different from the Ubuntu installation on another drive. Fedora is showing 3 min past midnight and Ubuntu before reboot to Fedora showed 2 minutes past 10 am same day. neither use UTC and it's only happened since installing Fedora 14. It has me puzzled. Roger
On 05/31/2011 01:26 PM, Sam Varshavchik wrote:
Before I begin a long and painful adventure in pulling apart with what's happening with systemd/initscripts, anyone has any clues where I should look?
The next few times you boot, go into your BIOS and make sure the time's right there. And, if the hardware clock's running slow, it may be a sign that your CMOS battery needs replacing. Modern computers are designed that way so that you can know when it's low and replace it before it dies completely. It's probably not an issue here, but it's good to know about in general.
Joe Zeff writes:
On 05/31/2011 01:26 PM, Sam Varshavchik wrote:
Before I begin a long and painful adventure in pulling apart with what's happening with systemd/initscripts, anyone has any clues where I should look?
The next few times you boot, go into your BIOS and make sure the time's right there. And, if the hardware clock's running slow, it may be a sign that your CMOS battery needs replacing. Modern computers are designed that way so that you can know when it's low and replace it before it dies completely. It's probably not an issue here, but it's good to know about in general.
It would be rather strange if a low cmos battery would result in the hardware clock being slow exactly by exactly four hours, no more, no less, on every boot, no matter how much time has elapsed between boots - anywhere between five minutes and sixteen hours - and despite the fact that the laptop's been on the mains power all the time, and wouldn't be drawing the CMOS battery at all.
On 05/31/2011 02:00 PM, Sam Varshavchik wrote:
It would be rather strange if a low cmos battery would result in the hardware clock being slow exactly by exactly four hours,
It would indeed, which is why I pointed out that it's probably not an issue here. I would like to point out, however, that your CMOS isn't working on AC power when it's turned off, even if it's plugged in.
On Tue, 2011-05-31 at 17:00 -0400, Sam Varshavchik wrote:
the laptop's been on the mains power all the time, and wouldn't be drawing the CMOS battery at all.
Depends on the circuit design. It's quite possible for part, or all, of the BIOS to depend entirely on a battery.
On Tue, 31 May 2011 16:26:21 -0400 Sam Varshavchik wrote:
Before I begin a long and painful adventure in pulling apart with what's happening with systemd/initscripts, anyone has any clues where I should look?
Check /etc/adjtime, it should say LOCAL, not UTC. You can also run hwclock --localtime to resync the hardware clock to local time.
I just went through this with a Windows dual boot system, and I could swear I didn't say clock uses UTC when I installed, but maybe I did out of reflex.
Tom Horsley writes:
On Tue, 31 May 2011 16:26:21 -0400 Sam Varshavchik wrote:
Before I begin a long and painful adventure in pulling apart with what's happening with systemd/initscripts, anyone has any clues where I should
look?
Check /etc/adjtime, it should say LOCAL, not UTC. You can also run hwclock --localtime to resync the hardware clock to local time.
It's says LOCAL, and the hwclock is most certainly resynced. Besides, at eash reboot hwclock-save.service should assure that the bios clock gets synced. But, at the next boot, it's broken again.
I just went through this with a Windows dual boot system, and I could swear I didn't say clock uses UTC when I installed, but maybe I did out of reflex.
I upgraded from F14. There were no issues before the upgrade.
I thought that it was odd that after I upgraded to F15, applied the updates, and rebooted a few times, the clock was off by twelve hours. I just shrugged it off as a gremlin, and resynced from my ntp server.
But when I noticed that the clock immediately jumped to being four hours later after a reboot, the alarm bell went off.
Unfortunately, now that we have this systemd infrastructure, it's not as easy as sticking a bunch of "date"s in the various rc scripts, to see what's happening to the clock when the system boots, and where it runs askew.
A brief Google search shows that I'm not the only one:
http://fedoraforum.org/forum/showthread.php?p=1475721#post1475721
… and, we're in Bugzilla. Looks like a bug to me.
On 05/31/2011 07:42 PM, Sam Varshavchik wrote:
Tom Horsley writes:
On Tue, 31 May 2011 16:26:21 -0400 Sam Varshavchik wrote:
Before I begin a long and painful adventure in pulling apart with
what's
happening with systemd/initscripts, anyone has any clues where I
should look?
Check /etc/adjtime, it should say LOCAL, not UTC. You can also run hwclock --localtime to resync the hardware clock to local time.
It's says LOCAL, and the hwclock is most certainly resynced. Besides, at eash reboot hwclock-save.service should assure that the bios clock gets synced. But, at the next boot, it's broken again.
I just went through this with a Windows dual boot system, and I could swear I didn't say clock uses UTC when I installed, but maybe I did out of reflex.
I upgraded from F14. There were no issues before the upgrade.
I thought that it was odd that after I upgraded to F15, applied the updates, and rebooted a few times, the clock was off by twelve hours. I just shrugged it off as a gremlin, and resynced from my ntp server.
But when I noticed that the clock immediately jumped to being four hours later after a reboot, the alarm bell went off.
Unfortunately, now that we have this systemd infrastructure, it's not as easy as sticking a bunch of "date"s in the various rc scripts, to see what's happening to the clock when the system boots, and where it runs askew.
A brief Google search shows that I'm not the only one:
http://fedoraforum.org/forum/showthread.php?p=1475721#post1475721
… and, we're in Bugzilla. Looks like a bug to me.
Fixed? systemd may be the unintentional culprit. systemctl status ntpd.service
Sam Varshavchik <mrsam <at> courier-mta.com> writes:
On my laptop, it seems that at every boot the clock is offseted by my timezone.
Date/Time properties shows "System clock uses UTC" unchecked. This is a dual- boot with WinXP, so I must keep the bios clock on local time. Yet, it seems that when I boot the bios clock is read as UTC nevertheless.
As an aside, there's a Windows hack (changing one of the registry entries) which allows setting the hardware clock to UTC. Unfortunately, in XP the time may not be properly restored after suspend/hibernate (which I don't do anyway on my XP/Fedora desktop so that doesn't affect me). It should work properly without this issue in Vista SP2 or Windows 7.
-
Andre Robatino -
Clyde E. Kunkel -
Joe Zeff -
Roger -
Sam Varshavchik -
Tim -
Tom Horsley