QWT-NG 4.3.7 (agent 24cf973)

Finishes the AppVM shutdown-loop fix — and removes what 4.3.6 left behind

4.3.6 stopped AppVMs from reboot-looping, and its release notes claimed "zero reboot requests
logged". That claim was wrong, and this release fixes what it hid.

What actually happens. The PV disk driver (xenvbd) files a "restart to complete installation"
request on every AppVM boot — an AppVM's system disk is volatile, so the device configuration
that would satisfy the request is forgotten at every shutdown. With AutoReboot=1 (4.3.4 and
earlier) that request became the silent reboot loop. With AutoReboot=0 (4.3.6) it became a
modal prompt — "Xen PV Storage Host Adapter needs to restart the system to complete
installation" — shown on the dom0 desktop on every AppVM start, with the xenbus_monitor
service wedged in STOP_PENDING behind it. Clicking Yes reboots the qube, and the demand returns
on the next boot.

The fix. xenbus_monitor now ships disabled, on every qube class. Nothing in the
unattended QWT flow needs it: the installer performs its own reboots at the right moments. The
per-boot payload re-asserts the disable in case a PV driver package upgrade re-registers the
service. No prompt, no wedged service, no reboot loop.

Tested: the defect was first reproduced on an unfixed 4.3.6 template (fresh AppVM: dialog
present, monitor wedged — so every acceptance check has been seen to fail), then 4.3.7 was
verified end to end on two paths: an in-place upgrade of a live 4.3.6 template (2 AppVM cold
boots), and a fresh template image carrying QWT-NG 4.3.2 upgraded to 4.3.7 (3 AppVM cold
boots). All five boots: no dialog, monitor Disabled/Stopped, zero reboot requests executed,
network up. The PV drivers still file their per-boot request on an AppVM — it is now inert.
A direct stock-4.2.2 → 4.3.7 run was not part of this pass; that upgrade machinery is
unchanged since it was validated for earlier 4.3.x releases.

Also fixed (found by review of 4.3.6)

• qubesdb connection leak in the network service. QwtngNetSetup opened a new qubesdb
  connection every 2 seconds and never closed any (~43k/day); qubesdb would eventually stop
  answering for every consumer in the guest. Now one connection for the service's life, every
  read buffer freed, dead connections self-heal. Measured flat handles and stable memory.
• Fail-closed service install. 4.3.6 deleted stock network-setup.exe before confirming its
  replacement service registered; a failed registration shipped a template with no network
  applier at all while reporting success. Now the stock binary is only removed after the
  replacement demonstrably exists, and registration is retried through Windows'
  marked-for-delete window.
• StandaloneVMs no longer keep silent-AutoReboot armed forever (4.3.6 reset it only on
  templates).
• Log rotation now bounds the real log directory (Q:\Qubes Logs on the private volume —
  4.3.6 pruned a directory QWT no longer writes to, while the real one grew without bound).
• A failed compile of the network service can no longer silently ship the previous build's
  binary.

Known issue (upgrade installs only, cosmetic)

When upgrading a template that already runs QWT-NG, the install result may show
updater_agent: "error: relay compile failed (csc rc=1)" — the old updates-relay executable can
be locked by a running updater task at that moment. The relay is unchanged since 4.3.6, so the
already-installed copy keeps working; nothing is lost. Will be made retry-clean in the next
release.

Install

RPM in dom0, or the ISO/tarball inside the template. Install into the template, not an AppVM,
and let the template shut down at the end. Upgrading from 4.3.4/4.3.6 is an in-place upgrade — no
uninstall needed.

Created your Windows qube by hand (no qvm-create-windows-qube, no dom0 RPM)? Two dom0-side
settings are required or the Qubes Update tool fails against the qube with errors like
mkdir -p /run/qubes-update/& exit:

qvm-features <qube> vmexec 1
qvm-prefs    <qube> qrexec_timeout 1800

Set them on the template/standalone; AppVMs inherit both. The README now documents this
prominently (new section near the top).

Do not run the Qubes updater inside a Windows AppVM: finish updates in the template and let it
reboot itself, or the AppVM will retry forever against its volatile root.