similar to: [PATCH] xen init script: don't fail when being run in domU

Hans van Kranenburg writes ("[PATCH 09/13] xen init script: move init_dom0 into xenstored start"): > This little xen-init-dom0 program is present in both our 4.8 and 4.11 > packages, so there's no need to keep the if else code. Also, it only > makes sense to run it after starting xenstored, and not all other times > start is called. I think xen-init-dom0 is not in jessie

Package: xen-utils-common Version: 4.0.0-1 Severity: important After running modules_setup you need to have the following line: [ -x /sbin/restorecon ] && /sbin/restorecon -R /dev/xen The reason is that the module load causes the kernel to create device nodes in the devtmpfs. This bypasses the udev code for labelling the device node and results in xenstored being unable to access

Package: xen-utils-common Version: 4.4.1-2 Severity: normal For correct operation under SE Linux the start script needs to assign correct security labels to firectories it creates. Note that restorcon doesn't cause any problems if run twice. If it's executable then you can safely run it. Below is a patch that demonstrates how to solve this problem. --- xen.old 2014-10-12

The contents are the wip.testme branch currently on salsa. I combined the wip.initscript and wip.oxenstored into this and added more things today. I think this is pretty gtg and it's smoke tested (in several cases by scping files around instead of doing package build), so it needs a final extra review and test round before putting it in master branch (which I don't want to force push). I

Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, * What led up to the situation? I upgraded my server from squeeze to wheezy and then to jessie. Server is Intel S3200SHV m/b with Intel(R) Core(TM)2 Quad CPU. I'm pretty sure that before that it was running whatever came before squeeze, I forget the name. I was trying to get xen_pciback to work, so I

Package: xen-utils-common Version: 4.1.3~rc1+hg-20120614.a9c0a89c08f2-2 Severity: important Please modify the init scripts in a manner similar to the following to give the correct SE Linux labels. Failing to correctly label them may result in Xen not working correctly when SE Linux is enabled. --- /etc/init.d/xen.orig 2012-06-24 10:29:04.000000000 +1000 +++ /etc/init.d/xen 2012-06-24

Hans van Kranenburg writes ("Re: [PATCH 08/13] xen init script: rewrite xenstored start logic"): > So the question we should answer first is: What do we allow the user to > set as value? /bin/bash? And how should the init script deal with that? If they specify an absolute path, it should be used. Eg, /home/alice/Xen/xen/tools/xenstore/xenstore If the user specifies /bin/bash

Hans van Kranenburg writes ("[PATCH 08/13] xen init script: rewrite xenstored start logic"): > -XENSTORED="$ROOT"/bin/xenstored > +# In /etc/default/xen, the user can set XENSTORED, which has to be either > +# 'xenstored' or 'oxenstored'. In here, we add the version specific path. > +if [ -n "$XENSTORED" ]; then > +

Package: xen-utils-common Version: 4.4.0-1 Severity: important Tags: patch Under some circumstances the xl toolstack needs to create a loopback mount of a guest disk in dom0 (e.g. in order to run pygrub). Depending on the nature of the guest disk (e.g. qcow2 or raw file image based) this can require a qemu instance in dom0. The upstream xencommons starts such a qemu on boot. The following patch

Hans van Kranenburg writes ("[PATCH 06/13] sysconfig.xencommons.in: Strip and debianize"): > Strip all options that are for stuff we don't ship, which is 1) > xenstored as stubdom and 2) xenbackendd, which seems to be dead code > anyway. [1] > > It seems useful to give the user the option to revert to xenstored > instead of the default oxenstored if they really

Package: xen-utils-common Version: 4.4.1-9+deb8u4 Severity: normal Dear Maintainer, I have a server with a large number of domUs set to auto-start. For the first time I have booted it with all of them needing to start from cold, but the xendomains service only got part way through. syslog showed nothing notable about the domains starting? Apr 16 14:57:45 snaps xendomains[4631]: Starting

Hello, I build and installed Xen (4.1.3) from source, and I think I have got it working. Well, almost. I am using unmodified kernel of Fedora16 as my dom0 kernel. So this is what happened. I am able to boot into Xen, but the "xl info" failed with the standard error message mentioned in the tutorial. "libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running? failed to

Hello, I build and installed Xen (4.1.3) from source, and I think I have got it working. Well, almost. I am using unmodified kernel of Fedora16 as my dom0 kernel. So this is what happened. I am able to boot into Xen, but the "xl info" failed with the standard error message mentioned in the tutorial. "libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running? failed to

On 27.11.2014 12:18, Ian Campbell wrote: > On Thu, 2014-11-27 at 11:02 +0100, Stefan Bader wrote: >> On 21.11.2014 13:50, Ian Campbell wrote: >>> Package: xen-utils-common >>> Version: 4.4.0-1 >>> Severity: important >>> Tags: patch >>> >>> Under some circumstances the xl toolstack needs to create a loopback >>> mount of a

Hi Ian, can you please review and sponsor the upload of a first Xen 4.10 package to experimental? The work which has been done to arrive at this point from the previous 4.8 packages is visible at: https://salsa.debian.org/xen-team/debian-xen/commits/master The only commit which is not in master yet is the actual package release:

I'm just dumping all I got in here, after initial feedback we can see how to organize todo's around it. tl;dr: * Does not upgrade cleanly from 4.8 packages, so we have to prevent this from entering testing until we fix that. * Live migration is broken, explodes with memory allocation errors. ---- >8 ---- 1. Build packages * I have built salsa/master using pbuilder targeting sid.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r cfb49fe940fd -r 81f75ed45ec2 tools/hotplug/Linux/init.d/xencommons --- a/tools/hotplug/Linux/init.d/xencommons Tue Aug 16 16:56:16 2011 -0700 +++ b/tools/hotplug/Linux/init.d/xencommons Tue Aug 16 17:05:18 2011 -0700 @@ -29,12 +29,18 @@ XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid shopt -s extglob -if [

Hi I gave the new Xen-4.6rc2 a spin on a CentOS 7 virtualisation guest (nested-xen). I haven't yet started testing guests, but rather looked at the install itself. One issue, I found, was with xenstored.service and the corresponding unit-file: [root at xencen7ws ~]# systemctl status xenstored xenstored.service - The Xen xenstore Loaded: loaded

On Sat, Apr 2, 2016 at 4:05 PM, Rowland penny <rpenny at samba.org> wrote: > I compile Samba myself and I use init files, I would rather have them than > the bloat systemd comes with. They are not complex if you understand bash > and are a lot easier to understand than all that systemd comes with. At first I felt the same way but the service files are starting to seem simpler. Yes,

I am going to submit a proposal for a Xen BOF at DC18. Here is my first cut at a draft abstract: Title: Xen in Debian BoF Format: workshop with 25 min slot The Xen packages in Debian are in need of some work, including some tidying up, upstreaming of some Makefile patches, and updating to new versions. There is a large outstanding bug list. Also with the demise of Alioth and the