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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm