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 <i...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org