Comment 7 for bug 1452644

I can confirm this, by installing network-manager, nfs-kernel-server, and setserial into a clean VM. setserial's init.d script is very demanding as it both wants to start in run level "S" (sysinit.target in systemd's mapping) *and* requires $remote_fs. But we can't start remote file systems that early if we need NetworkManager for them, this only works with very simple networking like ifupdown.

I suppose /etc/init.d/setserial wants $remote_fs as it reads stuff from /var/lib/setserial/ which might potentially be on NFS. Having setserial on an NFS /var with NetworkManager is certainly a very special case, and I suppose we could just ignore it. But I think we can relax the early startup instead.

As far as I can see, the most appropriate course here is to provide a systemd unit for setserial with more fine-grained ordering, or just a drop-in to relax the overly harsh "Default-Start: S" (as it really just Before=system-getty.slice). I don't want to completely replace the init.d script as it has lots of code (which really doesn't belong there, but I leave that to the Debian maintainer, and this is too intrusive for an SRU).