mathieuh

I definitely understand the lack of polish for such a new board, I already very grateful for where I got so far. As for latest being broken, I mainly wanted to make sure others looking could find the 20.11.5 build which boots fine,. I managed to get networkd and timesyncd working, and found a way to get the gmac interface name stabilized using a systemd .link file targeting the device Path. Wondering if a udev method would be preferred? In this case I believe targeting by driver will not work, for some reason it seemed to be missing when I tried. I was looking into rebuilding an image with these tweaks included, and so I could maybe contribute some of it back, but this is where I started struggling. The build environment is very picky, and while I have a few x64 linux systems around, none of them were full Ubuntu or capable: Synology NAS with docker (lacking bin fmt tools), Chromebook with linux crostini VM and docker (lacking loopback devices). Now that I finally got a build environment running, I'll try to see where I can help. Thanks for the pointers on the existing board customization. If you have any suggestions on how to improve the handling of multi adaptor boards in the scripts, I'll try to see what I can do.

I recently received my NanoPi R4S 4GB (my first SBC) and have been looking into running armbian on it (my first experience with it). A few things I've noticed: - The official 20.11.6 build (buster) does not bring up the network properly. It pings but SSH never starts. 20.11.5 or a local build from trunk seem fine. Just mentioning in case others wonder why the currently "latest" on the official page doesn't work - The gmac ethernet device naming seems unstable. It usually comes up as `eth1` but sometimes come up as `eth0`. It seems to depend on timing when the r8169 pci adapter is brought up (in the first case it's named `eth0` before being renamed to the stable `enp1s0`). Is there precedent in armbian to force the integrated adapter to a more stable name such as `eno1` ? - The `armbian-hardware-optimization` script for `rk3399` seem to hardcode `eth0` for the gmac adapter, which causes errors when it ends up as eth1: Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 234: /proc/irq/$(awk -F":" "/eth0/ {print \$1}" </proc/interrupts | sed 's/\ //g')/smp_affinity: No such file or directory Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 235: /sys/class/net/eth0/queues/rx-0/rps_cpus: No such file or directory Jan 13 01:35:46 nanopi-r4s armbian-hardware-optimization[638]: /usr/lib/armbian/armbian-hardware-optimization: line 237: /sys/class/net/eth0/queues/rx-0/rps_flow_cnt: No such file or directory - When I first played with the official 20.11.05 build, I experienced the r8169 pci adapter sometimes not being detected on command line reboots (with cable plugged in if that makes a difference). I didn't see anything particular in the logs besides the device completely missing. I'll see if I can reproduce again and post the logs. - The built-in chrony seem to ignore my DHCP provided NTP server, and insists on using its built-in list. Since this device will end up on an isolated VLAN, it'll keep failing to synchronize clock. Since this is not a desktop like device and I'm not particularly happy with NetworkManager either (I need to build up a more complex VLAN and bridge based topology), I'll probably just build a custom image without either and enable systemd's networkd and timesyncd. - The build scripts seem to pull an inordinate amount of dependencies (e.g. gcc for a bunch of platforms) even when simply building an image using "prebuilt" kernel and packages. Wondering if supporting a flow for "light" customization of images (mostly limited to package installation and adding configs) is something that was considered?