<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Sept 2023 at 20:41, Mark Rogers <<a href="mailto:mark@more-solutions.co.uk">mark@more-solutions.co.uk</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>(I should be able to find another Pi to test for any physical hardware issues, I'll try that tomorrow.)</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>(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.)</div><div><br></div><div>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? <br></div></div><span class="gmail_signature_prefix">-- </span><br><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><br></div></div></div></div></div></div>