similar to: Bug#697409: xen-utils-4.1: pygrub does not correctly distinguish between "disk with partitions" and "partition"

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub does not recognize the include statement in extlinux.conf. The default Debian installation of extlinux creates a stub extlinux.conf which includes linux.cfg, where all the linux image entries are. This means that even if bugs 697407 and 697409 are fixed, pygrub still can't find the right kernel on a default Debian installation

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The grub.cfg created by a default Debian installation uses many configuration statements that pygrub does not recognize, and pygrub is unable to find any kernel to load. ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500,

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal pygrub looks for extlinux config files "/boot/isolinux/isolinux.cfg" and "/boot/extlinux.conf", but the default Debian installation uses the config file "/boot/extlinux/extlinux.conf". (See /usr/lib/xen-4.1/bin/pygrub lines 405-407.) ...Marvin -- System Information: Debian Release: 7.0 APT prefers testing

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.

Processing commands for control at bugs.debian.org: > merge 697407 697409 697412 697417 Bug #697407 [xen-utils-4.1] xen-utils-4.1: pygrub doesn't find extlinux.conf in default Debian location Bug #697409 [xen-utils-4.1] xen-utils-4.1: pygrub does not correctly distinguish between "disk with partitions" and "partition" Bug #697412 [xen-utils-4.1] xen-utils-4.1: pygrub

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-utils-common Version: 4.0.0-1 Severity: wishlist Tags: patch I am not a gawk/mawk expert, but I looked carefully at the few uses of gawk that I saw in /etc/xen/scripts/vtpm-common.sh and network-bridge, and I did not see anything that was gawk-specific. It would be nice if they could be changed to awk and the dependency on gawk removed. base-files is Essential: yes and it

Fix for pygrub path on Solaris. Signed-off-by: John Levon <john.levon@sun.com> diff --git a/tools/python/xen/xend/XendDomainInfo.py b/tools/python/xen/xend/XendDomainInfo.py --- a/tools/python/xen/xend/XendDomainInfo.py +++ b/tools/python/xen/xend/XendDomainInfo.py @@ -37,7 +37,7 @@ from xen.util.blkif import blkdev_uname_ from xen.util.blkif import blkdev_uname_to_file from xen.util

Hello, What is the recommended way to offer high availability to Guests? For example, let host1, host2 and host3 be libvirt and KVM/Qemu enabled. If I start a guest in host1, how can I guarantee that it will stay online if host1 goes down? GlusterFS, for example, would take care of storage; but what about CPU and RAM? How can this be accomplished? Thank you for any feedback or comment in

Hey guys, I have a private network and I trust it! /me hides behind trees... So, in order to exercise my trust, I wanna migrate guests over TCP; with and without shared storage. This is: - I want to migrate from host1 to host2; which have shared storage; over TCP without certs - I want to migrate from host1 to host99, which don't have shared storage, over TCP without certs I am asking

Hello, xen-utils-4.1's pygrub is unable to boot VMs from a partitionless blockdev that has grub installed in first sector. I'm not sure it deserves a bug report, although it is kind of a regression from 4.0. Long story short: zeroing first sector of domU's boot blockdev fixes it. Maybe some of this report would be useful in the wiki, if someone else has the same (odd) setup. --- The

Tags: patch I think this can be fixed with the following patch; it at least worked for me: http://lists.xen.org/archives/html/xen-devel/2011-01/txtLboGgCEUdF.txt -- Adi --- xen-4.1.0/tools/pygrub/src/pygrub.orig 2010-12-31 15:24:11.000000000 +0000 +++ xen-4.1.0/tools/pygrub/src/pygrub 2011-01-30 18:58:17.000000000 +0000 @@ -96,6 +96,7 @@ fd = os.open(file, os.O_RDONLY) buf =

Package: xen-utils-4.1 Version: 4.1.4-2 Severity: wishlist Tags: patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Maintainer, Please consider adding xfs support to pygrub in xen-utils-4.1. The version from xen-utils-4.2 from upstream supports xfs and the required changes are minimal. I am attaching a patch which was constructed by squashing the following commits together:

Package: xen-utils-4.4 Version: 4.4.1-9+deb8u8 Severity: normal Under Xen 4.1 in Debian 7 (wheezy), the following works when included in a DomU configuration in "/etc/xen/cfg/" -- bootloader = '/usr/lib/xen-default/bin/pygrub' After upgrading to Xen 4.4 as part of an upgrade to Debian 8 (jessie), the DomU silently fails to start. Examination of the log files shows that the

Package: xen-hypervisor-4.1-amd64 Version: 4.1.1-3 Severity: important Whenever I try to start a domU, xm create failed for 'Boot loader didn't return any data!'. % sudo xm create -c squeeze.cfg Using config file "/etc/xen/squeeze.cfg". Error: Boot loader didn't return any data! It seems related to the following error in dmesg [1440.163935] pygrub[3654] trap invalid

Processing commands for control at bugs.debian.org: > tags 697407 + upstream patch Bug #697407 [src:xen] xen-utils-4.1: pygrub doesn't find extlinux.conf in default Debian location Bug #697409 [src:xen] xen-utils-4.1: pygrub does not correctly distinguish between "disk with partitions" and "partition" Bug #697412 [src:xen] xen-utils-4.1: pygrub does not recognize the

Processing commands for control at bugs.debian.org: > tags 697412 + moreinfo Bug #697412 [src:xen] xen-utils-4.1: pygrub does not recognize the include statement in extlinux.conf Bug #697407 [src:xen] xen-utils-4.1: pygrub doesn't find extlinux.conf in default Debian location Bug #697409 [src:xen] xen-utils-4.1: pygrub does not correctly distinguish between "disk with partitions"

Subject: xen-utils-4.1: /usr/lib/xen-default missing Package: xen-utils-4.1 Version: 4.1.3-1 Severity: important Dear Maintainer, when using paravirtualization with xen and libvirt the path for pygrub is: /usr/lib/xen-default/bin/pygrub But this path is not provided with xen-utils-4.1 and will brake upgrades to wheezy. With xen-utils-4.0 and debian squeeze this path is provided with

Processing commands for control at bugs.debian.org: > tags 697407 + fixed-upstream Bug #697407 [src:xen] xen-utils-4.1: pygrub doesn't find extlinux.conf in default Debian location Bug #697409 [src:xen] xen-utils-4.1: pygrub does not correctly distinguish between "disk with partitions" and "partition" Bug #697412 [src:xen] xen-utils-4.1: pygrub does not recognize the

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