Reboot delay due to networking
With a few of the new images, I noticed that reboots were taking a while - they were stuck on some networking related bits. I'm not sure why it fixed it, but I moved the eth0 network definition from /etc/network/interfaces.d/eth0 to directly in /etc/network/interfaces (and removed the other file) and changed the inet6 entry from dhcp to auto. Reboots are fast now.
I get the pattern of splitting various configuration out to individual files in *.d/ but never really understood it for networking when interfaces are fixed. For stuff like USB ethernet cards and modular wifi, whatever - but for the integrated ethernet port of an SoC? Keep it simple.
Comments
On investigation I find that: (1) the "stop" phase of the ifup task for eth0 is running for 90 seconds and then timing out; (2) if I try to run the "ifdown eth0" command manually it gets stuck waiting for the lock on the eth0 interface state file; (3) the state-file lock is still being held by the original "ifup" command which brought up the interface (this command is still running), and "lslocks" shows this and several other lockfiles being held open for write-lock by various programs such as chrond and ate, and there's a lock on "run/..." apparently being held by a process which no longer exists!
All of this suggests that something is a bit amiss in the file-locking logic in the kernel, and since I don't see similar problems on Stretch or Buster on i386 or AMD64 systems I suspect it may be specific to arm64 or to the Meson-specific code. Maybe something is amiss with muted handling?