Shoka

Thanks Igor.

I'm setting up a new Armbian system from a cold start. I ran armbian-config and used the personal > welcome option to set the MOTD_DISABLE options in /etc/defaults/armbian-motd. It did not do anything to the welcome screen. I asked for the header tips and updates to be excluded. Looking at the resulting /etc/defaults/armbian-motd file : netadmin@ups-monitor:/etc/update-motd.d$ cat /etc/default/armbian-motd # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE="" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached netadmin@ups-monitor:/etc/update-motd.d$ The edit has been applied, but to the comment line, not the actual MOTD_DISABLE line. I don't know where the script that takes the action is located to check it, but I guess this is not intentional, and thus it needs to be updated to ignore lines beginning with # Second point, I'm reasonably sure, some time back, I put in a change to modify the script 41-armbian-config to change it's THIS_SCRIPT line to "config" rather than "armbian-config", so that it's disable syntax matched the other files in the set. At the moment, on a fresh install, it still needs armbian-config in the MOTD_DISABLE line. My build today is: Has that pull request got lost somewhere ? Harry

Next run worked for me as well. As you say probably temporary. I realize the internet is overloaded at the moment. I cannot work out if the request timed out in the build system, or the remote end responded with 504. If it timed out in the build system we should worry, since crappy internet is with us for some time, and maybe the timeout value is not long enough. If it came from the other end, nothing will help. Harry

Just got this error at the very end of a build. [ o.k. ] Checking git sources [ linux-firmware-git master ] fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Fetching updates fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/': The requested URL returned error: 504 [ .... ] Checking out error: pathspec 'FETCH_HEAD' did not match any file(s) known to git. I checked a very few minutes later and the URL https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ did eventually respond with a reasonable page, though with a huge delay. Presume that git.kernel.org had a problem, and returned the 504 error, not that the build system timed out waiting, but maybe wiser heads than me can check. If it was just lag, we may see a lot more of this sort of error, given the load on the internet at the moment.... Harry

I have a supported build host running, and successfully building and testing kernels for a few targets that I have examples of. I'm looking to extend my repertoire to building complete armbian images. I think I also want to use EXTERNAL and/or EXTERNAL_NEW to configure additional packages into the image. This has led me to this stanza: BUILD_MINIMAL (yes|no): set to “yes” to build bare CLI image suitable for application deployment. This option is not compatible with BUILD_DESKTOP=”yes” and BUILD_EXTERNAL=”yes” I can find no BUILD_EXTERNAL referenced elsewhere, should this be simply EXTERNAL ? or have I missed something. Is there documentation on how EXTERNAL and EXTERNAL_NEW parameters are invoked? Harry

Igor, as far as I can tell your documentation omits mention of the SYNC_CLOCK parameter to the build scripts. If your build host is a system already synced to NTP, for example by systemd-timedated this fragment from general.sh 895 # sync clock 896 if [[ $SYNC_CLOCK != no ]]; then 897 display_alert "Syncing clock" "host" "info" 898 ntpdate -s ${NTP_SERVER:- pool.ntp.org} 899 fi seems to simply mess with the system clock to no purpose. What is the objective? To force an NTP synch or to force the time into the log? timedatectl seems to give correct answers about NTP status even when chrony is managing the clock. I don't have a system to test if it works reasonably with NTPD handling the clock, but if it does, possibly preceding the ntpdate with a check using timedatectl to check if we are already synched to NTP and if so skip the ntpdate would be a good idea? Document the parameter? If we add the check for NTP synch, possibly remove the parameter? Harry

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

Looks like an expired key on http://repo.aptly.info/dists/nightly/InRelease EXPKEYSIG ED75B5A4483DA07C Andrey Smirnov <me@smira.ru> Harry

Built a kernel finally. . Not tested it yet, but it built with no errors. The final total of packages missing from the build was: ccache aria2 libusb-1.0-0-dev Already generated a pull request to add them AND swig python-dev libncurses-dev libstb-dev (not absolutely certain this is required, but I strongly suspect it is) lzma pixz u-boot-tools Will add an additional pull request to add those additional seven packages to the required list. Harry

And another missing component. libncurses-dev. Now struggling with the STB truetype renderer. I can see its missing, but cant find a package for it Its use in u-boot is discussed here. There is a github repository, not sure how it should be installed by the build script. Harry

I understand the development teams position entirely. I'm only reporting the issues I've come up against, because they are rooted in required packages that are not identified in the existing install set up. I've put in a pull request to add the first three omissions to the hostdeps list, since even the supported host configuration is also vulnerable to upstream changes to the set of standard packages. I'll put in requests to add these two as well as any more I find. So far none of the issues I've found are inherent in the choice of host, I suspect I would have has similar issues with a fresh Ubuntu install. Possibly not if those packages are installed by default in that release of Ubuntu, but it's dangerous to rely on that.

More missing packages. Getting further now I have swig and python-dev installed. Still failing though. Harry

Suggested changes to general.sh 796 export LC_ALL="en_US.UTF-8" 797 798 # packages list for host 799 # NOTE: please sync any changes here with the Dockerfile and Vagrantfile 800 local hostdeps="wget ca-certificates device-tree-compiler pv bc lzop zip binfmt-support build-essential ccache debootstrap ntpdate \ 801 gawk gcc-arm-linux-gnueabihf qemu-user-static u-boot-tools uuid-dev zlib1g-dev unzip libusb-1.0-0-dev fakeroot \ 802 parted pkg-config libncurses5-dev whiptail debian-keyring debian-archive-keyring f2fs-tools libfile-fcntllock-perl rsync libssl-dev \ 803 nfs-kernel-server btrfs-progs ncurses-term p7zip-full kmod dosfstools libc6-dev-armhf-cross \ 804 curl patchutils liblz4-tool libpython2.7-dev linux-base swig aptly acl python3-dev \ 805 locales ncurses-base pixz dialog systemd-container udev lib32stdc++6 libc6-i386 lib32ncurses5 lib32tinfo5 \ 806 bison libbison-dev flex libfl-dev cryptsetup gpgv1 gnupg1 cpio aria2 pigz dirmngr python3-distutils \ 807 ccache aria2 libusb-1.0-0-dev" 808 809 local codename=$(lsb_release -sc) 810 When I get my build environment working, and can adequately test, I'll submit this as a pull request. Harry

I know I'm not supposed to pester with issues on non supported build platforms. This is probably due to my choice of build platform, but in case it's not: build is quitting with this log.... scripts/dtc/pylibfdt/Makefile:27: recipe for target 'scripts/dtc/pylibfdt/_libfdt.so' failed scripts/Makefile.build:432: recipe for target 'scripts/dtc/pylibfdt' failed scripts/Makefile.build:432: recipe for target 'scripts/dtc' failed Makefile:528: recipe for target 'scripts' failed [ error ] ERROR in function compile_uboot [ compilation.sh:204 ] [ error ] U-boot compilation failed [ o.k. ] Process terminated That first make fail seems to occur in here: 13 PYLIBFDT_srcs = $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_SRCS)) \ 14 $(obj)/libfdt.i 15 16 quiet_cmd_pymod = PYMOD $@ 17 cmd_pymod = unset CROSS_COMPILE; unset CFLAGS; \ 18 CC="$(HOSTCC)" LDSHARED="$(HOSTCC) -shared " \ 19 LDFLAGS="$(HOSTLDFLAGS)" \ 20 VERSION="u-boot-$(UBOOTVERSION)" \ 21 CPPFLAGS="$(HOSTCFLAGS) -I$(LIBFDT_srcdir)" OBJDIR=$(obj) \ 22 SOURCES="$(PYLIBFDT_srcs)" \ 23 SWIG_OPTS="-I$(LIBFDT_srcdir) -I$(LIBFDT_srcdir)/.." \ 24 $(PYTHON2) $< --quiet build_ext --inplace 25 26 $(obj)/_libfdt.so: $(src)/setup.py $(PYLIBFDT_srcs) FORCE 27 $(call if_changed,pymod) 28 29 always += _libfdt.so 30 31 clean-files += libfdt.i _libfdt.so libfdt.py libfdt_wrap.c I suspect something amiss with the python config on my build host, but python is definitely not my strong suit. Anybody suggest tests to verify the python config? Harry

I'm not inclined to use docker, nor vagrant, and I don't have access to a Ubuntu system these days, all the systems I have to hand are Linux Mint. Linux Mint tricia is a derivative of Ubuntu 18.04, the supported build host. So I'm being a naughty boy and trying to set up a build environment on an existing Mint system. I'm not expecting support from here on setting this up, but a few of the hurdles I've overcome may reflect bugs/missing documentation in the supported build system. The setup failed initially for the test for supported systems. Fixed that, not of interest here. It failed for lack of ccache, again for lack of aria2 and again for lack of libusb-1.0. I've tried to determine if those would be installed in a new Ubuntu installation, but I don't seem to be able to locate the package manifest for 18.04. So if someone can check if they are default installed, I'll forget about it, but if they are missing from a default Ubuntu install, I'll look at documenting the need for them. Harry

Looks like it's included by default, compiled in, not a module. Presumably because some users will be using SLIP connections? I understand that the kernel impact of compiling the module in is zero. Marginally irritating, I have one box with a config with two dummies. On a Raspbian box though, where dummy is a module. I guess I'm going to have to re-learn how to compile my own kernel.... from config-5.4.20-sunxi CONFIG_NET_CORE=y CONFIG_BONDING=m CONFIG_DUMMY=y <<<<<<<<<<< compiled in, not modular. # CONFIG_EQUALIZER is not set CONFIG_IFB=m # CONFIG_NET_TEAM is not set From Kconfig... config DUMMY tristate "Dummy net driver support" ---help--- This is essentially a bit-bucket device (i.e. traffic you send to this device is consigned into oblivion) with a configurable IP address. It is most commonly used in order to make your currently inactive SLIP address seem like a real address for local programs. If you use SLIP or PPP, you might want to say Y here. Since this thing often comes in handy, the default is Y. It won't enlarge your kernel either. What a deal. Read about it in the Network Administrator's Guide, available from <http://www.tldp.org/docs.html#guide>. To compile this driver as a module, choose M here: the module will be called dummy. If you want to use more than one dummy device at a time, you need to compile this driver as a module. Instead of 'dummy', the devices will then be called 'dummy0', 'dummy1' etc.

Further I've looked high and low for the dummy driver, without success. Is the dummy driver compiled in to the Armbian kernel, and if so why ? Harry

Nothing special. Its a very convenient way to keep track of whats running. The pi's show as neighbor's to the MikroTik routers I use. I'm a retired network engineer, like to keep my hand in Harry

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.

Stranger and stranger.... I have an nanopi R1 on another segment of my network, lots of devices, including buster based raspberry pi's, an antique pi running Jessie, and a MikroTik router. That behaves pretty much as expected... netadmin@nanopi:~$ cd /run/systemd/netif/lldp netadmin@nanopi:/run/systemd/netif/lldp$ ls 3 netadmin@nanopi:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 4c:5e:0c:54:93:d7 core-MikroTik ..b.r...... Local devices/et… n/a eth0 b8:27:eb:30:ff:62 namepi .......a... b8:27:eb:30:ff:62 eth0 eth0 b8:27:eb:3e:6a:ab watchpi.local.s… .......a... b8:27:eb:3e:6a:ab eth0 eth0 edc39c88bf9d4103… namepi .......a... eth0 \"timepi uplink… eth0 fe1d4a4d0ac7441e… routerpi .......a... eth0 routepi uplink Capability Flags: b - Bridge; r - Router; a - Station 5 neighbors listed. netadmin@nanopi:/run/systemd/netif/lldp$ xxd 3 00000000: 9200 0000 0000 0000 0180 c200 000e 4c5e ..............L^ 00000010: 0c54 93d7 88cc 0207 044c 5e0c 5493 d704 .T.......L^.T... 00000020: 2205 4c6f 6361 6c20 6465 7669 6365 732f ".Local devices/ 00000030: 6574 6865 7231 3020 6d67 6d74 2073 7769 ether10 mgmt swi 00000040: 7463 6806 0200 780a 0d63 6f72 652d 4d69 tch...x..core-Mi 00000050: 6b72 6f54 696b 0c2c 4d69 6b72 6f54 696b kroTik.,MikroTik 00000060: 2052 6f75 7465 724f 5320 362e 3436 2e33 RouterOS 6.46.3 00000070: 2028 7374 6162 6c65 2920 5242 3230 3131 (stable) RB2011 00000080: 5569 4153 100c 0501 ac19 1901 0200 0000 UiAS............ 00000090: 0b00 0e04 0014 0014 0000 be00 0000 0000 ................ 000000a0: 0000 0180 c200 000e b827 eb30 ff62 88cc .........'.0.b.. 000000b0: 0207 04b8 27eb 30ff 6204 0703 b827 eb30 ....'.0.b....'.0 000000c0: ff62 0602 0078 0a06 6e61 6d65 7069 0c5e .b...x..namepi.^ 000000d0: 5261 7370 6269 616e 2047 4e55 2f4c 696e Raspbian GNU/Lin 000000e0: 7578 2039 2028 7374 7265 7463 6829 204c ux 9 (stretch) L 000000f0: 696e 7578 2034 2e31 392e 3636 2d76 372b inux 4.19.66-v7+ 00000100: 2023 3132 3533 2053 4d50 2054 6875 2041 #1253 SMP Thu A 00000110: 7567 2031 3520 3131 3a34 393a 3436 2042 ug 15 11:49:46 B 00000120: 5354 2032 3031 3920 6172 6d76 376c 0e04 ST 2019 armv7l.. 00000130: 009c 0080 100c 0501 c0a8 3701 0200 0000 ..........7..... 00000140: 0300 0804 6574 6830 fe09 0012 0f03 0100 ....eth0........ 00000150: 0000 00fe 0900 120f 0103 ecc0 0010 0000 ................ 00000160: cd00 0000 0000 0000 0180 c200 000e b827 ...............' 00000170: eb3e 6aab 88cc 0207 04b8 27eb 3e6a ab04 .>j.......'.>j.. 00000180: 0703 b827 eb3e 6aab 0602 0078 0a17 7761 ...'.>j....x..wa 00000190: 7463 6870 692e 6c6f 6361 6c2e 7368 6f6b tchpi.local.shok 000001a0: 612e 6e65 740c 5c52 6173 7062 6961 6e20 a.net.\Raspbian 000001b0: 474e 552f 4c69 6e75 7820 3820 286a 6573 GNU/Linux 8 (jes 000001c0: 7369 6529 204c 696e 7578 2034 2e39 2e33 sie) Linux 4.9.3 000001d0: 352d 7637 2b20 2331 3031 3420 534d 5020 5-v7+ #1014 SMP 000001e0: 4672 6920 4a75 6e20 3330 2031 343a 3437 Fri Jun 30 14:47 000001f0: 3a34 3320 4253 5420 3230 3137 2061 726d :43 BST 2017 arm 00000200: 7637 6c0e 0400 9c00 8010 0c05 01ac 1919 v7l............. 00000210: 9502 0000 0002 0008 0465 7468 30fe 0900 .........eth0... 00000220: 120f 0301 0000 0000 fe09 0012 0f01 036c ...............l 00000230: c000 1000 005d 0000 0000 0000 0001 80c2 .....].......... 00000240: 0000 0eb8 27eb 30ff 6288 cc02 2107 6564 ....'.0.b...!.ed 00000250: 6333 3963 3838 6266 3964 3431 3033 6162 c39c88bf9d4103ab 00000260: 3863 6339 6262 3436 3130 3136 3762 0405 8cc9bb4610167b.. 00000270: 0565 7468 3006 0200 7808 0f22 7469 6d65 .eth0...x.."time 00000280: 7069 2075 706c 696e 6b22 0a06 6e61 6d65 pi uplink"..name 00000290: 7069 0e04 0094 0080 0000 5e00 0000 0000 pi........^..... 000002a0: 0000 0180 c200 000e b827 ebf9 db38 88cc .........'...8.. 000002b0: 0221 0766 6531 6434 6134 6430 6163 3734 .!.fe1d4a4d0ac74 000002c0: 3431 6538 3137 6430 3131 6537 3064 6132 41e817d011e70da2 000002d0: 3437 3104 0505 6574 6830 0602 0078 080e 471...eth0...x.. 000002e0: 726f 7574 6570 6920 7570 6c69 6e6b 0a08 routepi uplink.. 000002f0: 726f 7574 6572 7069 0e04 0094 0080 0000 routerpi........ All the armbian systems are notionally running buster and the same release of systemd-networkd. netadmin@ups-monitor:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@probe2:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@nanopi:/run/systemd/netif/lldp$ networkctl --version systemd 241 (241) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid netadmin@nanopi:/run/systemd/netif/lldp$ This has to be some difference between the armbian builds for the Orangepi r1 and the nanopi r1. This has to constitute a bug, inside armbian. I'll raise a bug and point to this thread. Harry

Some more info; looking through the networkctl code for anything related to lldp I came across this. static int open_lldp_neighbors(int ifindex, FILE **ret) { _cleanup_free_ char *p = NULL; FILE *f; if (asprintf(&p, "/run/systemd/netif/lldp/%i", ifindex) < 0) return -ENOMEM; f = fopen(p, "re"); if (!f) return -errno; *ret = f; return 0; } So looking at the /run file referenced, on the orangepi zero netadmin@ups-monitor:/run/systemd/netif/lldp$ ls 3 netadmin@ups-monitor:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… Capability Flags: a - Station 1 neighbors listed. netadmin@ups-monitor:/run/systemd/netif/lldp$ xxd 3 00000000: 5d00 0000 0000 0000 0180 c200 000e 0242 ]..............B 00000010: 1ce9 ebbe 88cc 0221 0736 6334 3463 6339 .......!.6c44cc9 00000020: 3232 3437 3234 3936 3862 6433 6335 3362 224724968bd3c53b 00000030: 6566 3661 3236 6131 3104 0505 6574 6830 ef6a26a11...eth0 00000040: 0602 0078 080f 2270 726f 6265 3120 7570 ...x.."probe1 up 00000050: 6c69 6e6b 220a 0670 726f 6265 310e 0400 link"..probe1... 00000060: 9400 8000 00 ..... netadmin@ups-monitor:/run/systemd/netif/lldp$ and on one of the orangepi r1's netadmin@probe2:/run/systemd/netif/lldp$ ls 3 netadmin@probe2:/run/systemd/netif/lldp$ networkctl lldp LINK CHASSIS ID SYSTEM NAME CAPS PORT ID PORT DESCRIPTION eth0 6c44cc9224724968… probe1 .......a... eth0 \"probe1 uplink… eth0 8ebf95efbfdc41c5… ups-monitor .......a... eth0 \"ups-monitor u… Capability Flags: a - Station 2 neighbors listed. netadmin@probe2:/run/systemd/netif/lldp$ xxd 3 00000000: 5d00 0000 0000 0000 0180 c200 000e 0242 ]..............B 00000010: 1ce9 ebbe 88cc 0221 0736 6334 3463 6339 .......!.6c44cc9 00000020: 3232 3437 3234 3936 3862 6433 6335 3362 224724968bd3c53b 00000030: 6566 3661 3236 6131 3104 0505 6574 6830 ef6a26a11...eth0 00000040: 0602 0078 080f 2270 726f 6265 3120 7570 ...x.."probe1 up 00000050: 6c69 6e6b 220a 0670 726f 6265 310e 0400 link"..probe1... 00000060: 9400 8000 0067 0000 0000 0000 0001 80c2 .....g.......... 00000070: 0000 0e02 428e 4109 de88 cc02 2107 3865 ....B.A.....!.8e 00000080: 6266 3935 6566 6266 6463 3431 6335 6266 bf95efbfdc41c5bf 00000090: 6339 3865 6264 6461 6634 3962 3638 0405 c98ebddaf49b68.. 000000a0: 0565 7468 3006 0200 7808 1422 7570 732d .eth0...x.."ups- 000000b0: 6d6f 6e69 746f 7220 7570 6c69 6e6b 220a monitor uplink". 000000c0: 0b75 7073 2d6d 6f6e 6974 6f72 0e04 0094 .ups-monitor.... 000000d0: 0080 0000 .... netadmin@probe2:/run/systemd/netif/lldp$ So it looks like networkctl is correctly reporting all the information available to it. So why does systemd-networkd only acquire those one or two results. ???? Harry

If you mean for lldp to be generated/read by the switch my routers do that, but this test set up is simply four Orangepi boards attached to a dumb TP-Link gigabit unit, no config possible. However all the lldp traffic is reaching the four Orange pi's, that is what the tshark network traces are about. If you keep watching the networkctl lldp output, all the peers do appear, but only two at a time for the pi r1's and only one at a time for the pi zero. Harry

This "motd" fragment has a bug/inconsistency. # any changes will be lost on board support package update THIS_SCRIPT="armbian-config" MOTD_DISABLE="" /etc/defaults/armbian-motd has : # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" This works correctly for the other "motd" fragments which contain, for instance : THIS_SCRIPT="sysinfo" MOTD_DISABLE="" but fails to disable 41-armbian-config unless the MOTD_DISABLE string includes armbian-config. I've verified that nothing untoward happens if you change 41-armbian-config to THIS_SCRIPT="config" MOTD_DISABLE="" and suppression then occurs correctly with /etc/defaults/armbian-motd set to: # add space-separated list of MOTD script names (without number) to exclude them from MOTD # Example: # MOTD_DISABLE="header tips updates" MOTD_DISABLE=" header tips updates config" ONE_WIRE="" # yes = show 1-wire temperature sensor if attached On a separate, but related note, I do use the 30-armbian-sysinfo script. However my version has a minimally modified output. My modified version first. System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: eth0: 192.168.1.5 CPU temp: 43°C Usage of /: 5% of 29G System load: 0.02 0.01 0.00 Up time: 1:18 hour Memory usage: 29 % of 238MB Zram usage: 16 % of 119Mb IP: 192.168.1.5 CPU temp: 44°C Usage of /: 5% of 29G Note the IP information starting on a new line, and the interface information included. netadmin@probe3:~$ diff ~/motd/30-armbian-sysinfo /etc/update-motd.d/30-armbian-sysinfo 141c141 < [[ -n $tmp ]] && ips+=("$intf: $tmp") --- > #[[ -n $tmp ]] && ips+=("$intf: $tmp") 143c143 < #[[ -n $tmp ]] && ips+=("$tmp") --- > [[ -n $tmp ]] && ips+=("$tmp") 199c199 < printf "\nIP: " --- > printf "IP: " I prefer my version. I'm very much a newbie on this board, I have no idea where to post the suggestion. Cheers Harry