On Wed, 27 Sept 2023 at 09:39, Mantas Mikulėnas <graw...@gmail.com> wrote:
> It might be an issue with the kernel driver for your Ethernet interface, > then (as setting the interface 'up/down' usually reinitializes the > controller) – or possibly a physical issue with your cable or your switch, > but it doesn't seem like the kind of issue that userspace configuration > should be *able* to lead to in the first place. (...except maybe for EEE > "power saving" stuff that might tip over a really marginal link.) > What doesn't make sense is that this had previously worked, although it's possible that the network hardware has changed since it was previously tested. > (It's sort of like blaming a segfault crash on the user: if a program > crashes, that's inherently a bug regardless of configuration. Here it's > similar: if the Ethernet cable is really connected but the driver still > reports "no carrier", that's either an interface issue or – if you see the > same on multiple Pi's – perhaps a NIC driver issue, but it's not something > that configuration ought to be *able* to do.) > OK, in that case if this persists I'll have to look at upgrading the whole system, which I'm trying to avoid doing. But: > Use the "drop-in" system (dhcpcd.service.d/*.conf), e.g. via `systemctl > edit dhcpcd5`. Add a few ExecStartPre= commands in [Service] to have it > "manually" bring the interface up, then down (possibly with a 'sleep .5' > after each), and hopefully when dhcpcd brings it up the /second/ time it > will work. > This has worked: [Service] ExecStartPre=ip addr ExecStartPre=ip link set eth0 down ExecStartPre=ip link set eth0 up ExecStartPre=ip addr (the "ip addr" calls are just to log the before/after state to journal). It's booted in that state several times now successfully. I'll need to do more testing yet but I am inclined to leave it at that (I hate workarounds rather than actually fixing the issue but I suspect this is far as I'll get). Thank you (massively!) for your assistance on this. -- Mark Rogers
