similar to: Bug#407299: xen-utils-common: man 1 xm: warning: can't find numbered character 160

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: wishlist Xen can run 32bit domU clients on 64bit (amd64) dom0. Unfortunately only amd64 linux-image-xen packages are available on arch amd64. Please provide 686 packages as well (if possible). This would enable the installation of 32bit clients without the need to manually compile a kernel. Feel free to reassign this bug to the correct

Package: xen-utils-common Version: 3.0.3-0-2 Severity: wishlist Tags: patch Currently when hostnames are wider than 10 chars, the xentop output is messed up. Please add the following patch to support up to 20 chars, or better yet, allow the columns to auto size :) #! /bin/sh /usr/share/dpatch/dpatch-run ## xentop-name-width.dpatch by <apeeters@lashout.net> ## ## All lines beginning with

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal Hi, I am getting the following message in dmesg about twice a minute: peth0: received packet with own address as source address A patch is available in the upstream BTS: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=339 -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing')

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal gzip -3 compresses the Xen save files in a reasonably small amount of time and makes them take less than half the space that they might otherwise require. On systems with an encrypted root filesystem and on systems that have really fast CPUs if xm supported such compression then that would increase the speed of xm save and xm restore

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal After running "halt" in a couple of domains I ran "xm list" repeatedly to see when the halt command was complete. Below is some of the output. The "Device 0 not connected" should not occur. yoyoxen:~# xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0

Package: xen-utils-3.4 Version: 3.4.2-2 Severity: important *** Please type your report below this line The Package is fail cause the directoryname /usr/lib/xen-3.4 is wrong when i call the xm tool a wrapperscript searching for version 3.4.0 and dont find 3.4.0 it must be /usr/lib/xen-3.4.0 and all is fine *** -- System Information: Debian Release: squeeze/sid APT prefers testing APT

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: important the xen-utils packages lack xfrd, which is required for live domain migrations using xm migrate. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale:

Package: xen-utils-3.0-unstable-1 Version: 3.0-unstable+hg11561-1 Severity: grave Justification: renders package unusable with the recent unstable kernel, the evtchn device should be created with major/minor 10, 63. Instead, it's being created with 10, 201. If fixed manually, xenstored will re-create it with the wrong minor number. This causes Xen to be entirely unusable, as xenstored is

Package: xen-utils-common Version: 3.0.3-0-2 Followup-For: Bug #401249 I don't mean to "me too", but I thought I might inform that this is not a one-off occurence. Please advise how I can assist with further debugging. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to

Package: xen-utils-common Version: 3.0.3-0-2 Severity: wishlist I had an error in the disk configuration of a VM (typo in the LVM volume group name) and got this error: # xm create test.cfg Using config file "test.cfg". Error: Device 2049 (vbd) could not be connected. Hotplug scripts not working. # I would be nice to have an error message that clarifies things. -- System

Package: xen-utils-common Version: 4.1.2-1 Severity: grave Justification: renders package unusable (Grave because dash is the default /bin/sh) With dash 0.5.5.1-7.4 as /bin/sh, /usr/sbin/xm enters an infinite loop of reexcuting itself. When run with bash, it works correctly. I traced that to /usr/lib/xen-common/bin/xen-toolstack; here's the diff between "/bin/sh -x /usr/sbin/xm"

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal Tags: patch When shutting down xen domains with '/etc/init.d/xendomains stop' most of the time not all domains are stopped when the script finishes. As it turns out the xendomains-script queries running domains by executing 'xm list', this command replies its usage info sometimes instead of giving proper output. I

Processing commands for control at bugs.debian.org: > close 407299 4.1.3~rc1+hg-20120614.a9c0a89c08f2-2 Bug #407299 [xen-utils-common] xen-utils-common: man 1 xm: warning: can't find numbered character 160 Marked as fixed in versions xen/4.1.3~rc1+hg-20120614.a9c0a89c08f2-2. Bug #407299 [xen-utils-common] xen-utils-common: man 1 xm: warning: can't find numbered character 160 Marked Bug

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: normal pygrub can't work with this package, because the fsys filesystem modules included in the source package are missing. As a workaround, I downloaded the xen-3.0 source package, went into tools/pygrub/src/, installed e2fslibs-dev and libreiserfs0.3-dev, ran "make", and copied stuff from

Hi all, Would it be possible to include support for a non-pae capable machines on the demo cd. The 3.0 version worked but the 3.0.3 version fails with Cannot execute PAE-enabled kernel on a PAE-less CPU! (Please CC me since I am not subscribed to the list) Thanks, -- Adriaan Peeters _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Package: xen-utils-3.0.3-1 Version: 3.0.3-0-2 Severity: normal Since this package installs python modules in /usr/lib/xen-3.0.3-1/lib/python/, and uses them directly from there, not following the python policy, once xend has started up, lots of .pyc files are created there, which will not be removed if the package is purged. These pyc files may also cause problem for future python upgrades, I

Package: xen-utils-common Version: 4.1.4-2 Severity: normal Hi, During some research I encountered incorrect information in the man page of xm, about the dump-core functionality: The man page says: "Defaults to dumping the core without pausing the domain if no I<OPTIONS> are specified." When taking a look at the source code of this process, the default behaviour is to actually

Package: xen-utils-4.0 Version: 4.0.1-1 Severity: normal Due to license issues this version of Xen does not include the blktap2 backend (tapdisk2) and associated utilities (vhd-util, etc.). The decision was made to disable the blktap v1 kernel module (the default is now blktap2). As a result we can't use any tap devices which means worse performance than previousl. Since blktap1 was available

Package: xen-utils-common Version: 3.0.3-0-2 Severity: important I have installed all the packages I can think of to get Xen going and it still fails with the following : /var/log/xen/xend-debug.log: Exception starting xend: (111, 'Connection refused') er.py", line 463, in process_request_thread self.finish_request(request, client_address) File "SocketServer.py",

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