Marecki

The "proper" solution, i.e. one which requires neither downgrading the kernel nor masking new capabilities, is pretty straightforward - recompile Buster systemd packages against Linux-5.8+ kernel headers. I thought my original explanation ("systemd built against kernel headers older than 5.8 does not work") made this clear, in hindsight I should have been more explicit.

Unfortunately upgrading systemd to the version from buster-backports doesn't help, that version has apparently still been built using older kernel headers: # systemctl --version systemd 245 (245.6-1~bpo10+1) +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid # systemctl show armbian-hardware-monitor.service >/dev/null Failed to parse bus message: Invalid argument # echo $? 1 (this is from a system which has been restarted several times since the systemd upgrade) Downgrading the kernel obviously does help but it's a bit of a blunt instrument, especially if one wants to run Ansible regularly rather than just for initial set-up.

Hello, In case you haven't heard about this yet, the fact that Armbian Buster Current comes with a 5.8 kernel means it suffers from this Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964926 which us caused by combining this kernel version (as well as future ones) with systemd built using older kernel headers. This bug is mostly harmless but it does at the very least prevent Ansible from managing services on affected systems due to 'systemctl show' exiting with a non-zero exit code. Unfortunately with the official Debian Buster kernel version being 4.19 it is unlikely that this will be fixed on their end.

I was going to say that I had - I did update the u-boot package - but then I realised that the version number I saw on the serial console was not the same as that in the package description. Long story short, I forgot to actually write the u-boot image to the system disc on ALL the machines I have just switched to current... Interesting that it's only been the lime2 which failed to boot under those circumstances. Anyway, one quick dd session later and everything looks in order again. Thanks for having pointed me in the right direction!

Hello, Earlier on this week I decided to upgrade the kernel and the DTBs on my Armbian cluster (quite a few different boards but all of them based on Allwinner A20) from buster-next-5.92 to buster-current-20.08.2. Having successfully completed the upgrade on several other servers, I moved on to the lime2 one - which promptly failed to come back up after the reboot. Connecting the serial console shows u-boot doing its thing without issues and the kernel beginning to boot, producing normal messages - only to suddenly freeze. When exactly the freeze occurs varies, sometimes it even happens halfway through outputting a message line - but it is definitely before the handover to init and I think it's also before initramfs kicks in. Having poked around a bit, I have narrowed the problem down to the DTB update. If I have /boot/dtb point to dtb-4.19.62-sunxi, the system comes up fine - even with the new kernel. On the other hand, as soon as I symlink it back to dtb-5.8.6-sunxi the kernel hangs. BTW. I do not use any overlays and apart from the verbosity increase I do not think I have changed anything in armbianEnv.txt since system installation. In fact, let me just post it here: verbosity=7 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun7i-a20 rootdev=UUID=REDACTED rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Any ideas how I can debug this further? If you need any more information, let me know.