Hans van Kranenburg writes ("[PATCH 1/2] xen init/maint scripts: Do nothing if
running for wrong Xen package"):
> After trying to fix this issue in the init script, we found out that the
> problem still happened for systems running with systemd.
>
> The xen-utils-V postinst and prerm have DPKG_MAINTSCRIPT_PACKAGE in
> their environment. When calling invoke-rc.d xen <action> under systemd,
> the whole circus of translation and compatibility layers is used to
> finally end up running the /etc/init.d/xen script again. However, when
> ending up there, the DPKG_MAINTSCRIPT_PACKAGE variable is lost.
>
> So, instead of trying to fix this in the init script, avoid calling
> invoke-rc.d altogether, when installing or removing for a different
> version of Xen than the currently running one.
>
> Since we only call this from two places, and the check is a one liner,
> directly put it into the prerm and postinst.
>
> Carefully quote the values on both sides of the comparison. For example,
> when removing a xen-utils-V package after rebooting into just Linux
> without Xen, the version retrieval helper will print an error like
> "ERROR: Can't find hypervisor information in sysfs!", there will be no
> useful output on stdout and it will compare an empty string with the
> version of the xen-utils package, resulting in the right action, not
> trying to stop or start anything.
>
> To avoid hitting the disappearing xenconsoled scenario, the fix has to
> be present in the maintainer scripts of the to be removed *old*
> xen-utils-V package. This means users will have to first upgrade to a
> package with this fix before upgrading to a different Xen version.
>
> Signed-off-by: Hans van Kranenburg <h...@knorrie.org>
> Closes: #932759 (1/2)
> Fixes: cc85504103 "xen init script: Do nothing if running for wrong Xen
> package"
Reviewed-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
