Shoka

I encountered this running apt-get update, not during a build.
 
Tried several fixes without success.
Eventually fixed it using info from the bug report for the last time it occurred in 2018.
here
sudo apt-key adv --keyserver pool.sks-keyservers.net --recv-keys ED75B5A4483DA07C Harry

https://github.com/armbian/build/pull/1833

Better adding them here:
https://github.com/armbian/build/blob/master/lib/general.sh#L798-L806

Fixed
 
There is a file /etc/machine-id that controls (among other things) the machine id broadcast by systemd-networkd.
It's set during first boot, by systemd-machine-id-setup.  Another thing to fix on a cloned system
 
In principal simply deleting this file and running systemd-machine-id-setup should generate a new random machine-id file.
Unfortunately systemd-machine-id-setup takes its preferred id from another file  /var/lib/dbus/machine-id I think, so you get straight back to the original, duplicated file.
Answer 2 (29) here gives a sequence that recreates a random /etc/machine-id file compatible with dbus/machine-id, and replaces the dbus/machine-id with the new /etc/machine-id.  Notes elsewhere suggest that "bad things will happen" if you replace dbus machine-id on a running system, but  as noted in that solution, a boot fixes any bad things that occur.
 
sequence here in case that link disintegrates...
# Messing with machine-id at al  sudo rm -f /etc/machine-id sudo dbus-uuidgen --ensure=/etc/machine-id sudo rm /var/lib/dbus/machine-id sudo dbus-uuidgen --ensure # immediate reboot. Done and rebooted all five machines in my test setup.
 
netadmin@ups-monitor:~$ networkctl lldp LINK             CHASSIS ID        SYSTEM NAME      CAPS        PORT ID           PORT DESCRIPTION eth0             2ddb2dd5c7ab115e… probe3           .......a... eth0              \"probe3 uplink… eth0             6c44cc9224724968… probe2           .......a... eth0              \"probe2 uplink… eth0             a304dbe115289f1c… nanopi           .......a... eth0              \"nanopir1 upli… eth0             abe4d225ff47687e… probe2           .......a... eth0              \"probe2 uplink… eth0             eaf8d1906e1149a0… probe1           .......a... eth0              \"probe1 uplink… Capability Flags: a - Station 5 neighbors listed. Yay    
 
 
Harry

 
 
 

More info, it's not a bug.
I moved the nanopi to the test network and it demonstrated the same symptoms.
 
Digging into the lldp traffic as captured by tshark.
 
chassis subtype:                 device:     Chassis ID: 8ebf95efbfdc41c5bfc98ebddaf49b68 ups_monitor 386562663935656662666463343163356266633938656264... 6c44cc9224724968bd3c53bef6a26a11 probe1      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe2      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 probe3      366334346363393232343732343936386264336335336265... 6c44cc9224724968bd3c53bef6a26a11 nanopir1    366334346363393232343732343936386264336335336265... All the orangepi r1's and (possibly the nanopir1 were cloned from the same sd card.
It looks like systemd-networkd is seeing all the r1's and the nanopi as the same device, despite the differing MAC addresses, and thus the difference between the orangepi zero, which sees only one unique device, and the ri's and the nano, which see two unique devices. It's just an unhappy coincidence that the number of unique devices seen matches the number of interfaces on the device.
 
lldpd allows per system configuration of chassis subtype and chassis ID.
 
Off to find out if the same is possible with systemd-networkd
 
Suggestion to switch ports is a good one, but I'm not sure if systemd-networkd would consider them different devices, with the those properties matching, so going down fixing that mistake first.
 
I can probably persuade systemd-networkd to use the mac address in it's lldp broadcasts, but if anyone knows where those chassis type and chassis ID strings are stored, generated from etc, I'd love to find out.
 
Thanks for the help and suggestions so far.
 
Harry
 

Pull request generated. Will consider requesting changes to 30-armbian-sysinfo if there is consensus that that change is desirable.