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

[Marek Marczykowski-Górecki]

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>