Check network connectivity before omarchy-update starts making changes

[lavrinovich86]

What happened

I ran omarchy-update about 30 seconds after boot. Wi-Fi had associated with the access point, but DHCP had not yet handed out an address. The update still pruned the package cache, took a Snapper snapshot, and started the stay-awake inhibitor before it reached omarchy-update-keyring, where pacman -Sy failed:

Update Arch signing keys
error: failed retrieving file 'multilib.db' from mirror.omarchy.org : Could not resolve host: mirror.omarchy.org
warning: fatal error from mirror.omarchy.org, skipping for the remainder of this transaction
error: failed retrieving file 'core.db' from mirror.omarchy.org : Could not resolve host: mirror.omarchy.org
error: failed retrieving file 'extra.db' from mirror.omarchy.org : Could not resolve host: mirror.omarchy.org
error: failed retrieving file 'omarchy.db' from pkgs.omarchy.org : Could not resolve host: pkgs.omarchy.org
warning: fatal error from pkgs.omarchy.org, skipping for the remainder of this transaction
error: failed to synchronize all databases (failed to retrieve some files)

Something went wrong during the update!
...
'/usr/bin/setpriv' terminated by signal TERM.

The journal shows the timing:

19:24:26  boot
19:24:46  wlp98s0: config -> ip-config (dhcp4: beginning transaction, timeout 45s)
19:24:56  omarchy-update started
19:25:06  snapper create (snapshot 151)
19:25:17  pacman -Sy --noconfirm archlinux-keyring  -> Could not resolve host
19:25:31  wlp98s0: ip-config -> failed (reason 'ip-config-unavailable')
19:25:39  reconnected via another AP, lease 192.168.0.129, DNS fine

The root cause was on my network, not in Omarchy. But the update left behind a snapshot for an update that never ran, and the only message was a generic "Something went wrong" with a red setpriv terminated by signal TERM line that looks like a crash. That line appears to come from the stay-awake inhibitor being stopped during cleanup.

Suggestion

Add a network preflight next to omarchy-update-requires-free-space, before omarchy-update-pkg-prune and omarchy-snapshot create. For example, an omarchy-update-requires-network script that:

1. Checks that a default route exists (omarchy-network-status already uses ip route get 1.1.1.1).
2. Checks that the mirror hosts resolve (for example getent hosts mirror.omarchy.org).
3. Optionally waits a short time (such as nm-online -s -q -t 30) for an interface that is still activating.
4. Otherwise exits with a clear message, for example "No network connection. Connect to the internet and run the update again." It would honour OMARCHY_UPDATE_FORCE=1 like the free-space check does.

This would stop before any snapshot or cache change and show the actual reason. It also covers captive portals, VPN switches and early-boot races.

Related: #12455 proposes a download/apply split for connections that drop mid-update. This suggestion is narrower: it covers the case where there is no connection at the start.

A smaller, separate improvement: hide or reword the setpriv terminated by signal TERM line on the failure path, since it is expected cleanup and not an error.

System

• Omarchy 4.0.0.r2304.g7b336b1-1
• Kernel 7.2.5-4-omarchy
• NetworkManager + wpa_supplicant, systemd-resolved (stub mode)

Filed by Claude Opus 5.5 via Claude Code.

[tayfuryldz]

This seems worth catching before the snapshot/cache work. I would avoid a generic “internet is up” check though, because a successful ping doesn't tell us whether the endpoints the updater actually needs are reachable.

A cheap DNS lookup for the Omarchy package host plus one Arch mirror would cover the failure shown here. If that fails, exit with something explicit like “network/DNS not ready; no changes made.” Then the existing package operations remain the real authority once the preflight passes.