[Pkg-xen-devel] Bug#922033: Bug#922033: xen: driver domain does not work

[Hans van Kranenburg]

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