Comment 8 for bug 2063331

As an appendix to comment #7:

The situation gets interesting when we consider Desktop images. According to our network-online.target [spec] we want to "implement a common behavior across the Distro", so we should apply the same policy as described in comment #7.

An interesting case is a desktop system (e.g. laptop) that gets installed with the eth0 interface connected and autoconfigured. But the cable gets unplugged afterwards and the system starts roaming around using the internal wlan0 WiFi interface. Once the system reboots (cable still unplugged) this would (potentially) block "network-online.target".

Which is totally fine!
- As long as the normal boot process (reaching "default.target") can continue in parallel. Only applications that really depend on connectivity should wait for "network-online.target" and thus be delayed (for a reason).

- As long as no application blocks "default.target" ("graphical.target"), while at the same time waiting on "network-online.target" itself. Should we detect such applications, those applications (their systemd dependencies) need to be fixed.

Note:
On desktop systems the "wait-online" policy will not currently be enforced at all. This is due to "NetworkManager-wait-online.service" handling the situation more lax and "systemd-networkd.service" + "systemd-networkd-wait-online.service" are disabled by default on desktop images.

[spec] https://discourse.ubuntu.com/t/spec-definition-of-an-online-system/27838