<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Sept 2023 at 09:39, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.)<br></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div></div><div>(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.)<br></div></div></div></blockquote><div><br></div><div>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:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div>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.</div></div></blockquote><div><br></div><div>This has worked:</div><div><div style="margin-left:40px"><span style="font-family:monospace">[Service]</span><br><span style="font-family:monospace">ExecStartPre=ip addr</span><br><span style="font-family:monospace">ExecStartPre=ip link set eth0 down</span><br><span style="font-family:monospace">ExecStartPre=ip link set eth0 up</span><br><span style="font-family:monospace">ExecStartPre=ip addr</span><br></div></div><div><br></div><div>(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).</div><div><br></div><div>Thank you (massively!) for your assistance on this.<br></div><br></div><div class="gmail_quote">-- <br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div style="font-size:12.8px"><span style="font-size:12.8px">Mark Rogers</span></div></div></div></div></div></div></div></div>