Bug#773561: Installing "xen-linux-system-amd64" on jessie fails
Control: reassign -1 xen-utils-common 4.4.1-6
Control: retitle -1 /etc/init.d/xen fails when run in a guest, causing postinst to fail.
Seems like this issue is in the Xen packages not in the xen-linux-system
metapackage, so reassigning.
On Mon, 2014-12-22 at 23:01 +0100, Sydney Meyer wrote:
> > On 22 Dec 2014, at 17:25, Ian Campbell <ijc@debian.org> wrote:
> >
> > On Sat, 2014-12-20 at 20:46 +0100, Sydney Meyer wrote:
> >> Hello Ian,
> >>
> >> "systemctl status xen.service" gives:
> >
> > Thanks. Sadly these logs weren't as informative a I had hoped they would
> > be :-/ (In case it's not clear: this is not your fault)
> >
> >> root@jessie:/home/sydney# systemctl status xen.service
> >> ● xen.service - LSB: Xen daemons
> >> Loaded: loaded (/etc/init.d/xen)
> >> Active: failed (Result: exit-code) since Sat 2014-12-20 20:42:30 CET; 11s ago
> >> Process: 4796 ExecStart=/etc/init.d/xen start (code=exited, status=255)
> >>
> >> Dec 20 20:42:30 jessie xen[4796]: Starting Xen daemons: xenfs (warning).
> >> Dec 20 20:42:30 jessie systemd[1]: xen.service: control process exited, code=exited status=255
> >> Dec 20 20:42:30 jessie systemd[1]: Failed to start LSB: Xen daemons.
> >> Dec 20 20:42:30 jessie systemd[1]: Unit xen.service entered failed state.
> >
> > This basically says "it failed", which isn't terribly helpful!
> >
> > I think it is complaining because it couldn't mount xenfs, but it
> > doesn't say why.
> >
> > If you run "/etc/init.d/xen start" from the root command line does it
> > say something more informative/useful?
>
> No, it fails and refers to systemctl/journalctl:
OK.
>
> root@jessie:/home/sydney# /etc/init.d/xen start
> [....] Starting xen (via systemctl): xen.serviceJob for xen.service failed. See 'systemctl status xen.service' and 'journalctl -xn' for details.
> failed!
> >
> > Could you also try running /usr/lib/xen-common/bin/xen-dir
> > and /usr/lib/xen-common/bin/xen-toolstack by hand (also as root).
>
> root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-dir
> /usr/lib/xen-4.4
>
> root@jessie:/home/sydney# /usr/lib/xen-common/bin/xen-toolstack
> /usr/lib/xen-4.4/bin/xl
Thanks, so it thinks it is running under Xen (which given what you say
below makes sense).
What (if anything) does "mount -t xenfs xenfs /proc/xen" report?
Does /proc/xen exist?
> Yes, this particular output is from a Xen DomU with vmx enabled. The
> Dom0 is running Xen 4.4.1 compiled from source on a Debian Linux
> 3.16.2 Kernel.
Thanks, this would have been good to know up front. I suppose you are
wanting to do some sort of nested virtualisation? You are likely the
first to try this with the Debian packaging, and nested virt generally
is considered tech preview upstream, so I'd expect there to be some
wrinkles in doing this.
By "with vmx enabled" I guess you mean with nestedhvm=1 in the guest
cfg? Are you running this in a PV or HVM guest (I think HVM)? Can you
post the dmesg from the kernel please, along with the guest cfg file.
I don't have much experience with nested virt but AIUI there are some
caveats with running Xen on Xen, in particular it seems that the L1
hypervisor (see [0] for the terminology) can either be a xenbus client
of the L0 hypervisor or provide xenbus services to its own L2 guests,
but not both at the same time. I think that people generally disable PV
drivers on the L1 domain (e.g. with xen_platform_pci=1 in its config) so
that it is free to provide xenbus services to its own guests. It might
be that this isn't relevant to the issue you report here, but it might
have some bearing (and it worth trying to disable it).
[0] http://wiki.xenproject.org/wiki/Xen_nested
> I have also tested this on a VMware Fusion 7 Guest (HW Version 11).
And it fails in the same way? If so then that's interesting because I
wouldn't expect the kernel to discover that it was running on Xen under
those circumstances. I wonder if the initscript is confused because it
is running on any hypervisor at all not specifically Xen
Does /sys/hypervisor/type exist in all cases and what does it contain?
> > Assuming you are running this on the dom0/host, have you booted into the
> > hypervisor at this point or are you running bare-metal/native? (I
> > suspect the latter).
>
> The VM was running "native", i.e. the VM itself didn't boot into
> hypervisor mode.
My hypothesis is that because it is running as a guest on Xen something
is getting confused and thinking it is actually booting as a host on
Xen, but the vmware thing doesn't quite fit.
Ian.
Reply to: