similar to: Bug#514918: xen-utils-unstable: xend starts with errors

Hi. I use xen-4.0.0 My domU successfully started, but when i tried to connect to DomU console i get error: root@debian-office:/opt/src/NexetaStor# xm console NexentaStor-EVAL-2.2.0 Unexpected error: <type ''exceptions.TypeError''> Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/sbin/xm", line 7, in <module>

Hi. I use xen-4.0.0 My domU successfully started, but when i tried to connect to DomU console i get error: root@debian-office:/opt/src/NexetaStor# xm console NexentaStor-EVAL-2.2.0 Unexpected error: <type ''exceptions.TypeError''> Please report to xen-devel@lists.xensource.com Traceback (most recent call last): File "/usr/sbin/xm", line 7, in <module>

Processing commands for control at bugs.debian.org: > # reassigning all open bugs reported against versioned xen packages that are no longer in the archive to src:xen > reassign 514918 src:xen 3.3-unstable+hg17961-1 Bug #514918 [xen-utils-unstable] xen-utils-unstable: xend starts with errors Warning: Unknown package 'xen-utils-unstable' Bug reassigned from package

Package: xen-utils-3.4 Version: 3.4.3~rc6-1 Severity: important blktapctrl isn't started by default. If blktapctrl isn't started then none of the tap: disks (eg tap:aio) work. This functionality has been removed in tools-misc-xend-startup.diff @@ -120,24 +86,14 @@ if not sys.argv[1:]: print 'usage: %s {start|stop|reload|restart}' % sys.argv[0] elif

debian/patches/tools-python-prefix.diff removes auxbin.pathTo and replaces it with auxbin.path_bin and auxbin.path_boot. However there are still references to auxbin.pathTo in xend. The attached switches those usages to the correct new function. Without these I get: Error: 'module' object has no attribute 'pathTo' when trying to start a guest with

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: important /usr/lib/xen-3.2-1/bin/blktapctrl searches for tapdisk executable in /usr/bin while is in /usr/lib/xen-3.2-1/bin this makes tap:aio unusable I've linked to /usr/bin and everything went fine perhaps the idea is to patch sources to pick executable from the right directory Regards -- System Information: Debian Release: 5.0

Resent of mail sent on 28.04. xend: fix bug in option parsing If you enable legacy tcp xmlrpc in xend''s config but omit to enable ssl the following backtrace is generated when starting xend: [2010-04-28 16:09:04 15754] ERROR (SrvDaemon:349) Exception starting xend (''NoneType'' object has no attribute ''rfind'') Traceback (most recent call last): File

Package: xen-utils-4.0 Version: 4.0.0-2 Severity: important xend does not start because of a bug in option parsing. Error described here: http://www.gossamer-threads.com/lists/xen/devel/172035 Patch: --- a/tools/python/xen/xend/XendOptions.py Mon Apr 26 12:13:23 2010 +0100 +++ b/tools/python/xen/xend/XendOptions.py Wed Apr 28 16:54:04 2010 +0200 @@ -207,18 +207,18 @@ def

Hi everyone,  I am using bio3d package for some sequence analysis because of its nice integrated MUSCLE execution. However, I have been encountering some errors while I was running seqaln function, which calls for installed MUSCLE program. In my case, I stored the MUSCLE program on the desktop with pathway of "./Desktop/muscle/src/muscle". I had no problem running MUSCLE directly from

Package: xen-unstable Version: 3.3-unstable+hg17961-1 Severity: normal Tags: sid User: debian-gcc at lists.debian.org Usertags: ftbfs-gcc-4.5 The package fails to build in a test rebuild on at least amd64 with gcc-4.5/g++-4.5, but succeeds to build with gcc-4.4/g++-4.4. For the compiler version used, see: http://lists.debian.org/debian-devel/2010/01/msg00230.html The full build log can be found

After upgrading to xen unstable packages I'm seeing the following problem: skx@itchy:~$ sudo /etc/init.d/xend restart Restarting XEN control daemon: xendTraceback (most recent call last): File "/usr/lib/xen-3.0-unstable-1/bin/xend", line 40, in ? from xen.xend.server import SrvDaemon File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py", line 17,

Hello, I just upgraded my 64-bits dom0 from Etch to Lenny, I am still running the 2.6.18 Xen kernel by apt-pinning it (see later). But now xend does not start anymore: ------------ xen:~# /etc/init.d/xend start Starting XEN control daemon: xendTraceback (most recent call last): File "/usr/lib/xen-3.0.3-1/bin/xend", line 40, in <module> from xen.xend.server import SrvDaemon

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-4 Severity: important # /etc/init.d/xend start Restarting XEN control daemon: xendTraceback (most recent call last): File "/usr/lib/xen-3.0.3-1/bin/xend", line 40, in <module> from xen.xend.server import SrvDaemon File "/usr/lib/xen-3.0.3-1/lib/python/xen/xend/server/SrvDaemon.py", line 17, in <module> import

Hi; With xen-3.1.0 on Pardus 2007, "/usr/sbin/xend start" returns "Cannot find Xen Python modules." cause Xen Python modules installed into "/usr/lib/python2.4/site-packages/" Following patch adds site-packages into search path Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr> diff -r aee991c7723a tools/misc/xen-python-path ---

Package: xen-utils-3.2-1 Version: 3.2.1-2 Followup-For: Bug #477525 I have the same problem after updating from etch to lenny. (Thus updating Xen from 3.0 to 3.2) Does anyone know how to fix this? -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/2 CPU cores) Locale:

Package: xen-utils-3.2-1 Version: 3.2.0-5 Severity: important $vifnum is undefined when this is called. Starting XEN control daemon: xend/etc/xen/scripts/network-route: line 27: /proc/sys/net/ipv4/conf/eth/proxy_arp: No such file or directory /etc/xen/scripts/network-route: line 27: /proc/sys/net/ipv4/conf/eth/proxy_arp: No such file or directory /etc/xen/scripts/network-route: line 27:

In the hope that it will be acceptable, I''m suggesting this change to make another tiny step towards the ability to run the tools e.g. out of the build tree (so that multiple different Xen versions can co-exist without the requirement to re-install the respective version with each boot). Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-06-18/tools/misc/xen-python-path

changeset: 11208:a40c8bae08a81181c38a43a744b5d87db22066ea parent: 11206:12da2c3245bbbf63781e2ad5e6f2eb489d93957c user: Jimi Xenidis <jimix@watson.ibm.com> date: Tue Aug 01 16:40:33 2006 -0400 files: tools/python/xen/util/auxbin.py description: [TOOLS] ppc64 is not a LIB_64_ARCH Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com> diff -r

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: normal Tags: patch Hi, There is a bug xen-3-3.2.1/tools/libfsimage/reiserfs/fsys_reiserfs.c, it is using "unsigned long" which is 64 bits on amd64 arch and 32 bits on i386 arch. This makes pygrub can't work on reiserfs on amd64 arch. You can easily reproduce it. A patch is included for fixing this problem. diff

Package: xen-utils-3.2-1 Version: 3.2.1-2 Severity: normal *** Please type your report below this line *** When live migrating a PV guest from one Lenny dom0 to another, the migration fails with the following error: libvir: Xen Daemon error : POST operation failed: xend_post: error from xen daemon: (xend.err '/usr/lib/xen-3.2-1/bin/xc_save 28 39 0 0 1 failed') The kernel messages