systemd: order update-engine after network-online.target

[Prachi194agrawal]

update-engine.service currently starts, and can mark a newly-updated
partition as successful (~1 minute post-reboot), with no dependency on
network availability. If a regression leaves the instance without
network access, recovery today requires manual intervention via the
serial console instead of an automatic rollback.

This adds After=/Wants=network-online.target so update-engine only
starts once network-online.target has been reached.

Wants= vs the Requires= suggested in the issue

I used Wants= instead of Requires=. systemd.special(7) warns
against Requires= on network-online.target, since it would stop
update-engine outright if that target were ever deactivated, rather
than simply deferring startup. Wants=+After= gives the same
ordering without that failure mode. Happy to switch back if there's a
reason Requires= is actually wanted here.

Verification

Verified with systemd-analyze verify (no syntax errors, no
dependency cycles). I was not able to boot-test this on a real Flatcar
image (no QEMU/KVM available in my current setup) - would appreciate a
maintainer or CI confirming actual boot/rollback behavior before merge.

Not included

The issue also asks for documentation of an opt-out drop-in unit for
operators who rely on the current behavior. Leaving that out of this
PR to keep it small/reviewable; happy to follow up with a
flatcar-website docs PR if that's wanted.

Fixes flatcar/Flatcar#521

[Copilot]

Pull request overview

This PR adjusts the update-engine.service systemd unit ordering so the update engine is started only after network-online.target is reached, reducing the chance of prematurely marking an update “successful” before networking is available (which can otherwise block automatic recovery/rollback in network-regression scenarios).

Changes:

• Add After=network-online.target to defer update-engine.service start until network-online.target is reached.
• Add Wants=network-online.target to ensure network-online.target is pulled in when update-engine.service starts.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Prachi194agrawal]

Following up with something I found on closer inspection: this delays the good-partition mark, but doesn't block it indefinitely in a sustained outage. network-online.target is reached once systemd-networkd-wait-online.service finishes — including by timing out after its default TimeoutStartSec=120s, which Flatcar doesn't override — because ordering completion doesn't require that dependency to succeed. So in a fully offline boot, flatcar-setgoodroot still eventually fires, just ~2-3 minutes later than today instead of indefinitely blocked.

Still a real improvement (more time for a transient outage to resolve, or for someone to notice before the mark is permanent), and I'd expect Requires= to behave the same way here since target-reaching doesn't check dependency success either. But it falls short of the fully-automatic-rollback framing in the issue's "ideal future situation" for a sustained total outage on one boot. A real fix would need flatcar-setgoodroot gated on an explicit connectivity check, not just unit ordering — happy to open that as a separate follow-up issue if useful, rather than scope-creep this PR.