Fazik83 0 October 7 Hello Guys, I have a problem with time in my Orange Pi Plus 2E. I have installed yesterday Linux orangepiplus2e 4.19.62-sunxi #5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l GNU/Linux and and I can't set right time. root@orangepiplus2e:~# hwclock 2019-10-07 16:52:25.994362+02:00 root@orangepiplus2e:~# date Mon Oct 7 16:56:46 CEST 2019 Now is 16:40 hour. Yesterday different was about 20 minutes, today is about 4 minutes. How to align the time? root@orangepiplus2e:~# hwclock --test -D hwclock: use --verbose, --debug has been deprecated. hwclock from util-linux 2.33.1 System Time: 1570460247.618048 Trying to open: /dev/rtc0 Using the rtc interface to the clock. Last drift adjustment done at 1570392310 seconds after 1969 Last calibration done at 1570392310 seconds after 1969 Hardware clock is on local time Assuming hardware clock is kept in local time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2019/10/07 16:53:13 Hw clock time : 2019/10/07 16:53:13 = 1570459993 seconds since 1969 Time since last adjustment is 67683 seconds Calculated Hardware Clock drift is 0.000000 seconds 2019-10-07 16:53:11.370984+02:00 Test mode: nothing was changed. root@orangepiplus2e:~# timedatectl status Local time: Mon 2019-10-07 16:59:06 CEST Universal time: Mon 2019-10-07 14:59:06 UTC RTC time: Mon 2019-10-07 16:54:51 Time zone: Europe/Warsaw (CEST, +0200) System clock synchronized: no NTP service: inactive RTC in local TZ: yes Warning: The system is configured to read the RTC time in the local time zone. This mode cannot 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'. 0 Share this post Link to post Share on other sites
ifThenERROR 0 October 15 I, too, encountered this issue on a Nanopi Neo (original, not Neo2). The system was flashed with a brand new image of Armbian Buster two days ago. No other software set up yet. No custom settings except the initial user creation yet. But right from the start the clock was screwed up. It showed 07/16/2019 7:40 AM as date and since did not update. I kept the Neo running for a day and did serveral reboots, but no change. Flashed again to be sure, same issue. Can't update because the date is so long in the past. The update servers' certificates seemingly are from the future. Why do I think it's related to the problem above? root@nanopineo:~# timedatectl status Local time: Thu 2019-07-18 05:58:17 UTC Universal time: Thu 2019-07-18 05:58:17 UTC RTC time: Sat 1970-01-03 01:26:59 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: no NTP service: inactive RTC in local TZ: no Note the clock is not synchronized and the NTP service is inactive, same as above. So the NTP is inactive you say? root@nanopineo:~# systemctl status ntp * ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-07-18 05:56:54 UTC; 2min 24s ago Docs: man:ntpd(8) Process: 1068 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS) Main PID: 1074 (ntpd) Tasks: 2 (limit: 856) Memory: 812.0K CGroup: /system.slice/ntp.service `-1074 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 104:110 Jul 18 05:56:54 nanopineo ntpd[1074]: Listen normally on 3 eth0 192.168.178.24:123 Jul 18 05:56:54 nanopineo ntpd[1074]: Listen normally on 4 lo [::1]:123 Jul 18 05:56:54 nanopineo ntpd[1074]: bind(21) AF_INET6 fe80::1932:c3bf:c5ff:1a1e%3#123 flags 0x11 failed: Cannot assign requested address Jul 18 05:56:54 nanopineo ntpd[1074]: unable to create socket on eth0 (5) for fe80::1932:c3bf:c5ff:1a1e%3#123 Jul 18 05:56:54 nanopineo ntpd[1074]: failed to init interface for address fe80::1932:c3bf:c5ff:1a1e%3 Jul 18 05:56:54 nanopineo ntpd[1074]: Listening on routing socket on fd #21 for interface updates Jul 18 05:56:54 nanopineo ntpd[1074]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jul 18 05:56:54 nanopineo ntpd[1074]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jul 18 05:56:56 nanopineo ntpd[1074]: Listen normally on 6 eth0 [fe80::1932:c3bf:c5ff:1a1e%3]:123 Jul 18 05:56:56 nanopineo ntpd[1074]: new interface(s) found: waking up resolver Oh, looks like it's actually running! It gives a couple messages though, looking like they shouldn't be this way. Today I tried to manually set the correct date and update the system. Updating went well, but still got a dysfunct NTP. Could it be that the current image for H3s is broken? Or is the problem located at the keyboard as usual? Cheers 0 Share this post Link to post Share on other sites
Igor 1614 October 15 5 hours ago, ifThenERROR said: Could it be that the current image for H3s is broken? Or is the problem located at the keyboard as usual? The only recent change in this area, possible related, is replacing ntpdate with chrony, but since you have ntp, changes hasn't landed to images yet. If you have an option, start with self-made image. root@orangepizeroplus:~# timedatectl Local time: Tue 2019-10-15 05:30:53 UTC Universal time: Tue 2019-10-15 05:30:53 UTC RTC time: Tue 2019-10-15 05:30:54 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: inactive RTC in local TZ: no 0 Share this post Link to post Share on other sites
ifThenERROR 0 October 15 3 hours ago, Igor said: If you have an option, start with self-made image. It's a little inconvinient, but can do. To be sure I choose the correct config. ./compile.sh BOARD=nanopineo BRANCH=next KERNEL_ONLY=no RELEASE=buster Is that right? 0 Share this post Link to post Share on other sites
Igor 1614 October 15 4 minutes ago, ifThenERROR said: Is that right? Yes. Or ./compile.sh and select those options via menu. 0 Share this post Link to post Share on other sites
ifThenERROR 0 October 15 As an addition, the documentation currently states issues with thermal management: Quote Due to H3’s overheating tendencies a working throttling implementation is important when more heavy workloads should run on the board. This is implemented in legacy kernel (settings have been improved a lot by linux-sunxi community and us compared to Allwinner’s defaults), but in mainline kernel it is still Work-in-Progress which is one of the reasons that prevent us from releasing Armbian images with mainline kernel. So while you currently only get legacy images in download area you can already try to build your own images with kernel 4.x using our build system and choosing next branch or use prebuilt nightly images for some boards. https://docs.armbian.com/Hardware_Allwinner-H3/ Is that still the case and should I rather use the legacy kernel? At least the part about the available downloads seems to be outdated and the download page states „mainline based kernel 4.19.y“. 0 Share this post Link to post Share on other sites
Igor 1614 October 15 51 minutes ago, ifThenERROR said: Is that still the case No, ignore. Legacy kernels are EOL and due for removal. 0 Share this post Link to post Share on other sites
ifThenERROR 0 Thursday at 09:22 PM Ok, I compiled a new image according to the documentation and now got Armbian_5.98_Nanopineo_Debian_buster_next_4.19.79 up on the NEO. The time is correct right from the start. Strangely "timedatectl status" reports the clock as synchronized, but ntp still inactive. Did the aforementioned change take effect now? Anyhow I'm all happy! Is there anything I can do to help iron this issue out from the downloadable image so others won't run into it? 0 Share this post Link to post Share on other sites
Igor 1614 Thursday at 09:32 PM 7 minutes ago, ifThenERROR said: but ntp still inactive Perhaps because we changed to chrony package? 7 minutes ago, ifThenERROR said: Is there anything I can do to help iron this issue out from the downloadable image so others won't run into it? Help on development to push out next update sooner? Its happen in branch "arm64" https://github.com/armbian/build/tree/arm64 This is the job to be done:https://github.com/armbian/build/pull/1586#issuecomment-541457614 0 Share this post Link to post Share on other sites
ifThenERROR 0 Thursday at 10:13 PM 37 minutes ago, Igor said: This is the job to be done: Sorry, but I don't get it. What exactly needs to be done there? Do you need testing of that branch? 0 Share this post Link to post Share on other sites
Igor 1614 Friday at 06:05 AM 8 hours ago, ifThenERROR said: Sorry, but I don't get it. What exactly needs to be done there? Do you need testing of that branch? "we can also jump u-boot to 2019.10" This can be done in any branch. Change https://github.com/armbian/build/blob/master/config/sources/sunxi64_common.inc#L7 or https://github.com/armbian/build/blob/master/config/sources/sunxi_common.inc#L3 and you will notice that many u-boot patches will fail. They need to be adjusted or removed if they contribute nothing. Try. Job description = sources maintenance. Compare and adjust. If you can help maintain forum - moving topics here and there. Its also helpful. 0 Share this post Link to post Share on other sites
