### System details

- Omarchy `4.0.1-1` / omarchy-settings `4.0.1-1` (Quattro)
- Lenovo ThinkPad P16v Gen 3 (`21RTS1CW26`), Intel Core Ultra 7 265H
- Intel Arc Pro 130T/140T iGPU + NVIDIA RTX PRO 1000 Blackwell Laptop GPU (`10de:2db8`), nvidia `610.57.04`
- Kernel `7.1.9-arch1-2`, systemd `261.2-1`, NetworkManager `1.58.1-1`
- Hyprland `0.56.2-1`, Quickshell `0.3.1-1`
- `/sys/power/mem_sleep` = `[s2idle]` (no `deep` available)
- Wi-Fi `wlp0s20f3` (iwlwifi), Thunderbolt dock, **lid closed at boot**, on AC
- Stock logind drop-ins from omarchy-settings, no local overrides at the time of capture

### What's wrong?

Booting with the lid closed on a Thunderbolt dock leaves the machine with **no Wi-Fi
for the entire session**. The network panel is empty and the Wi-Fi toggle does nothing.

The cause is not networking. logind suspends the machine ~5s into boot, that suspend
wedges and never completes, and NetworkManager — which had already gone to sleep on
logind's `PrepareForSleep(true)` — never receives the matching wake. It stays
`DISABLED (ASLEEP)` with every device `unmanaged` until something restarts it.

#### The chain

**1. logind loses the dock race and suspends.** The lid is closed at boot.
`HandleLidSwitchDocked=ignore` is set, but the dock has not enumerated yet when logind
reads the lid switch — Thunderbolt binds *two seconds later*:

```text
09:23:22.293052 systemd-logind[1039]: Suspending...
09:23:24.308388 kernel: typec port1: bound usb4_port3 (ops connector_ops [thunderbolt])
```

`HandleLidSwitchExternalPower` is unset, so the decision falls through to
`HandleLidSwitch=suspend`:

```text
$ busctl get-property org.freedesktop.login1 /org/freedesktop/login1 \
    org.freedesktop.login1.Manager HandleLidSwitch HandleLidSwitchDocked HandleLidSwitchExternalPower
s "suspend"
s "ignore"
s ""
```

**2. NetworkManager goes to sleep, as it should.**

```text
09:23:22.293864 NetworkManager[1028]: manager: sleep: sleep requested (sleeping: no  enabled: yes)
09:23:22.298096 NetworkManager[1028]: device (wlp0s20f3): state change: disconnected -> unmanaged (reason 'unmanaged-nm-disabled', managed-type: 'full')
09:23:22.328545 NetworkManager[1028]: manager: NetworkManager state is now DISABLED (ASLEEP)
```

**3. The suspend wedges and never returns.** The last kernel PM line is the filesystem
sync; `Freezing user space processes` is never reached:

```text
09:23:22.330253 systemd[1]: Reached target Sleep.
09:23:22.332733 systemd[1]: Starting System Suspend...
09:23:22.347849 systemd-sleep[1296]: Performing sleep operation 'suspend'...
09:23:22.348186 kernel: PM: suspend entry (s2idle)
09:23:22.377186 kernel: Filesystems sync: 0.028 seconds
                 <nothing further>
```

25 minutes later the unit is still starting and the process is still alive:

```text
$ systemctl status systemd-suspend.service
     Active: activating (start) since Fri 2026-08-28 09:23:22 EDT; 25min ago
   Main PID: 1296 (systemd-sleep)

$ busctl get-property org.freedesktop.login1 /org/freedesktop/login1 \
    org.freedesktop.login1.Manager PreparingForSleep
b true
```

**4. So the wake never arrives.** No `PrepareForSleep(false)`, so NetworkManager stays
asleep for the whole session with every device `unmanaged (unmanaged-nm-disabled)`.

**5. User-visible result.** The panel has no networks to show, and clicking the Wi-Fi
toggle only ever writes `off` — `WirelessEnabled` cannot become true while the manager
is asleep. Nine clicks, nine no-ops (pid 1955 is `quickshell -n -p /usr/share/omarchy/shell`):

```text
09:23:53.514401 NetworkManager[1028]: audit: op="radio-control" arg="wireless-enabled:off" pid=1955 uid=1000 result="success"
09:23:54.002191 NetworkManager[1028]: audit: op="radio-control" arg="wireless-enabled:off" pid=1955 uid=1000 result="success"
...9 identical lines...
```

#### Reproduced on every boot in the journal

Five consecutive boots, same signature each time — `Suspending...` roughly two seconds
after NetworkManager starts, `PM: suspend entry (s2idle)`, no resume, NM `DISABLED (ASLEEP)`:

| Boot ID | When | `Suspending...` |
|---|---|---|
| `044ff756` | Aug 25 10:41 | 10:41:43 |
| `0c38a308` | Aug 25 10:45 | 10:45:29 |
| `495462ad` | Aug 26 13:43 | 13:43:13 |
| `d8ea769e` | Aug 27 08:40 | 08:40:41 |
| `9c4f7ad7` | Aug 28 09:23 | 09:23:22 |

### What I expected

Booting docked with the lid closed should not attempt a suspend, and a suspend that
never completes should not leave the session permanently without networking.

### Steps to reproduce

1. Dock a laptop (Thunderbolt dock, external display, on AC).
2. Close the lid.
3. Power on and let it boot to the desktop.
4. Open the network panel — it is empty, and the Wi-Fi toggle does nothing.
5. `systemctl status systemd-suspend.service` → still `activating (start)`.
6. `journalctl -b -u NetworkManager | grep ASLEEP` → `NetworkManager state is now DISABLED (ASLEEP)`.

### Workaround

`sudo systemctl restart NetworkManager` — a fresh instance was never told to sleep, so
Wi-Fi works again for the rest of the session.

### Suggested fix

Omarchy owns lid policy since Quattro dropped hypridle, and ships
`/etc/systemd/logind.conf.d/{10-ignore-power-button,20-inhibit-delay}.conf`, neither of
which touches the lid. `HandleLidSwitchDocked=ignore` cannot win this race on its own,
because dock detection is not settled when logind reads the lid at boot. External power
*is* known that early, so adding

```ini
[Login]
HandleLidSwitchExternalPower=ignore
```

to the shipped drop-ins closes the boot-time hole while leaving lid-close-on-battery
suspend intact. I have applied exactly that locally; a reboot to confirm it is pending,
so treat the fix as proposed rather than verified.

### Notes

- **Distinct from #7788** ("Hard hang entering s2idle on lid close"): there the machine
  dies and the journal ends. Here the machine stays fully usable and logged in — only
  `systemd-sleep` is wedged, and the damage is that NetworkManager is stranded.
- **Knock-on to #7280**: because this sleep operation never finishes,
  `omarchy-sleep-lock.service` cannot ever take its inhibitor and restart-looped **662
  times** in 25 minutes. I have added the detail as a comment there rather than
  duplicating it here.
- I have not isolated *why* the suspend wedges between the filesystem sync and the
  process freezer. NVIDIA is the obvious suspect given the timing (nvidia-powerd and
  supergfxd's PCI rescan are both still initialising at 09:23:21), but I have not
  confirmed it, and it may well be a kernel/systemd issue rather than an Omarchy one.
  The Omarchy-actionable part is not taking the suspend in the first place.