Package: hyperv-daemons

Version: 6.12.115-2

Severity: normal

Tags: patch



Dear Maintainer,



On trixie Hyper-V guests, every upgrade of hyperv-daemons leaves

hv-kvp-daemon.service and hv-vss-daemon.service stopped until the next

reboot. While they are down, the Hyper-V host no longer sees the guest's IP

addresses (Get-VMNetworkAdapter shows none) and host-side backups lose the

VSS freeze.



Steps to reproduce, on a Hyper-V guest with hyperv-daemons installed and

hv-kvp-daemon running:



  # systemctl is-active hv-kvp-daemon

  active

  # apt-get install --reinstall hyperv-daemons

  # systemctl is-active hv-kvp-daemon

  inactive



We saw this on all 9 guests we checked, when unattended-upgrades took

hyperv-daemons from 6.12.113-1 to 6.12.115-2 on 2026-11-03 and 2026-11-04.

It happened the same way earlier with 6.12.111-1 to 6.12.113-1. Whether the

units are enabled makes no difference. The journal shows the stop during the

dpkg run and no start after it:



  systemd[1]: Stopping hv-kvp-daemon.service - Hyper-V key-value pair (KVP)
daemon...

  systemd[1]: hv-kvp-daemon.service: Deactivated successfully.

  systemd[1]: Stopping hv-vss-daemon.service - Hyper-V volume shadow copy
service (VSS) daemon...

  systemd[1]: hv-vss-daemon.service: Deactivated successfully.



Cause: debian/rules.real installs the units with



  dh_installsystemd --name hv-$$service-daemon --no-enable --no-start



With debhelper 13.24.2 this generates, in preinst:



  if [ -z "$DPKG_ROOT" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ]
; then

          deb-systemd-invoke stop 'hv-kvp-daemon.service' >/dev/null || true

  fi



Because of --no-start, the generated postinst code never starts the unit.
The

hand-written postinst then runs



  # On upgrade make sure running daemons are restarted

  systemctl try-restart hv-kvp-daemon.service hv-vss-daemon.service



but preinst has already stopped the units, so try-restart does nothing. Most

installations do not notice, because hyperv-daemons is upgraded together

with a new kernel, and at the next boot udev starts the units through their

device binding. Guests that are not rebooted after unattended upgrades stay

without KVP and VSS until they are.



Proposed fix: add --no-stop-on-upgrade. The units then keep running through

the upgrade, and the existing try-restart in postinst restarts them on the

new binaries, which is what its comment says it is for. I built a test

package in a trixie container with debhelper 13.24.2, with the same flags

as above. Adding --no-stop-on-upgrade removes only the preinst stop block;

the generated postinst and prerm are unchanged. The patch is against

debian/latest and applies to debian/6.12/trixie with an offset.
--- a/debian/rules.real

+++ b/debian/rules.real

@@ -679,7 +679,7 @@

        $(dh_binary_pre)

        $(call make-tools,tools/hv) install

        for service in kvp vss; do \

-               dh_installsystemd --name hv-$$service-daemon --no-enable
--no-start \

+               dh_installsystemd --name hv-$$service-daemon --no-enable
--no-start --no-stop-on-upgrade \

                        || break; \

                dh_installinit --name hv-$$service-daemon \

                        || break; \



A fix in a trixie point release would be appreciated, since stable guests

are the ones running unattended-upgrades.



Thanks,

Rex