|
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@xxxxxxxxxxxxxxx>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.serviceThanks! 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
