On Wed, Sep 27, 2023 at 12:14 PM Mark Rogers <mark@xxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, 27 Sept 2023 at 09:39, Mantas Mikulėnas <grawity@xxxxxxxxx> 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).
So now I'm curious: if the first command you run is to bring the interface *down*, then what exactly brought it up?
Normally interfaces start in (administrative) 'down' state until something – such as dhcpcd – brings them up (and starts waiting for carrier, etc). But if this is in ExecStartPre and dhcpcd isn't running yet, then how is eth0 'up'?
Mantas Mikulėnas
