Bug 835962 - systemd not setting system time correctly
Summary: systemd not setting system time correctly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-27 16:49 UTC by Bob Hockney
Modified: 2012-06-28 09:19 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-27 18:49:46 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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?


Note You need to log in before you can comment on or make changes to this bug.