Bug 692262

Summary: F15 gains an hour at each reboot
Product: [Fedora] Fedora Reporter: Michael Young <m.a.young>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: johannbg, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-04 18:41:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Michael Young 2011-03-30 20:33:08 UTC
Now I am in summer time I have noticed F15 gains an hour each time I reboot it. I am guessing there is something unbalanced in the start up and shut down scripts provided by systemd.
Currently (as I haven't corrected the time) hwclock --show is one hour ahead of real time, the time on hte desktop is two hours ahead, /etc/sysconfig/clock contains ZONE="Europe/London" and /etc/adjtime contains
3530.393003 1301512717 0.000000
1301512717
LOCAL

Comment 1 Lennart Poettering 2011-03-31 12:28:14 UTC
Hmm, LOCAL and not UTC?

/etc/sysconf/clock is mostly irrelevant, /etc/localtime matters.

What does "systemctl status hwclock-load.service" say?

What does "systemctl is-enabled hwclock-load.service ; echo $?" say?

Comment 2 Michael Young 2011-03-31 18:14:24 UTC
# systemctl status hwclock-load.service
hwclock-load.service - Apply System Clock UTC Offset
	  Loaded: loaded (/lib/systemd/system/hwclock-load.service)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/hwclock-load.service

# systemctl is-enabled hwclock-load.service ; echo $?
1

Comment 3 Lennart Poettering 2011-04-02 02:06:25 UTC
Ah, so it isn't enabled.

"systemctl enable hwclock-load.service" should fix your problem.

But I do wonder how it happened that this service isn't enabled, after all we enable it by default in %post.

Is this an upgrade from an older F15/Rawhide?

Comment 4 Michael Young 2011-04-02 08:33:49 UTC
It was an update from F14. The install had also gone through the F14 alpha/beta stages, so systemd-units was probably first installed when systemd was the default in F14 testing. I have checked the other services mentioned in the systemd-units scripts and getty@.service and remote-fs.target aren't enabled either.

Comment 5 Lennart Poettering 2011-04-04 18:41:32 UTC
Ah, OK, if it is such an old setup, then let's just hope this problem was due to that, and that the bug doesn't exist for fresh installs, and upgrades from a F14 final version. Closing.