omarchy-windows-vm: a single launch click can never work from a cold start — RDP connects before the guest finishes booting, then the launch stops the VM #12710

omarchy-windows-vm: a single launch click can never work from a cold start — FreeRDP connects before the Windows guest finishes booting, gets "connection reset", gives up, and the launch stops the VM

Version: omarchy 4.0.4-1 (current repo version), kernel 7.2.5-3-omarchy, dockurr/windows container.

What happens

omarchy-windows-vm launch (e.g. via the desktop menu entry) with no running container:

1. __priv_up_wait returns as soon as the container logs contain Windows started successfully — but in dockurr/windows that message is printed when the QEMU display is ready, before the Windows guest has finished booting (a cold boot takes several minutes).
2. launch_windows immediately runs xfreerdp3. The container's RDP proxy accepts the TCP connection right away, but the guest's RDP service isn't up yet, so FreeRDP gets BIO_read ... Connection reset by peer / ERRCONNECT_CONNECT_TRANSPORT_FAILED twice within ~7 seconds and exits (freerdp_post_connect failed).
3. The script treats that as "RDP session closed" and stops/removes the container, throwing away the boot progress.

Net effect: the user clicks Windows, sees nothing, and every subsequent attempt repeats the same loop. A launch only succeeds if the container was left running long enough for the guest to fully boot (e.g. because the auto-stop was declined), or if something outside the script already waited.

Evidence (from a real cold start)

[16:48:11] xfreerdp3 starts (container started seconds earlier)
[16:48:14] BIO_read returned a system error 104: Connection reset by peer
[16:48:18] BIO_read returned a system error 104: Connection reset by peer
           freerdp_post_connect failed
RDP session closed. Stopping Windows VM...

Reconnecting ~5 minutes later (container still running, guest fully booted) connects instantly and the RDP session works fine — confirming the guest just wasn't ready yet.

Suggested fix

Before invoking xfreerdp3 in launch_windows, poll until the guest's RDP service actually answers. A plain TCP connect is not sufficient (the proxy accepts immediately); probe with a real X.224 connection request, e.g.:

  # The container's RDP proxy accepts TCP before the guest finishes booting;
  # poll with an X.224 connection request until the guest answers.
  local rdp_deadline=$((SECONDS + 480))
  until timeout 6 bash -c 'exec 3<>/dev/tcp/127.0.0.1/3389 && printf "\x03\x00\x00\x13\x0e\xe0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x03\x00\x00\x00" >&3 && head -c 1 <&3' 2>/dev/null; do
    ((SECONDS < rdp_deadline)) || break
    sleep 3
  done

I've been running exactly this patch locally; from a full cold start the launch now waits through the guest boot and the RDP session connects on the first click. (Alternatively, FreeRDP could be wrapped in a bounded retry loop, but the readiness probe is cheaper and keeps the single-connect behavior.)

Related but distinct: the setgid/chmod 0700 launch failure — already tracked in #11940 (closed) with open PRs #12323 / #10595 / #12019 / #12264. This issue is independent of that fix.