similar to: Bug#691734: xen-utils-common should install successfully even if xen cannot be started

Package: xen-utils-common Version: 4.1.3-2 Severity: important IMPORTANT NOTE: This bug has been generated using reportbug run from a debian stable system. The affected debian testing systems are isolated in a lab and do not have internet access. The issue is wholly reproducible on several different debian testing installations. xen-utils-common fails to install if xen cannot be started.

Processing commands for control at bugs.debian.org: > forcemerge 691734 709103 Bug #691734 [xen-utils-common] xen-utils-common should install successfully even if xen cannot be started Bug #691734 [xen-utils-common] xen-utils-common should install successfully even if xen cannot be started Marked as found in versions xen/4.1.4-3+deb7u1. Bug #709103 [xen-utils-common] xen-linux-system-amd64:

Processing commands for control at bugs.debian.org: > reassign 709103 xen-utils-common 4.1.4-3+deb7u1 Bug #709103 [xen-linux-system-amd64] xen-linux-system-amd64: Xen installation FAILS from Debian repository Bug reassigned from package 'xen-linux-system-amd64' to 'xen-utils-common'. No longer marked as found in versions linux-latest/46. Ignoring request to alter fixed versions

Processing commands for control at bugs.debian.org: > merge 691734 709103 Bug #691734 [xen-utils-common] xen-utils-common should install successfully even if xen cannot be started Unable to merge bugs because: severity of #709103 is 'normal' not 'important' Failed to merge 691734: Did not alter merged bugs Debbugs::Control::set_merged('transcript',

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: normal Dear Maintainer, i changed toolkit to xl, after that i observe that my domU started as HVM domains. I found same problem here: http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html When i manualy setup loop devices and specify it as disks in my VM conf file, domU started as PV. -- System Information: Debian Release: 7.1

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: normal Tags: patch Dear Maintainer, * What led up to the situation? I have a xen dom0 with more than one interface that I want to make bridges on * What exactly did you do (or not do) that was effective (or ineffective)? I have my own bridge making script that calls network-bridge for each interface. This used to work in

Package: xen-utils-common Version: 4.1.4-3 Severity: important Dear Maintainer, Executive summary: dist-upgrade - squeeze to wheezy. Rebooted machine; no default route on network interface eth0. Commented 'transfer_addrs' function in network-bridge produced a machine which worked after reboot. We're using network-bridge as our xen networking configuration. After rebooting the

On Mon, 2014-04-21 at 15:43 +0200, Sjors Gielen wrote: > Package: xen-utils-4.1 > Version: 4.1.4-3+deb7u1 > Severity: important > > When an LVM LV that serves as the root disk for a Xen DomU contains a boot > loader (or possibly other data) in its volume boot record, pygrub fails to boot > it, printing "Error: boot loader didn't return any data" before exiting.

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-4.1 Version: 4.1.4-3+deb7u1 Severity: important When an LVM LV that serves as the root disk for a Xen DomU contains a boot loader (or possibly other data) in its volume boot record, pygrub fails to boot it, printing "Error: boot loader didn't return any data" before exiting. I think this is because of the function "is_disk_image" on line 45 of

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-3+deb7u1 Severity: important Dear Maintainer, We are having a problem on several Supermicro servers (I'll include more details on the configuration later) : when booting Linux 3.2 linux-image-3.2.0-4-amd64 (Wheezy) as a DOM0 on Xen 4.1 (xen-hypervisor-4.1-amd64 from Wheezy), the system hangs after : [ 3.716174] scsi1 : ata_piix [

Processing commands for control at bugs.debian.org: > close 691734 Bug #691734 [xen-utils-common] xen-utils-common should install successfully even if xen cannot be started Bug #709103 [xen-utils-common] xen-linux-system-amd64: Xen installation FAILS from Debian repository Marked Bug as done Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. --

Control: tag -1 +patch (experimenting with http://www.donarmstrong.com/posts/control_at_submit/ ...) Hi Thomas, I think it is as simple as the following, which works for me with xl and xm. Does it work as you expect/want with xe? Ian. >From 88f10bc8dbf96dd2c32f12259249f8be70fd01a4 Mon Sep 17 00:00:00 2001 From: Ian Campbell <ijc at hellion.org.uk> Date: Thu, 19 Jul 2012 16:19:09

Package: xen-utils-common Followup-For: Bug #706876 The problem here is that network-* scripts are fragile and prone to breakage. Both Debian and upstream recommend configuring networking explicitly using the normal distro mechanisms i.e. /etc/network/intefaces. See http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29 Ian. -- System Information: Debian Release: jessie/sid

Package: xen-hypervisor-4.1-amd64 Version: 4.1.4-3+deb7u1 Severity: important Dear Maintainer, Just upgraded a Supermicro server (X9SCM-F motherboard) from Squeeze to Wheezy. And now the IPMI serial console no longer work as it used to. It hangs like this: [...] (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) ENABLING IO-APIC IRQs (XEN) -> Using old ACK method (XEN) Platform timer

Package: xen-utils-common Version: 3.0+hg11624-1 Severity: normal Hi, the executable /usr/sbin/xm refers to the man pages xm(1) and xmdomain.cfg(5). As far as I can see, Debian doesn't ship the respective upstream man pages available at http://xensource.com/ . Since Debian packages should ship man pages for executables, it would be a good idea to include those. Thanks, bye, Roland --

Package: xen-utils-3.2-1 Version: 3.2.0-4 Severity: important Tags: patch pygrub uses tools/libfsimage to read a guest filesystem. Unfortunately the grub derived code does not support 256 byte inodes. Grub itself has been patched (see #463236 and #463123) and this patch has now been applied to the upstream Xen tree. See <http://xenbits.xensource.com/staging/xen-unstable.hg?rev/c777e572a467>

After a few days, one of my DomU becomes unresponsive. Here''s the output of my DomU''s. root@xenII:/var/log/xen# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 7126 2 r----- 723932.0 redhat-sdsweb 11 4091 2 -b---- 92633.1 w2k8-AD

Package: xen-utils-common Version: 4.1.3-8 Severity: important When antispoof is set to 'on', the vif-common script does not create an ALLOW firewall rule for the emulated vif devices. This means that HVM nodes, unless a Xen PV driver is installed and running, cannot access the external network. The vif-common script creates an ACCEPT entry for the normal vif device (e.g. vif4.0) but not

Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, I've just set up a fresh Jessie system using the installer dated 2014-03-05, then installed and enabled Xen 4.3. I've done this quite a few times before using Wheezy and 4.1. I set up xenbr0, then created a test domU using xen-create-image, which completed without issue. However I was unable to start the new