similar to: Bug report on xcp-xapi: dumpcore crashes with exit status 139

Hi, We found a crash in qemu-dm contained in the xen-utils-4.1 package. You are being contacted because your are listed as one of the maintainer of xen-utils-4.1. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will

Hi, We found a crash in vhd-update contained in the blktap-utils package. You are being contacted because your are listed as one of the maintainer of blktap-utils. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will

Hi, We found a crash in xentrace_setmask contained in the xen-utils-4.1 package. You are being contacted because your are listed as one of the maintainer of xen-utils-4.1. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report

Hi, We found a crash in xentrace_setsize contained in the xen-utils-4.1 package. You are being contacted because your are listed as one of the maintainer of xen-utils-4.1. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report

Hi, We found a crash in td-rated contained in the blktap-utils package. You are being contacted because your are listed as one of the maintainer of blktap-utils. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will be

Hi, We found a crash in xenctx contained in the xen-utils-4.1 package. You are being contacted because your are listed as one of the maintainer of xen-utils-4.1. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will be

Hi, We found a crash in xenbaked contained in the xen-utils-4.1 package. You are being contacted because your are listed as one of the maintainer of xen-utils-4.1. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report that will

Hi, We found a crash in tp contained in the xcp-storage-managers package. You are being contacted because your are listed as one of the maintainer of xcp-storage-managers. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. The bug report

Package: xen-utils-4.1 Version: 4.1.4-4 Severity: normal User: mayhem at forallsecure.com Usertags: mayhem xenbaked crashes with exit status 139. We confirmed the crash by re-running it in a fresh debian unstable installation. The attachment [1] contains a testcase (under ./crash) crashing the program. It ensures that you can easily reproduce the bug. Additionally, under ./crash_info/, we

Package: xen-utils-4.1 Version: 4.1.4-4 Severity: normal User: mayhem at forallsecure.com Usertags: mayhem xenctx crashes with exit status 139. We confirmed the crash by re-running it in a fresh debian unstable installation. The attachment [1] contains a testcase (under ./crash) crashing the program. It ensures that you can easily reproduce the bug. Additionally, under ./crash_info/, we include

Package: xen-utils-4.1 Version: 4.1.4-4 Severity: normal User: mayhem at forallsecure.com Usertags: mayhem xentrace_setmask crashes with exit status 139. We confirmed the crash by re-running it in a fresh debian unstable installation. The attachment [1] contains a testcase (under ./crash) crashing the program. It ensures that you can easily reproduce the bug. Additionally, under ./crash_info/,

Package: xen-utils-4.1 Version: 4.1.4-4 Severity: normal User: mayhem at forallsecure.com Usertags: mayhem xentrace_setsize crashes with exit status 139. We confirmed the crash by re-running it in a fresh debian unstable installation. The attachment [1] contains a testcase (under ./crash) crashing the program. It ensures that you can easily reproduce the bug. Additionally, under ./crash_info/,

Package: xcp-storage-managers Version: 0.1.1-3.1 Severity: normal User: mayhem at forallsecure.com Usertags: mayhem tp crashes with exit status 139. We confirmed the crash by re-running it in a fresh debian unstable installation. The attachment [1] contains a testcase (under ./crash) crashing the program. It ensures that you can easily reproduce the bug. Additionally, under ./crash_info/, we

Package: xcp-xapi Version: 1.3.2-15 Severity: normal I am trying to pass an SRIOV virtual function in a virtual machine but the attempt fails with the following errors shown in the xcp-xapi.log [20130829T19:29:17.909Z|debug|sriov1|314 UNIX /var/lib/xcp/xapi|VM.start R:9e8e10bd31bb|pciops] PCI devices from other-config:pci to attach: 0/0000:04:00.1 [20130829T19:29:18.012Z|debug|sriov1|314 UNIX

Package: xcp-xapi Version: 1.3.2-11 Severity: normal We need to have a separate user/group privilege for xapi and its dependent processes. At the moment, everything runs as root -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux

Package: xcp-xapi Severity: normal Tags: upstream Are there good reasons why xapi by default prefers to bidn to 80 and 443? This will lead to xapi installation/start failure on every server machine that might (and will probably) have apache installed. I know we can remove apache or change its port or change xapi's port (But I've had a hard time to easily find out where to specify the

Package: xcp-xapi Version: 1.3.2-8 Severity: important Tags: patch Found race condition (specific only to slave hosts): xcp-xapi can start earlier than xcp-networkd due lack of dependency in init.d script. Syptoms: After reboot slave's xcp does not work: xe (anything): The host failed to acquire an IP address on its management interface and therefore cannot contact the master. log:

Package: xcp-xapi Version: 1.3.2-8 Severity: important During startup /etc/init.d/xendomains script is called. That script is installed with xen-utils-common witch xcp-xapi is depends on. That script calls /usr/sbin/xen as xen list &> /dev/null This 'xen' seems to call xapi: xen list ^Z [1]+ Stopped xen list root at lab-xh3:~# ps f PID TTY STAT TIME

Hi, Nice to receive your suggestions. Follwing the suggestions, the xapi service does work on a non XCP host and most of the xe interface of get information (such as "xe vm-list ")can work well. However, when I used the "xe sr-create" interface to create a SR, I got a error "The SR could not be connected because the driver was not recognised ". I noted that

Hi, Nice to receive your suggestions. Follwing the suggestions, the xapi service does work on a non XCP host and most of the xe interface of get information (such as "xe vm-list ")can work well. However, when I used the "xe sr-create" interface to create a SR, I got a error "The SR could not be connected because the driver was not recognised ". I noted that