System-config-date correctly sets whether to set the system clock to UTC or not in /etc/adjtime. This setting is evaluated in hwclock-load.service (from systemd-units) at bootup, changing component.

I am seeing the same bug, America/New_York.

I wonder if the default timezone isn't known during some part of the new systemd boot, so it thinks local and utc are the same when it is fiddling with the clock?

I think this bug needs to be reassigned to systemd-units. I believe that this is a bug in the systemd-units %post script when upgrading from F14 to F15. 

The bug is that hwclock-load.service never gets enabled when upgrading
systemd-units-10-2.fc14.1.x86_64 to systemd-units-26-2.fc15.i686.

%post in systemd-units-26-2.fc15.i686 reads as follows:

if [ $1 -eq 1 ] ; then

# ....

        /bin/systemctl enable \
                getty@.service \
                remote-fs.target \
                systemd-readahead-replay.service \
                systemd-readahead-collect.service \
                hwclock-load.service > /dev/null 2>&1 || :
fi

This, of course, never gets executed when upgrading from F14. This gets executed only when installing systemd-units for the first time as part of a fresh install. The %post in F14's systemd-units did not enable hwclock-load.service -- looks like this was what was overlooked initially, it got fixed somewhere along the way, but existing F14 systems being upgraded to F15 do not get the benefit of the fix, because it never gets executed.

The fix is to manually run the above command, fix the clock for the last time, and reboot.

You can ignore the arch disrepancy, I was compared an F14 x86_64 machine with what I've got on an F15 i386 laptop. Fairly sure that this is the bug. After rebooting a few times, the clock came up with the correct local time, each time, now.

(In reply to comment #4)
> I think this bug needs to be reassigned to systemd-units. I believe that this
> is a bug in the systemd-units %post script when upgrading from F14 to F15. 

Oh, I meant to change the component of this bug to systemd (which is the main package of systemd-units) above in comment #1. Changing now.

> The bug is that hwclock-load.service never gets enabled when upgrading
> systemd-units-10-2.fc14.1.x86_64 to systemd-units-26-2.fc15.i686.
> 
> %post in systemd-units-26-2.fc15.i686 reads as follows:
> 
> if [ $1 -eq 1 ] ; then
> 
> # ....
> 
>         /bin/systemctl enable \
>                 getty@.service \
>                 remote-fs.target \
>                 systemd-readahead-replay.service \
>                 systemd-readahead-collect.service \
>                 hwclock-load.service > /dev/null 2>&1 || :
> fi
> 
> This, of course, never gets executed when upgrading from F14. This gets
> executed only when installing systemd-units for the first time as part of a
> fresh install. The %post in F14's systemd-units did not enable
> hwclock-load.service -- looks like this was what was overlooked initially, it
> got fixed somewhere along the way, but existing F14 systems being upgraded to
> F15 do not get the benefit of the fix, because it never gets executed.

I concur with that for some reason or another, the hwclock-load  and other services weren't enabled, but I don't think it's because $1 would evaluate to anything other than 1 in the case of upgrading F-14 (which doesn't have a systemd-units package) to F-15.

RPM is rather simplistic here, $1 means just "how many packages of this name (systemd-units) are installed after this part of the transaction (installation of the new version-release in the case of an update) is finished", see http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax for details. It doesn't care if the package is installed because it obsoletes an older one of a different name (which is what we have here in the case of an upgrade with a SysV->systemd migration).

I'm unsure why these services weren't enabled when installing the package, though. The only other reason I can think of why $1 could be != 1 is if systemd-units were installed twice, but then at one point the first instance must have been installed and $1 would have been 1 in its %post script. To me, that leaves a systemd-units version that didn't have this %post script while being installed for the first time, e.g. when upgrading from F-14 to a prerelease or Rawhide which had systemd < 14 (which is were the hwclock-load service was enabled for the first time). Did you see this issue with an upgrade from F-14 to F-15 proper, or was the upgrade done to a pre-release?

> The fix is to manually run the above command, fix the clock for the last time,
> and reboot.

Technically, that's only a workaround ;-).

If F14 did not have systemd-units, then where did this come from:

[mrsam@shorty ~]$ rpm -q -i systemd-units
Name        : systemd-units                Relocations: (not relocatable)
Version     : 10                                Vendor: Fedora Project
Release     : 2.fc14.1                      Build Date: Tue 05 Oct 2010 06:47:38 PM EDT
Install Date: Fri 22 Oct 2010 02:30:57 PM EDT      Build Host: x86-15.phx2.fedoraproject.org
Group       : System Environment/Base       Source RPM: systemd-10-2.fc14.1.src.rpm
Size        : 244036                           License: GPLv2+
Signature   : RSA/SHA256, Wed 06 Oct 2010 02:26:15 PM EDT, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://www.freedesktop.org/wiki/Software/systemd
Summary     : Configuration files, directories and installation tool for systemd
Description :
Basic configuration files, directories and installation tool for the systemd
system and session manager.

F14 did have systemd-units. Therefore, on upgrade $1=2, and that's why hwclock-load.service was not enabled.

This was an upgrade from F14 proper to F15.

That would explain it:

- F-14 was planned to be the first Fedora version to have systemd instead of upstart. This was changed shortly prior to release.
- Even though systemd wasn't offered in the installer (on account of not being listed in comps.xml), packages of an old version of systemd (10) were in the repository.

I guess that you either installed a prerelease of F-14 which still had systemd per default and updated to F-14 proper later, or installed systemd manually on your F-14 system. Is that the case?

This machine was installed from an F14 live image that I torrented off fedoraproject.org, post F14 release.

Was systemd-units present in the released F14 live image? Or did I somehow end up getting a prerelease F14 live image?

(In reply to comment #9)
> Was systemd-units present in the released F14 live image? Or did I somehow end
> up getting a prerelease F14 live image?

I've just checked this: the live image indeed included the systemd-units package (but not any other systemd packages). This leaves the question how these services could be enabled during upgrade from systemd-units<=13 to a later version...

A rather hackish way would be to check for the existence of the affected service unit files in the %pre scriptlet, then set a flag (a file) which is checked for and removed in %post (instead of $1==1) to enable the services, this would ensure that they are enabled only when the package is installed or being updated from a version that doesn't have these unit files (read: is too old).

Lennart, what do you think?

systemd packages are also on DVD installer of Fedora 14. I was doing clean install of F14 from DVD than I have upgraded it to F15.

You can use a triggerpostun on version < version with the trigger.

(In reply to comment #12)
> You can use a triggerpostun on version < version with the trigger.

Yes, much less hackish and one of the few cases where using a trigger poses less risk of shooting oneself in the foot than doing it differently :-).

I met the same bug after some update (maybe yesterdays) of fresh installed fedora-15 (Fedora-15-i386-DVD.iso is used). Workaround is to set 'System clock uses UTC'


[sergeil@ua-dudn000 etc]$ rpm -qf `which system-config-date `
system-config-date-1.9.61-2.fc15.noarch

The problem happens even for fresh installs of F15 (x86-64) with /home from F14.
Hardware clock is set to local time (IST). I had filed bugs earlier.

https://bugzilla.redhat.com/show_bug.cgi?id=709929

All my PCs/laptops upgraded from F14 are affected by this bug. It is not clear to me what is the resolution or a quick fix for this irritating bug. Does it need to re-install systemd-units or to enable hwclock-load.service service?

(In reply to comment #17)
> Does it need to re-install systemd-units

No.

> or to enable hwclock-load.service service?

Yes. Or switch to UTC for the hardware clock.

we should probably commonbugs this.

> enable hwclock-load.service service

do not work for me

(In reply to comment #20)
> > enable hwclock-load.service service
> 
> do not work for me

What command did you use to enable hwclock-load.service?

(In reply to comment #21)
> (In reply to comment #20)
> > > enable hwclock-load.service service
> > 
> > do not work for me
> 
> What command did you use to enable hwclock-load.service?

systemctl enable hwclock-load.service

==> and reboot

current status:
===============

[root@ua-dudn00000 etc]# cat adjtime 
-0.619641 1308676102 0.000000
1308676102
LOCAL

[root@ua-dudn00000 etc]# date
Tue Jun 21 17:14:19 EEST 2011

[root@ua-dudn00000 etc]# hwclock --show
Tue Jun 21 20:14:40 2011  -0.954261 seconds

==> right time is hwtime

[root@ua-dudn00000 sysconfig]# grep Kiev *
clock:ZONE="Europe/Kiev"
[root@ua-dudn00000 sysconfig]# cat /etc/sysconfig/clock 
# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.
ZONE="Europe/Kiev"


[root@ua-dudn00000 sysconfig]# file /etc/localtime 
/etc/localtime: timezone data, version 2, 12 gmt time flags, 12 std time flags, no leap seconds, 119 transition times, 12 abbreviation chars

[root@ua-dudn00000 sysconfig]# ll /etc/localtime 
-rw-r--r--. 2 root root 2057 Mar 30 19:04 /etc/localtime

[root@ua-dudn00000 sysconfig]# systemctl status hwclock-load.service
hwclock-load.service - Apply System Clock UTC Offset
Loaded: loaded (/lib/systemd/system/hwclock-load.service)
Active: active (exited) since Tue, 21 Jun 2011 20:08:43 +0300
Process: 406 ExecStart=/sbin/hwclock --systz (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/hwclock-load.service

[root@ua-dudn00000 sysconfig]# systemctl --all | grep clock
hwclock-load.service loaded active   exited  Apply System Clock UTC Offset
hwclock-save.service loaded inactive dead    Update RTC With System Clock

Duplicate of 656747?

Can anybody explain how to fix this bug manually? I think, it is not good idea to reinstall system...

IMHO, solution is to disable hwclock-load.service `systemctl disable hwclock-load.service`

`hwclock --systz` shift system time according to timezone, but it is not necessary, because local time is already in hwclock.

Nothing to do...

> IMHO, solution is to disable hwclock-load.service

Odd!  For me the problem disappeared when I ENABLED the hwclock-load.service as suggested earlier in this bugzilla.

I found workaround for this bug: build kernel with CONFIG_RTC_DRV_CMOS to 'm', not to 'y'. And it works for me.

Fedora-16 preAlpha (guest of KVM) is affected too...

Unfortunately, hwclock-load.service is missed there. By this reason I can not play with it.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Is this still a problem or can this bug be closed?

It works for me from so I think the bug can be closed.

Closing as NEXTRELEASE per http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

*** Bug 704050 has been marked as a duplicate of this bug. ***