Bug 835962

Summary:	systemd not setting system time correctly
Product:	[Fedora] Fedora	Reporter:	Bob Hockney <bhockney>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint
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:	2012-06-27 18:49:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Bob Hockney 2012-06-27 16:49:06 UTC

Description of problem:

Filing this against F16, but also experienced this with F15 after upgrading the system from F14.  This is not the hwclock-load.service bug in the F15 installer.

My hw clock is using local time, which for me is -0600 from UTC.  After booting, the system time is set to 6 hours _earlier_ than local time, as though the system time was being set to UTC with the hw clock using my local time.

# ls -l /etc/localtime
lrwxrwxrwx 1 root root 34 Mar 17 17:03 /etc/localtime -> /usr/share/zoneinfo/America/Denver

# cat /etc/adjtime
0.000000 1340812145 0.000000
1340812145
LOCAL

# 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="America/Denver"

For example, I booted earlier when my local time was 9:11 AM, and date gave:

Wed Jun 27 03:11:11 MDT 2012

I have verified that the hw clock is correct local time.

Version-Release number of selected component (if applicable):

F16 upgraded from F15 (which had been update from previous releases)

How reproducible:
Always, after reboot

Steps to Reproduce:
1.
2.
3.
  
Actual results:
System time off by UTC offset, but in the wrong direction 

Expected results:
System time correct after boot.

Additional info:

Comment 1 Michal Schmidt 2012-06-27 17:02:57 UTC

Do you have /usr on the root filesystem, or as a separate mount?

Comment 2 Bob Hockney 2012-06-27 17:57:45 UTC

(In reply to comment #1)
> Do you have /usr on the root filesystem, or as a separate mount?

/usr is separate filesystem

Comment 3 Bill Nottingham 2012-06-27 17:58:48 UTC

Time is set before /usr is mounted... in that case, you need /etc/localtime to be a copy, not a symlink.

Comment 4 Bob Hockney 2012-06-27 18:40:35 UTC

Thanks, I copied the file to /etc/localtime and it works as expected.

Having /usr on a separate filesystem used to be a recomended layout, but apparently no longer is.  Can you point me to a discussion of issues I may encounter if I keep this layout?

Comment 5 Michal Schmidt 2012-06-27 18:49:46 UTC

A split /usr layout is fine, provided that the initramfs mounts both / and /usr.
See this Fedora 17 feature page:
https://fedoraproject.org/wiki/Features/UsrMove

Comment 6 Bob Hockney 2012-06-27 20:52:51 UTC

Not sure if there is a more direct way to do this, but I forced initramfs to mount /usr by setting a symlink in /usr/sbin/init to /sbin/init, and then passing init=/usr/sbin/init to the kernel at boot time.

I can then use a symlink for /etc/localtime, and this also eliminated a few other error messages I was seeing.

Comment 7 Michal Schmidt 2012-06-27 21:50:33 UTC

An initramfs created using the version of dracut that's currently in F16 updates-testing should be able to mount /usr. The "usrmount" dracut module does it.
https://admin.fedoraproject.org/updates/FEDORA-2012-9063

Comment 8 Bob Hockney 2012-06-27 23:01:02 UTC

The dracut in F16 updates-testing works for me!

Perhaps when this is pushed to updates the resolution on this should be changed to ERRATA from NOTABUG.  Once I looked into it, more that just the system time was broken by /usr not being mounted in initramfs.  I consider this a bug.

Comment 9 Michal Schmidt 2012-06-28 09:19:09 UTC

Out of curiosity - what where the other problems that you saw?