Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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?
signature.asc
Description: PGP signature
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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
> ----
>
> 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?=
>>
>> Subject: [PATCH] Do not start dom0 services if running inside domU
>>
>> Signed-off-by: Marek Marczykowski-Górecki
>> ---
>> 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
>>
>
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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 ---- 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?= > > Subject: [PATCH] Do not start dom0 services if running inside domU > > Signed-off-by: Marek Marczykowski-Górecki > --- > 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 >
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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?= Subject: [PATCH] Do not start dom0 services if running inside domU Signed-off-by: Marek Marczykowski-Górecki --- 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? signature.asc Description: PGP signature
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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@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@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
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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@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@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? signature.asc Description: PGP signature
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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? signature.asc Description: PGP signature
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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? signature.asc Description: PGP signature
Bug#922033: [Pkg-xen-devel] Bug#922033: xen: driver domain does not work
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
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? signature.asc Description: PGP signature
