If one has selected: systemd ifupdown-scripts ifupdown (standalone, not work busybox) Then the lo interface will be up, but with no address assigned. The reason is that the systemd unit that is part of of ifupdown-scripts, network.service, flushes the address(es) from "lo" before calling ifup -a. It is normal for lo to already be up, but not via ifupdown, and ifup -a will complain if it run in this state. The address flush leaves "lo" in an up but with no address state. In that state, busybox ifup will configure lo without complaint and give it an address. This is what we want. But standalone ifup will skip the interface and not configure it. This is not what we want.
There is another issue that we discovered with the way buildroot's network.service works with systemd. Systemd will bring the lo interface up itself early in the boot. Later, when network.service runs, it will remove the address from the lo interface, as part of the ExecStart command in network.service to do exactly that. At this point lo no longer has an address. Then network.service runs ifup -a and properly configures lo. There a window, after the address is removed from lo and before ifup runs, where lo is not configured correctly. Anything that expects lo to be configured will fail to start correctly if it happens to hit this window when it tries to, e.g., bind a socket to an address on the lo interface. Since the systemd init design is that lo is already up, there are services that do this and will randomly fail. It's not necessary to be After network.target in order to use loopback.
So what do you suggest Trent?
THank you for your report. The issue tracker for the Buildroot project has been moved to the Gitlab.com issue tracker: https://gitlab.com/buildroot.org/buildroot/-/issues We are taking this opportunity to close old issues in this old tracker. If you believe your issue is still relevant, please open one in the new issue tracker. Thank you!