On Wed, Sep 27, 2023 at 12:14 PM Mark Rogers <m...@more-solutions.co.uk> wrote:
> 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). > 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
