Red Hat Bugzilla – Bug 870535
Regression in handling of localtime RTC: timezone offset applied twice
Last modified: 2012-12-07 23:36:04 EST
Created attachment 634008 [details]
dmesg, localtime and adjtime showing incorrect localtime
Description of problem:
On a fully updated Fedora 18 system, after booting to Windows and back I noticed that the system clock is offset by an additional seven hours (from UTC+7 to effectively UTC+14).
I have tried reinstalling Fedora 17, verifying that hwclock and date agree with each other, before then upgrading again to Fedora 18 using yum, and the issue persists.
Version-Release number of selected component (if applicable):
systemd-195-4.fc18.x86_64 (from Koji)
Steps to Reproduce:
1. Install Fedora 17, specifying HW clock is *not* set to UTC
2. Verify clock is correct
3. Update to Fedora 18
System clock is incorrect; see attached typescript for dmesg, localtime and adjtime settings. Note that the script was generated ~ 1 AM local time, *not* 8 AM as indicated.
Local time support should work without having to do hwclock --hctosys by hand.
I guess we move it in the wrong direction in 195.
Can you please paste the output of:
Local time: Sat, 2012-10-27 13:58:59 CEST
Universal time: Sat, 2012-10-27 11:58:59 UTC
RTC time: Sat, 2012-10-27 11:58:58
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
I suspect systemd in dracut seals the kernel's time-warp, which we expect to
work in the real system. This might fix it:
Certainly (and it happened with 194 too, I actually downloaded 195 from Koji to test if that fixed it). Will that commit be in 196?
Local time: Sun, 2012-10-28 10:21:25 WIT
Universal time: Sun, 2012-10-28 03:21:25 UTC
RTC time: Sun, 2012-10-28 10:21:25
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: yes
Warning: The RTC is configured to maintain time in the local time zone. This
mode is not fully supported and will create various problems with time
zone changes and daylight saving adjustments. If at all possible use
RTC in UTC, by calling 'timedatectl set-local-rtc 0'.
(In reply to comment #3)
> ✗ timedatectl
> Local time: Sun, 2012-10-28 10:21:25 WIT
> Universal time: Sun, 2012-10-28 03:21:25 UTC
> RTC time: Sun, 2012-10-28 10:21:25
This is after manually running hwclock --hctosys, but I take it you just want to verify that timezone, NTP enabled/synchronized/localTZ is set properly.
NTP is not synchronized because my horrible, horrible cable provider *blocked* ports 123 on their clients' machines, and the only way to get NTP sync working is to run ntpdate as a client with a port >= 1024, which I've not figured out how to get chrony to do
(In reply to comment #4)
> NTP is not synchronized because my horrible, horrible cable provider
> *blocked* ports 123 on their clients' machines, and the only way to get NTP
> sync working is to run ntpdate as a client with a port >= 1024, which I've
> not figured out how to get chrony to do
You can try adding "port 11123" to chrony.conf.
Given the fix in systemd git I presume this issue is fixed upstream now.
(In reply to comment #6)
> Given the fix in systemd git I presume this issue is fixed upstream now.
That patch sounds like it should fix the issue, but given that you announced that 196 will be targeting Fedora 19, perhaps the patch should be cherry-picked for a bugfix F18 update?
I could try doing that and see if that solves the problem. Presumably I'd need to run dracut and update my initrd as well.
(In reply to comment #5)
> (In reply to comment #4)
> > NTP is not synchronized because my horrible, horrible cable provider
> > *blocked* ports 123 on their clients' machines, and the only way to get NTP
> > sync working is to run ntpdate as a client with a port >= 1024, which I've
> > not figured out how to get chrony to do
> You can try adding "port 11123" to chrony.conf.
As it turns out, I needed to tell SELinux about the port change (good thing there's the troubleshooter - though why semanage is so slow beats me).
The Chrony documentation probably should be updated to mention the "port N" configuration option.
(In reply to comment #7)
> The Chrony documentation probably should be updated to mention the "port N"
> configuration option.
It's listed in the "4.2 The chronyd configuration file" section in the chrony info document.
Created attachment 636748 [details]
Patch to systemd F18 branch to apply Kay's git commit
I just tested an updated systemd build for F18 (patch attached), and after rebuilding my initrd using dracut, it does seem the issue is fixed. Would be great to see this fix land post-beta!
@ Miroslav - oops, the info file is the one place I didn't look. Thanks!
Could you do a build for F18 of systemd 196 or a build of 195 with a patch for this bug?
I am trying to sort out the problems involving the RTC on local time in this bug:
Bug 881403 - Anaconda doesn't correctly infer if system clock shows UTC or local time
There appear to be at least two problems, but I can't tell for sure without a fix for this bug.
systemd-195-10.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-195-10.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
(In reply to comment #11)
> systemd-195-10.fc18 has been submitted as an update for Fedora 18.
Thanks. I have tested systemd-195-10.fc18 in a VM and on bare metal, and it seems to fix this bug.
As Michel noted, the initramfs needs to be rebuilt. This can be accomplished by updating the kernel after updating systemd.
Set RTC to local time in BIOS.
Set time zone.
Verify that /etc/adjtime has LOCAL and not UTC.
Verify that the time returned by the date command matches the RTC:
$ date; cat /proc/driver/rtc
 Comment 9.
systemd-195-10.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.