Jump to content

ifThenERROR

Members
  • Posts

    5
  • Joined

  • Last visited

  1. Sorry, but I don't get it. What exactly needs to be done there? Do you need testing of that branch?
  2. 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?
  3. As an addition, the documentation currently states issues with thermal management: 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“.
  4. 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?
  5. 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
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines