Pkg xen devel - Feb 2019 - Bug#922033: xen: driver domain does not work

Source: xen
Severity: normal

Dear Maintainer,

Driver domain running Debian buster does not work, because
xendriverdomain service is missing. Upstream xen have
/etc/init.d/xendriverdomain (and equivalent xendriverdomain.service)
that starts `xl devd` process responsible for setting up backend
devices.

Source package contains related comment in debian/not-installed:

    # It is not clear why we have our own init scripts etc. in Debian.
    # We should probably transition to using the upstream ones and
    # fix any bugs we encounter.
    etc/init.d/xendriverdomain
    etc/init.d/xencommons
    etc/init.d/xen-watchdog
    etc/init.d/xendomains
    etc/default/xencommons

I think this should be fixed exactly this way - switch to upstream
startup scripts, instead of Debian-specific ones.
Also, upstream provide systemd startup files.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.74-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190211/e7a865b4/attachment-0001.sig>

Hi,

On 2/11/19 2:15 PM, Marek Marczykowski-Górecki wrote:
> Source: xen
> Severity: normal
> 
> Dear Maintainer,
> 
> Driver domain running Debian buster does not work, because
> xendriverdomain service is missing. Upstream xen have
> /etc/init.d/xendriverdomain (and equivalent xendriverdomain.service)
> that starts `xl devd` process responsible for setting up backend
> devices.
> 
> Source package contains related comment in debian/not-installed:
> 
>     # It is not clear why we have our own init scripts etc. in Debian.
>     # We should probably transition to using the upstream ones and
>     # fix any bugs we encounter.
>     etc/init.d/xendriverdomain
>     etc/init.d/xencommons
>     etc/init.d/xen-watchdog
>     etc/init.d/xendomains
>     etc/default/xencommons
> 
> I think this should be fixed exactly this way - switch to upstream
> startup scripts, instead of Debian-specific ones.
> Also, upstream provide systemd startup files.
Please see:

https://alioth-lists.debian.net/pipermail/pkg-xen-devel/2019-February/007673.html

https://alioth-lists.debian.net/pipermail/pkg-xen-devel/2019-February/007702.html

A number of the things above are currently being done.

If you want to help testing, please subscribe to the team mailing list
for progress updates.

On top of improving the situation, the basic fundamental reason why we
can't have same init scripts in Debian and upstream, is that Debian has
extra machinery to make it possible to have previous and next packages
coinstalled during release upgrades, and we also have to deal with a few
extra special cases because of that. This concept does not exist in the
upstream world.

Nonetheless, there is some attempt going on to bring them closer
together, but as you can read in the above links, not all of that
happened yet.

Thanks,
Hans

On Mon, Feb 11, 2019 at 04:27:45PM +0100, Hans van Kranenburg
wrote:
> A number of the things above are currently being done.
Thanks for the info.
> If you want to help testing, please subscribe to the team mailing list
> for progress updates.
I can help with testing guest side of the things (including xenstore
tools, driver domain etc), but I don't have any Debian-based dom0 handy.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190211/cfbac403/attachment.sig>

Hi,

On 2/11/19 6:35 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Feb 11, 2019 at 04:27:45PM +0100, Hans van Kranenburg wrote:
>> A number of the things above are currently being done.
> 
> Thanks for the info.
> 
>> If you want to help testing, please subscribe to the team mailing list
>> for progress updates.
> 
> I can help with testing guest side of the things (including xenstore
> tools, driver domain etc), but I don't have any Debian-based dom0
handy.
Aha! Excellent. Making driverdomain scripts work is actually on the TODO
list for Buster [1]. So having somone extra around who can see if it
does the right thing would be really helpful.

I added this bug number to the TODO item line.

Hans

[1] https://salsa.debian.org/xen-team/debian-xen/issues/24

Preliminary test results of something based on debian-xen master branch:
Xen version detection seems fundamentally wrong when talking about domU
side. I've installed relevant packages in buster-based domU, then tried
manually `xl devd`. The result:

    ERROR:  Can't find version 4.8 of xen utils, bailing out!

Yes, the hypervisor (and dom0 tools) are 4.8. But it should not matter
for domU, since it use only stable ABI.
The detection logic should be used only in dom0. On domU side I think it
should take version of xen-utils-common package (the one shipping
detection script) - so xen-utils-common_4.11* will use xen-utils_4.11.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190213/a511611d/attachment-0001.sig>

Hi,

On 2/13/19 1:53 AM, Marek Marczykowski-Górecki wrote:
> Preliminary test results of something based on debian-xen master branch:
> Xen version detection seems fundamentally wrong when talking about domU
> side. I've installed relevant packages in buster-based domU, then tried
> manually `xl devd`. The result:
> 
>     ERROR:  Can't find version 4.8 of xen utils, bailing out!
That message is from /usr/lib/xen-common/bin/xen-dir. xl is not actually
xl, but it's the wrapper script which tries to run xl for the current
running hypervisor version. Bweuh...
> Yes, the hypervisor (and dom0 tools) are 4.8. But it should not matter
> for domU, since it use only stable ABI.
> The detection logic should be used only in dom0. On domU side I think it
> should take version of xen-utils-common package (the one shipping
> detection script) - so xen-utils-common_4.11* will use xen-utils_4.11.
xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
missing.

And indeed, doing things based on running hypervisor does not make sense
here.

What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for fun?

Hans

On Wed, Feb 13, 2019 at 02:07:22AM +0100, Hans van Kranenburg
wrote:
> xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
> missing.
Oh... so maybe search for latest one and error out if none is there?
Or, create yet another binary package which depends on both, intended to
be installed in guest (description of xen-utils-common says it's for
dom0 only), and ship xendriverdomain service there?
> What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for fun?
4.8 is not there, but 4.11 is and it works. After printing some errors
which I believe are unrelated to Debian packaging:

    root at d10test:/home/user# /usr/lib/xen-4.11/bin/xl devd
    libxl: error: libxl.c:363:libxl_get_physinfo: getting physinfo: Permission
denied
    libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve
the maximum number of cpus
    libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve
the maximum number of cpus
    libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to retrieve
the maximum number of cpus
    root at d10test:/home/user# ps aux|grep xl\ devd
    root     25841  0.0  0.1  72144  2228 ?        Ssl  20:09   0:00
/usr/lib/xen-4.11/bin/xl devd


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190213/19301418/attachment.sig>

On 2/13/19 2:17 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 13, 2019 at 02:07:22AM +0100, Hans van Kranenburg wrote:
>> xen-utils-common 4.11 does not depend on xen-utils 4.11, so it can be
>> missing.
> 
> Oh... so maybe search for latest one and error out if none is there?
> Or, create yet another binary package which depends on both, intended to
> be installed in guest (description of xen-utils-common says it's for
> dom0 only), and ship xendriverdomain service there?
I have never used Xen stuff inside a domU, but only the idea that
xen-utils-common with all the dom0 stuff is also supposed to be
installed inside a domU while trying these things has only frightened
me. And it seems that feeling wasn't completely misguided.
>> What if you try running /usr/lib/xen-4.8/bin/xl directly instead, for
fun?
> 
> 4.8 is not there, but 4.11 is and it works.
Eh, yeah, 4.11, obviously.
> After printing some errors
> which I believe are unrelated to Debian packaging:
> 
>     root at d10test:/home/user# /usr/lib/xen-4.11/bin/xl devd
>     libxl: error: libxl.c:363:libxl_get_physinfo: getting physinfo:
Permission denied
>     libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to
retrieve the maximum number of cpus
>     libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to
retrieve the maximum number of cpus
>     libxl: error: libxl_utils.c:820:libxl_cpu_bitmap_alloc: failed to
retrieve the maximum number of cpus
>     root at d10test:/home/user# ps aux|grep xl\ devd
>     root     25841  0.0  0.1  72144  2228 ?        Ssl  20:09   0:00
/usr/lib/xen-4.11/bin/xl devd
It does something! \o/

Creating new binary packages etc... is not an option anymore during the
Buster freeze.

At some point Ian will probably look at this in the next days, to see
what we still can do for Buster. Any testing you can do and anything you
can find out in the meantime is of course useful.

Thanks,

K

On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg
wrote:
> Creating new binary packages etc... is not an option anymore during the
> Buster freeze.
Ok, I can carry myself a startup script calling actual xl directly. But
one thing would be very useful to have in buster - avoid starting
dom0 related services in guest. Otherwise even package installation
fails (if you happen to have the same version of xen packages in dom0
and domU). Would the below patch be acceptable?

-----8<-----

From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki? <marmarek at
invisiblethingslab.com>
Subject: [PATCH] Do not start dom0 services if running inside domU

Signed-off-by: Marek Marczykowski-Górecki <marmarek at
invisiblethingslab.com>
---
 debian/xen-utils-common.xen.init | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
index 4b793d5ac2..d73e827514 100644
--- a/debian/xen-utils-common.xen.init
+++ b/debian/xen-utils-common.xen.init
@@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
 	exit 0
 fi
 
+if grep -q '[^0-]' /sys/hypervisor/uuid; then
+	log_warning_msg "Xen guest detected"
+	exit 0
+fi
+
 XENCONSOLED="$ROOT"/bin/xenconsoled
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
 XENSTORED="$ROOT"/bin/xenstored
-- 
2.17.2


-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190216/f9c55a3d/attachment.sig>

On 2/16/19 4:26 AM, Marek Marczykowski-Górecki wrote:
> On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
>> Creating new binary packages etc... is not an option anymore during the
>> Buster freeze.
> 
> Ok, I can carry myself a startup script calling actual xl directly. But
> one thing would be very useful to have in buster - avoid starting
> dom0 related services in guest. Otherwise even package installation
> fails (if you happen to have the same version of xen packages in dom0
> and domU). Would the below patch be acceptable?
That's a good one yes. There's some optimization of checks already been
done in branch wip.testme [1], e.g. [2], but those checks would indeed
still not result in a noop in a domU. Nice find!

I'll add your change later today, and resend it for review. I think the
warning is not necessary, since a warning points at something that you
should fix. This should just noop.

In domU:
-# cat /sys/hypervisor/uuid
d5ad9b8c-b230-4bba-a74d-04049d090a36

In dom0:
-# cat /sys/hypervisor/uuid
00000000-0000-0000-0000-000000000000

Thanks,
Hans

[1] https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
[2]
https://salsa.debian.org/xen-team/debian-xen/commit/30c9a3c54332f34c515143b261514a04e1e1d13c
> -----8<-----
> 
> From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?>  <marmarek at
invisiblethingslab.com>
> Subject: [PATCH] Do not start dom0 services if running inside domU
> 
> Signed-off-by: Marek Marczykowski-Górecki <marmarek at
invisiblethingslab.com>
> ---
>  debian/xen-utils-common.xen.init | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/debian/xen-utils-common.xen.init
b/debian/xen-utils-common.xen.init
> index 4b793d5ac2..d73e827514 100644
> --- a/debian/xen-utils-common.xen.init
> +++ b/debian/xen-utils-common.xen.init
> @@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
>  	exit 0
>  fi
>  
> +if grep -q '[^0-]' /sys/hypervisor/uuid; then
> +	log_warning_msg "Xen guest detected"
> +	exit 0
> +fi
> +
>  XENCONSOLED="$ROOT"/bin/xenconsoled
>  XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
>  XENSTORED="$ROOT"/bin/xenstored
>

On 2/16/19 1:41 PM, Hans van Kranenburg wrote:
> On 2/16/19 4:26 AM, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
>>> Creating new binary packages etc... is not an option anymore during
the
>>> Buster freeze.
>>
>> Ok, I can carry myself a startup script calling actual xl directly. But
>> one thing would be very useful to have in buster - avoid starting
>> dom0 related services in guest. Otherwise even package installation
>> fails (if you happen to have the same version of xen packages in dom0
>> and domU). Would the below patch be acceptable?
> 
> That's a good one yes. There's some optimization of checks already
been
> done in branch wip.testme [1], e.g. [2], but those checks would indeed
> still not result in a noop in a domU. Nice find!
> 
> I'll add your change later today, and resend it for review. I think the
> warning is not necessary, since a warning points at something that you
> should fix. This should just noop.
Actually, while looking at this again...

In the init script, we already have...

capability_check()
{
        [ -e "/proc/xen/capabilities" ] || return 1
        grep -q "control_d" /proc/xen/capabilities || return 1
        return 0
}

...which gets called like this...

        capability_check
        case "$?" in
                0) ;;
                *) log_end_msg 255; exit ;;
        esac

Looking at /proc/xen/capabilities and seeing if there's control_d inside
seems to be a more common way to check if this is a dom0.

It does log_end_msg 255 and 255 seems to be warning.

The upstream init script has...

# run this script only in dom0:
# no capabilities file in xenlinux domU kernel
# empty capabilities file in pv_ops domU kernel
if test -f /proc/xen/capabilities && \
   ! grep -q "control_d" /proc/xen/capabilities ; then
        exit 0
fi

...which also doesn't look really good, since this exit 0 doesn't happen
when /proc/xen/capabilities does *not* exist, and the first domU I'm
looking inside here doesn't have it.

Can you show what happens exactly when 'package installation fails'?
> In domU:
> -# cat /sys/hypervisor/uuid
> d5ad9b8c-b230-4bba-a74d-04049d090a36
> 
> In dom0:
> -# cat /sys/hypervisor/uuid
> 00000000-0000-0000-0000-000000000000
> 
> Thanks,
> Hans
> 
> [1] https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
> [2]
>
https://salsa.debian.org/xen-team/debian-xen/commit/30c9a3c54332f34c515143b261514a04e1e1d13c
> 
>> -----8<-----
>>
>> From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?>> 
<marmarek at invisiblethingslab.com>
>> Subject: [PATCH] Do not start dom0 services if running inside domU
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek at
invisiblethingslab.com>
>> ---
>>  debian/xen-utils-common.xen.init | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/debian/xen-utils-common.xen.init
b/debian/xen-utils-common.xen.init
>> index 4b793d5ac2..d73e827514 100644
>> --- a/debian/xen-utils-common.xen.init
>> +++ b/debian/xen-utils-common.xen.init
>> @@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
>>  	exit 0
>>  fi
>>  
>> +if grep -q '[^0-]' /sys/hypervisor/uuid; then
>> +	log_warning_msg "Xen guest detected"
>> +	exit 0
>> +fi
>> +
>>  XENCONSOLED="$ROOT"/bin/xenconsoled
>>  XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
>>  XENSTORED="$ROOT"/bin/xenstored
>>
>

On Sat, Feb 16, 2019 at 10:36:00PM +0100, Hans van Kranenburg
wrote:
> Actually, while looking at this again...
> 
> In the init script, we already have...
> 
> capability_check()
> {
>         [ -e "/proc/xen/capabilities" ] || return 1
>         grep -q "control_d" /proc/xen/capabilities || return 1
>         return 0
> }
> 
> ...which gets called like this...
> 
>         capability_check
>         case "$?" in
>                 0) ;;
>                 *) log_end_msg 255; exit ;;
>         esac
> 
> Looking at /proc/xen/capabilities and seeing if there's control_d
inside
> seems to be a more common way to check if this is a dom0.
> 
> It does log_end_msg 255 and 255 seems to be warning.
systemd doesn't agree:

    Setting up xen-utils-common (4.11.1-2~) ...
    (...)
    Job for xen.service failed because the control process exited with error
code.
    See "systemctl status xen.service" and "journalctl -xe"
for details.
    invoke-rc.d: initscript xen, action "restart" failed.
    ● xen.service - LSB: Xen daemons
       Loaded: loaded (/etc/init.d/xen; generated)
       Active: failed (Result: exit-code) since Sat 2019-02-16 18:16:04 EST; 6ms
ago
         Docs: man:systemd-sysv-generator(8)
      Process: 7215 ExecStart=/etc/init.d/xen start (code=exited,
status=255/EXCEPTION)

    Feb 16 18:16:04 d10test systemd[1]: Starting LSB: Xen daemons...
    Feb 16 18:16:04 d10test xen[7215]: Starting Xen daemons: (warning).
    Feb 16 18:16:04 d10test systemd[1]: xen.service: Control process exited,
code=exited, status=255/EXCEPTION
    Feb 16 18:16:04 d10test systemd[1]: xen.service: Failed with result
'exit-code'.
    Feb 16 18:16:04 d10test 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

Full output: https://gist.github.com/marmarek/f6964e16157e69f5761e68ea1a925ae7
> The upstream init script has...
> 
> # run this script only in dom0:
> # no capabilities file in xenlinux domU kernel
> # empty capabilities file in pv_ops domU kernel
> if test -f /proc/xen/capabilities && \
>    ! grep -q "control_d" /proc/xen/capabilities ; then
>         exit 0
> fi
> 
> ...which also doesn't look really good, since this exit 0 doesn't
happen
> when /proc/xen/capabilities does *not* exist, and the first domU I'm
> looking inside here doesn't have it.
Generally I (too?) try to migrate away from /proc/xen, that's why my
patch use /sys/hypervisor/uuid instead.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20190217/5f5d4b5d/attachment-0001.sig>

On 2/17/19 12:27 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Feb 16, 2019 at 10:36:00PM +0100, Hans van Kranenburg wrote:
>> Actually, while looking at this again...
>>
>> In the init script, we already have...
>>
>> capability_check()
>> {
>>         [ -e "/proc/xen/capabilities" ] || return 1
>>         grep -q "control_d" /proc/xen/capabilities || return
1
>>         return 0
>> }
>>
>> ...which gets called like this...
>>
>>         capability_check
>>         case "$?" in
>>                 0) ;;
>>                 *) log_end_msg 255; exit ;;
>>         esac
>>
>> Looking at /proc/xen/capabilities and seeing if there's control_d
inside
>> seems to be a more common way to check if this is a dom0.
>>
>> It does log_end_msg 255 and 255 seems to be warning.
> 
> systemd doesn't agree:
> 
>     Setting up xen-utils-common (4.11.1-2~) ...
>     (...)
>     Job for xen.service failed because the control process exited with
error code.
>     See "systemctl status xen.service" and "journalctl
-xe" for details.
>     invoke-rc.d: initscript xen, action "restart" failed.
>     ● xen.service - LSB: Xen daemons
>        Loaded: loaded (/etc/init.d/xen; generated)
>        Active: failed (Result: exit-code) since Sat 2019-02-16 18:16:04
EST; 6ms ago
>          Docs: man:systemd-sysv-generator(8)
>       Process: 7215 ExecStart=/etc/init.d/xen start (code=exited,
status=255/EXCEPTION)
Hah! Yes, of course, because the exit without code will use the return
code of the previous command instead of 0. I forgot about that.
>     Feb 16 18:16:04 d10test systemd[1]: Starting LSB: Xen daemons...
>     Feb 16 18:16:04 d10test xen[7215]: Starting Xen daemons: (warning).
>     Feb 16 18:16:04 d10test systemd[1]: xen.service: Control process
exited, code=exited, status=255/EXCEPTION
>     Feb 16 18:16:04 d10test systemd[1]: xen.service: Failed with result
'exit-code'.
>     Feb 16 18:16:04 d10test 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
> 
> Full output:
https://gist.github.com/marmarek/f6964e16157e69f5761e68ea1a925ae7
> 
>> The upstream init script has...
>>
>> # run this script only in dom0:
>> # no capabilities file in xenlinux domU kernel
>> # empty capabilities file in pv_ops domU kernel
>> if test -f /proc/xen/capabilities && \
>>    ! grep -q "control_d" /proc/xen/capabilities ; then
>>         exit 0
>> fi
>>
>> ...which also doesn't look really good, since this exit 0
doesn't happen
>> when /proc/xen/capabilities does *not* exist, and the first domU
I'm
>> looking inside here doesn't have it.
> 
> Generally I (too?) try to migrate away from /proc/xen, that's why my
> patch use /sys/hypervisor/uuid instead.
Ok, I don't know too much about all the xen things in /proc and /sys
yet, but it seems the current check for a dom0 does its work, so let's
not change that right now.

But, change it to just exit 0. I added a change on top of the wip.testme
branch.

https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme

Thanks,
Hans