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 <[email protected]>
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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/arm
