similar to: Bug#538073: /etc/init.d/xend: typo in xend_stop

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.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.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

Package: xen-utils-3.4 Version: 3.4.0-2 Severity: normal Hi, the variable $DAEMON in /etc/init.d/xend is not set and thus the init.d/-script is not usable. I think it's supposed to be $XEND. Any ideas on that one? regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux

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

Processing commands for control at bugs.debian.org: > reassign 555902 xen-utils-common 3.3.1-2 Bug #555902 {Done: Bastian Blank <waldi at debian.org>} [xen-utils-3.4] xen-utils-3.4: /etc/init.d/xend - $DAEMON variable at xend_stop() Bug reassigned from package 'xen-utils-3.4' to 'xen-utils-common'. Bug No longer marked as found in versions xen-3/3.4.0-2. Bug No longer

Package: xen-utils-common Version: 3.0.3-0-2 Severity: minor Here's an excerpt from /etc/init.d/xend: *) N=/etc/init.d/xen-utils echo "Usage: $N {start|stop|restart|force-reload}" >&2 exit 1 ;; This will obviously display a wrong path when the script is called with unknown arguments. Regards, -- J?r?my -------------- next part

Package: xen-utils-common Version: 3.4.2-1 Severity: important File: /etc/init.d/xend Tags: patch Hello, /etc/init.d/xend assume xenfs is present and doesn't start xend if not. This dirty patch makes xend start and XEN being operationnal with old flavour xen kernels. I use 2.6.31.5 with forwarded ported Xen 2.6.18 dom0 kernel patch but it should work with debian's 2.6.26 ---

More details : I noticed that every start of xend is adding the POSTROUTING masquerade iptables rule, and nothing is done at stop time. This should bi fixed, at least. -- Olivier BERGER <olivier.berger at int-edu.eu> (ATTENTION : new address) Ing?nieur Recherche - Dept INF GET/INT at Evry (http://www.int-edu.eu/) OpenPGP-Id: 1024D/6B829EEC

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: normal Hi, # ps awux | grep /usr/lib/xen <nothing> # /etc/init.d/xend start Starting XEN control daemon: xend. # /etc/init.d/xend stop Stopping XEN control daemon: xend. # ps awux | grep /usr/lib/xen root 29826 0.2 0.1 2160 848 ? S 09:37 0:00 /usr/lib/xen-3.2-1/bin/xenstored --pid-file /var/run/xenstore.pid root

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal There should be a clean and clearly defined way to restart all the Xen daemons in the case of error. If the file /var/lib/xenstored/tdb is corrupt then you must stop xenstored, rm the file, and then restart it. Currently there is no defined way of doing this so the solution is to kill -9 the process, rm the file, and then reboot. --

I am seeing a problem with the Xen emulated serial console. When running a Linux 2.6.20 HVM guest that has CONFIG_HOTPLUG_CPU=n, the guest blocks on output to the console until it receives input keypresses from `xm console`. This prevents the guest from booting up without banging on some keys, and makes interactive use of the console difficult. By bisecting Linux kernel commits, I found that

https://bugzilla.mindrot.org/show_bug.cgi?id=2063 Bug ID: 2063 Summary: RFE: export principal which was used for .k5login Classification: Unclassified Product: Portable OpenSSH Version: 6.1p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component:

Package: xen-3 Version: 3.2.1-2 Severity: wishlist Xen 3.2.1 is now over a year old, and was obsoleted by Xen 3.3 eight months ago. The xen-unstable snapshot in sid is also about a year old. It would be nice to have updated Xen packages in Debian.

Same problem here with : xen-utils-common 3.2.0-2 -- Marius

Package: xen-utils-common Version: 3.2.0-1~bpo4+1 Severity: minor I use the version from backports, but it's still present in sid. In /etc/xen/xend-config-sxp : #(xen-tcp-xmlrpc-server-address 'localhost') #(xen-tcp-xmlrpc-server-port 8006) should be #(xend-tcp-xmlrpc-server-address 'localhost') #(xend-tcp-xmlrpc-server-port 8006) Small typo in a commented line, but

Hi all, Long time no speak. Well, since I''ve chosen to stick with the XML Xen configs; config.sxp, how do I; 1) Have a domain truly shutdown upon xend shutting down (not save state but halt -p). 2) Have certain VMs start before others. Startup is (on-xend_start start) But thats all I could really muster at this point. Thanks in advance, - Brian

The PCI_EXP_TYPE_PCI_BRIDGE should be PCI_EXP_FLAGS_TYPE here. Also a tiny fix to the python comment. Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

On 12/22/2011 01:37 AM, Mike McClurg wrote: > Hi Thomas, Jon, > > I was hoping that you could both comment on this github pull request: > > https://github.com/jonludlam/xen-api/pull/12 > > Mike > In Debian, /etc/default/xen is there to select xm vs xl. So we could do: if ! [ -f /etc/default/xen ] ; then TOOLSTACK=xm else . /etc/default/xen if ! [

Package: xen-utils-common Version: 4.0.0-1 Severity: normal A strange issue, when deploying Xen using Puppet, /etc/udev/rules.d/xend.rules and /etc/udev/rules.d/xen-backend.rules files are empty. Specifically, the symlinks point to ../xend.rules and ../xen-backend.rules respectively in /etc/udev, but neither of those files exist. Manually copying those files from another host that was not