dziekon

For anyone struggling with Docker connectivity issues on latest Arbian minimal images, I've found solution (although, can't say if it's a good or bad solution, I'm not a sysops wizard or whatever) which does seem to work fine for my use case. Tested on "Armbian_community 24.8.0-trunk.399 Bookworm with Linux 6.6.36-current-sunxi64" By following this stackoverflow answer (https://stackoverflow.com/a/76440642/951007), I've modified netplan's default configuration file (currently "/etc/netplan/10-dhcp-all-interfaces.yaml" file) from: (...) all-eth-interfaces: match: name: '*' (...) to (...) all-eth-interfaces: match: name: 'en*' (...) and restarted the entire SBC. With this change applied, docker network adapters changed their SETUP from "configuring" to "unmanaged", as it apparently should be in the first place (although please do note that other adapters have been changed as well, so proceed with caution): $ sudo networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 end0 ether routable configured 3 wlan0 wlan off unmanaged 4 docker0 bridge no-carrier unmanaged 5 br-xxxxxxxxxxxx bridge no-carrier unmanaged 6 br-xxxxxxxxxxxy bridge no-carrier unmanaged After that, Docker was able to communicate with the outside world: $ docker run busybox ping -c 1 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: seq=0 ttl=57 time=4.741 ms (...) and was able to communicate with other docker-based services in the same network - in my case, a Spoolman instance was not able to communicate with Postgresql instance started using one docker compose file. --- Again, please do note that I'm no expert in this regard, so if you decide to follow this solution, I would recommend verifying whether other services (that require connectivity in any way) still work as expected.

I ordered the 2GB version some time ago, should arrive in about week or two, judging by the previous orders from Xunlong's shop. I have quite high hopes for it, since it should be slightly faster and much cheaper than the OPi Zero 2. Will see how the bring up goes, hopefully I'll be able to at least boot it up with minor tinkering.

The proposed change patch looks malformed, but I assume you'd like to swap the LEDs, so that green is the board's power, while red is the board's activity (currently, power)? If that's the case, it makes sense to me, and I believe this was the original behavior as present on orangepi-xunlong 4.9 kernel. As for the patch itself, maybe it would be better to send these proposals as RFCs on Github directly, gists, or even just files? Looks like the board doesn't handle large code snippets that nicely, as it doesn't support highlighting, nor collapsing for easier thread maintenance. Just some thoughts to prevent spamming this discussion thread with non-exactly-discussion things.

@ALIGMSTEN thanks for the explanation. I've seen you've started a PR with your changes for newer kernels, so I guess I'll stop working on my own PR.

Hi @ALIGMSTEN could you please clarify what do you mean by saying that kernel 6.x.y is problematic in terms of introduction of CPU frequency tables? Personally, I was able to replicate what you've done in that regard for kernel 5.19 (I'm referring to this PR: https://github.com/armbian/build/pull/5123) in both kernel 6.1 (current) and 6.2 (edge) with no issues (as in - the OS boots, works & passes sbc-bench). You can see my results summary here: https://github.com/mdziekon/armbian-build/pull/2 For now I've opened a PR against my own fork, but if you think this is the right path, there's nothing preventing me from opening a PR against main armbian repo.