I am doing some testing with F22 on a Cubieboard2.

timedatectl reports:

      Local time: Tue 2015-09-01 15:32:05 EDT
  Universal time: Tue 2015-09-01 19:32:05 UTC
        RTC time: Thu 1970-01-01 00:04:04
       Time zone: America/Detroit (EDT, -0400)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: yes
      DST active: yes
 Last DST change: DST began at
                  Sun 2015-03-08 01:59:59 EST
                  Sun 2015-03-08 03:00:00 EDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2015-11-01 01:59:59 EDT
                  Sun 2015-11-01 01:00:00 EST

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

hmmm.  What is this about this warning?  All I did was select the timezone from the config screen...

Anyway.  If I boot up without a network connection, the time stays at Jan 1 1970.

I then set the time with the 'date' command and did:

touch /var/lib/systemd/clock
chown systemd-timesync:systemd-timesync /var/lib/systemd/clock

And rebooted.  Time is once again at Jan 1 1970.  I checked:

# ls -ls /var/lib/systemd/
total 16
4 drwxr-xr-x. 2 root             root             4096 Aug 23 13:39 catalog
0 -rw-r--r--. 1 systemd-timesync systemd-timesync    0 Sep  1 15:27 clock
4 drwxr-xr-x. 2 root             root             4096 May 21 15:06 coredump
4 -rw-------. 1 root             root              512 Jan  1  1970 random-seed
4 drwxr-xr-x. 2 root             root             4096 Aug 23 13:58 timers


So clock has a good timestamp.  Maybe the wrong chown names?  Or something still yet?



On 09/01/2015 02:38 PM, Dennis Gilmore wrote:
On Tuesday, September 01, 2015 01:03:03 PM Robert Moskowitz wrote:

On 09/01/2015 12:14 PM, Robert Nelson wrote:

On Tue, Sep 1, 2015 at 11:10 AM, Robert Moskowitz <rgm@htt-consult.com> 

wrote:

How is system time set?  Is ntpdate run after the network is ready? How
long does it retry waiting for the network to be available?

I have seen a number of challenges becuase the system time is bac at the
epoch start as there is no battery rtc.  And  I wonder how many armv7
boards have a battery to maintain time across boots?

Minimally, a process could right the time, in the proper format, to a
file,
say /etc/currenttime every 5 min and at shutdown.

Then date can be run early in the boot process, piping this file in.  It
would not be perfect and does not help, much for new installs, but better
than epoch start.

Plus /etc/currenttime can be at least set to the image build date/time so
not even firstboot will be at epoch start.

systemd v215+ has a nice feature to take care of this:

systemctl enable systemd-timesyncd.service

Thanks!  I see that this DOES work even when no network.  It would be
good if the images came with this enabled and with the time set to the
build date/time, so we had a better starting time a firstboot.

Without a battery backed RTC its really not that useful.  Picture 6 or 10 
months after a release, does it matter if the time is half a year to a year 
off or 35 years off? 

I am just trying to understand what problem you think this solves. chronyd or 
timesyncd should fix up the time as soon as you get a network connection.

Regards

Dennis


_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm