On Wed, Sep 27, 2023 at 11:23 AM Mark Rogers <m...@more-solutions.co.uk> wrote:
> On Tue, 26 Sept 2023 at 20:41, Mark Rogers <m...@more-solutions.co.uk> > wrote: > >> (I should be able to find another Pi to test for any physical hardware >> issues, I'll try that tomorrow.) >> > > I have today tested on a different Pi, different PSU, different cable, all > with exactly the same results. There is definitely something about the > early boot stages which is different from later on that means bringing the > network up early (as happens now) will usually fail. > > (Some more background: This is a heavily modified install for a specific > application so it's almost certainly something I have broken somewhere. > However it has worked for years, I'm trying to resolve an issue on a unit > that was returned because of physical damage to the SD card, so I've > rebuilt it from an old image and now have this problem. I just need to > break down the boot sequence to find out which step is causing the > interface to get into a state where it fails like this. Systemd version is > 241.) > 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.) (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.) > > Alternatively I guess there's the workaround option: detect the condition > at a later stage of the boot and run the down/up sequence to fix it. If I > try that, where is likely the best place in the sequence to put it? If I > wanted to make it, in effect, part of the dhcpcd unit (in that when dhcpcd > starts it first runs a down/up script), how should I do that without > modifying system dhcpcd unit files? > 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. -- Mantas Mikulėnas
