Pkg xen devel - Feb 2019 - [PATCH] xen init script: don't fail when being run in domU

When installing xen-utils-V in a driver domain domU, it drags in
xen-utils-common, which also contains the init script for xenstored and
xenconsoled.

Installing the package will fail right away, because it exits non-zero
after checking whether it's running in a xen dom0 or not:

 systemd[1]: Starting LSB: Xen daemons...
 xen[7215]: Starting Xen daemons: (warning).
 systemd[1]: xen.service: Control process exited, code=exited,
status=255/EXCEPTION
 systemd[1]: xen.service: Failed with result 'exit-code'.
 systemd[1]: Failed to start LSB: Xen daemons.
 dpkg: error processing package xen-utils-common (--configure):
  installed xen-utils-common package post-installation script subprocess
returned error exit status 1

Since there's nothing to be fixed, there should not be a warning. It's
totally fine to skip xenstored, xenconsoled and qemu steps in this case,
so just exit cleanly.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033
Reported-by: Marek Marczykowski-Górecki <marmarek at
invisiblethingslab.com>
Signed-off-by: Hans van Kranenburg <hans at knorrie.org>
---
 debian/xen-utils-common.xen.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
index e16d263def..c082e3ad05 100644
--- a/debian/xen-utils-common.xen.init
+++ b/debian/xen-utils-common.xen.init
@@ -280,7 +280,7 @@ case "$1" in
 	capability_check
 	case "$?" in
 		0) ;;
-		*) log_end_msg 255; exit ;;
+		*) log_end_msg 0; exit ;; # not a dom0, skip the rest
 	esac
 	env_setup
 	xenstored_start
-- 
2.20.1

Hans van Kranenburg writes ("[PATCH] xen init script: don't fail when
being run in domU"):
> When installing xen-utils-V in a driver domain domU, it drags in
> xen-utils-common, which also contains the init script for xenstored and
> xenconsoled.
Acked-by: Ian Jackson <ijackson at chiark.greenend.org.uk>

Marek, it is actually possible to set a non-0000 uid for dom0.  I'm
afraid the right way to tell is indeed to mount /proc/xen and look for
control_d.

So if you really want to reduce the use of /proc/xen you could send
patches to Linux to advertise the relevant thing in a sane way in
/sys.

I did notice this difference:

dom0
/sys/hypervisor/properties/features:000028f0

domU
/sys/hypervisor/properties/features:000020f0

I suspect, without looking it up, thant 0x0800 is "control domain".
But, really, let us not go there...

Sorry,
Ian.

On 2/21/19 4:05 PM, Ian Jackson wrote:
> Hans van Kranenburg writes ("[PATCH] xen init script: don't fail
when being run in domU"):
>> When installing xen-utils-V in a driver domain domU, it drags in
>> xen-utils-common, which also contains the init script for xenstored and
>> xenconsoled.
> 
> Acked-by: Ian Jackson <ijackson at chiark.greenend.org.uk>
> 
> Marek, it is actually possible to set a non-0000 uid for dom0.  I'm
> afraid the right way to tell is indeed to mount /proc/xen and look for
> control_d.
> 
> So if you really want to reduce the use of /proc/xen
Current one will just work fine. There is no need to mount /proc/xen in
domU at all, since the absence will just mean that the script will think
it's not in a dom0, which is exactly what you want.
> you could send
> patches to Linux to advertise the relevant thing in a sane way in
> /sys.
> 
> I did notice this difference:
> 
> dom0
> /sys/hypervisor/properties/features:000028f0
> 
> domU
> /sys/hypervisor/properties/features:000020f0
> 
> I suspect, without looking it up, thant 0x0800 is "control
domain".
> But, really, let us not go there...
Hans