N2+ Impervious to Timekeeping Applications

[Quantum]

Armbian current:

 

It seems that the N2+ is [i]immune[/i] to Chrony and systemd-timesyncd.  The only way I can set the date/time is manually through date -s.

 

# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-11-24 13:06:59 PST; 31min ago
 Invocation: 50da85c1116348dbbd83cca270da6ff8
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 1185 (systemd-timesyn)
     Status: "Idle."
      Tasks: 2 (limit: 4227)
     Memory: 1.6M (peak: 2.3M)
        CPU: 79ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─1185 /usr/lib/systemd/systemd-timesyncd

Nov 24 13:06:59 lab systemd-timesyncd[1185]: System clock time advanced to recorded timestamp: Mon 2025-11-24 13:06:59 PST
Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection.
Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection.
Nov 24 13:06:57 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection.
Nov 24 13:07:01 lab systemd-timesyncd[1185]: Network configuration changed, trying to establish connection.
Nov 24 13:07:11 lab systemd-timesyncd[1185]: Timed out waiting for reply from 10.2.1.10:123 (10.2.1.10).

 

No, the network configuration has na-ha-hot, changed, Spastic.  I see via tcpdump, the request going out 123/udp and the response, coming back.  The information arrives at the destination.  But it hits a hard rock head and disintegrates.  Of course if it can't set the system clock, there's no sense trying to make it set the RTC.

 

How is this possible in the 21st Century?  Does time, no longer matter to Gen Z?  Is this the precursor to the Apocalypse?  Should I convert to religion and start praying?

Edited Tuesday at 10:17 PM by Quantum

[laibsch]

10 hours ago, Quantum said:

How is this possible in the 21st Century?

 

What you need to understand is that whatever money you paid, you paid for the hardware not for software support.  So, the hardware vendor does not give you software support.  And we are just a bunch of enthusiasts trying to keep our own boards alive.  I am sure that you can understand that your understandable nonetheless misguided rant does not necessarily help in making us more enthusiastic.  Armbian provides you with some help to maintain your own board yourself.  Whenever somebody does so and provides their work back to the community you are in luck and can freeload off of their work.  Still doesn't give you the right to make demands and rant.

In your case, you are in luck as there is a person donating their expertise and time.  Let's see if @NicoD has anything to say about the issue with your board.  Buy him a coffee on Paypal or Patreon for the time he already donated to keep YOUR board alive while getting 0 cents from you so far?

[eselarm]

12 hours ago, Quantum said:

Chrony and systemd-timesyncd.

2 captains on the same ship is my first note. 

Then there is fake-hwclock and maybe an RTC onchip/silicon and/or your own or PCB vendor added RTC module like DS3231. And the battery can be almost empty. Early Debian Trixie had a bug with fake hwclock script, I already removed it years ago on SBCs where I added DS3231, but if you haven't there is the sort of 3rd captain. RPi/Raspbian users had that issue.

 

[eselarm]

And further, what do you need? I know Armbian and Opensuse use chrony instead of older ntp things. Chrony can serve the time to others, do you need that? If not remove it I would say and keep/use a standard client-only method.

[Quantum]

@laibsch:  Thanks, but your objections are worthless.  You have zero sense of humor, son.

 

@esalarm: As a Debian user since 1997 I did an aptitude purge between trying daemons.  I can not make any of them set the time, as they usually do in normal Debian.  There is something missing in the most current stable Armbian.  I wish you would try it on an N2+.

 

I am happy to use chrony, as I have for several years, although in this case it has no effect.  But the new Debians seem to be moving to systemd for everything such as this, so I adapted.  But that didn't work either.  I can't be the only one;  maybe the first?

[eselarm]

9 hours ago, Quantum said:

As a Debian user since 1997 I did an aptitude purge between trying daemons.  I can not make any of them set the time, as they usually do in normal Debian.  There is something missing in the most current stable Armbian.  I wish you would try it on an N2+.

Try what?

Do I need to guess what "the most current stable Armbian" is ? 

 

Best post an URL + sha256sum what you are doing/using. In theory, I could fairly easy merge it into booting in a KVM, it has then properly working (virtual) RTC from the host (ROCK5B or NanoPi-R6C or RPi4B), but likely needs generic Debian Trixie kernel+initrd/(DTB). That can hide potential errors with your hardware, like a dangling wire in your cable or RJ45 connector or duplicate DHCPserver in LAN or worse (criminals). Or you have ethernet time protocol working, various ethernet HW supports it, like on RPi. Or what do you use to manage your network? Recently netplan.io got pushed, that was a disaster for me, such that I banned Ubuntu now.

 

[Igor]

16 hours ago, Quantum said:

There is something missing in the most current stable Armbian.  I wish you would try it on an N2+.

It might be related to Trixie (quick test is checking this on Ubuntu variant). We fix few bugs in user space - some packages were missing due to changes in their relations ... if we are talking about hardware RTC, then it is kernel related. Generic kernels usually have only basic support for most boards we are dealing with, but still, this specific function could work different or not at all. Depending of the version and time of build. Hard to say without investigation. I added battery to my N2+ a while ago and tested RTC functionality. It worked, but its a long time ago since I did that test. I will look into  this when possible.

[Quantum]

Quote

Try what?

Do I need to guess what "the most current stable Armbian" is ? 

I kind of thought it is common knowledge, but just go here:  https://www.armbian.com/odroid-n2/

It's what I'm running.

 

Quote

Or what do you use to manage your network? Recently netplan.io got pushed, that was a disaster for me, such that I banned Ubuntu now.

lol, yes I figured that out too, and aptitude purged netplan and systemd-resolved with extreme prejudice.  In this graybeard's humble opinion these are solutions looking for problems.  overlays, overlaying overlays of overlays. 

 

The inherent (and new) systemd-networkd they've snuck in without telling anyone, does suffice and is sensible.

 

Somehow though systemd-timesyncd simply can not set the date/time, and neither can chrony which I've used for years.  Much less the hardware clock.

 

Quote

(quick test is checking this on Ubuntu variant)

Ah, I have too much time invested in Debian on the N2+, and have never had any respect for Ubongo.  But the purpose of this board is to time-control devices, so it would be nice to have the correct time.  I've always used the C2032 battery.

Edited yesterday at 12:07 AM by Quantum

[eselarm]

Same trick as in 

but with N2+ image sha256sum:

5627794e883fc3b8b9ccf918efe4e5427621761402e8e2d10b05730495fc19ce  Armbian_25.11.1_Odroidn2_trixie_current_6.12.58_minimal.i
mg.xz

and 1 reboot, then with armbian-config set my timezone to CET and reboot again:

root@odroidn2:~# timedatectl  
              Local time: Fri 2025-11-28 19:50:36 CET
          Universal time: Fri 2025-11-28 18:50:36 UTC
                RTC time: Fri 2025-11-28 18:59:21
               Time zone: Europe/Amsterdam (CET, +0100)
System clock synchronized: no
             NTP service: active
         RTC in local TZ: no

root@odroidn2:~# timedatectl  
              Local time: Fri 2025-11-28 20:00:31 CET
          Universal time: Fri 2025-11-28 19:00:31 UTC
                RTC time: Fri 2025-11-28 19:00:32
               Time zone: Europe/Amsterdam (CET, +0100)
System clock synchronized: yes
             NTP service: active
         RTC in local TZ: no

It seems it took several seconds for a sync, but nothing strange I think.

 

However, important notice is that networking has picked the wrong DNS server; It seems to assume 'router IP = DNS IP' which is not the case in my case, so several things fail, especially in-house things, not what goes outside. This is not the case when network-manager+openresolv do the network config (and no netplan.io). I run 2 computers with systemd-networkd+systemd-resolved, but that took a lot of time and reading and some config tweaking before those do simply the same as before with network-manager+openresolv. And no benefit, only that they can run slightly easier as container with own MAC-address (real HW must be off then of course) and also a bit easier as container host.

Edited yesterday at 07:32 PM by eselarm

[eselarm]

I already see what the issue is: I have configured things in such a way that strange/new machines get served differently then known/existing ones. In addition, the known/existing ones need an extra setting in case of systemd-resolved. This makes a quick test with some random VM like this appear doing things wrong, but is actually expected.

If I purge --autoremove netplan.io and put a symlink ln -sf /usr/lib/systemd/network/89-ethernet.network.example /etc/systemd/network/89-ethernet.network, there is working network again after reboot or restart service.
 

[Quantum]

esalarm: personally, I tear out systemd-resolved and netplan, and just use /etc/resolv.conf. (and chattr +i)  In my LAN the gateway is designated DNS resolver running Unbound, so my situation is more normal.

 

But that's not the reason systemd-timesyncd and chrony are not working.  Neither one can set the time properly, even as properly configured.  Using tcpdump I see the 123/udp request going out to the proper machine, and the response coming back...  but it has no effect on Armbian.  No firewall blocks.  Time stays on whatever I set it to, and counts from there, always a few minutes behind or ahead.

 

There is something fundamentally wrong with current Armbian.

[eselarm]

1 hour ago, Quantum said:

There is something fundamentally wrong with current Armbian.

I don't think so, then my Virtual Machine run would fail the same way as you describe, but it doesn't, it works fine. Of course it is the meson64 kernel running on top of KVM/virt machine, the RTC for example is emulated, while for your real N2+ is a specific Amlogic SoC kernel driver I assume, so there something could be wrong. Or what about clocking tree, there are many failures possible. I know for rockchip64 there were 2 RTC modules, at some point in time 1 was chosen over the other, so a change, could also introduce issues. You could browse kernel changes/patches And also what about an unknown bad/corrupted diskblock or so. I normally use Btrfs for rootfs, so easy to check for and detect corruption. So maybe re-image again.

I am still not sure if I used the same image as you, but up to you to track that. 

You can do the same thing as I did to see if it is maybe a specific Amlogic driver issue; Run that image as VM on the same N2+, you need a network bridge with main eth port or else use NAT. Or you make it first efi bootable, then it can run easier in virt-manager GUI. N2+ is fast enough to run VMs, I even do that on ROCK3A (2GB RAM, 4x Cortex-A55).  Or use standard Debian Trixie kernel on real N2+, not sure if that works good enough. Or remove/disable RTC kernel module. Or also remove fake-hwclock stuff if you haven't already done that. I did not do it for this VM run, but when real RTC+battery, I would remove or disable it.

[Quantum]

I don't understand then, what is the problem?