similar to: Bug#852069: DomU guests with pygrub as bootloader do not start after, upgrade from Xen 4.1 (wheezy) to Xen 4.4 (jessie)

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u4 Severity: serious Tags: patch dom0 running wheezy domU upgraded from wheezy to jessie. The domU doesn't boot any more, errors: Error code: Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse /grub/grub.cfg Error parameters: Traceback (most recent call last):, File "/usr/lib/xcp/lib/pygrub.xcp", line 853, in

Note: I could simply direct boot the appropriate kernel/initrd to get the alpha1 installation going as always done in the past, but I think this should work. The Debian alpha 1 installer page says it should. Details $ sudo xm create -c wheezytest.cfg Using config file "./wheezytest.cfg". Error: Boot loader didn''t return any data! direct pygrub test run: # pygrub

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 26/04/15 10:45, Bastian Blank wrote: > Hi Daniel > > On Sun, Apr 26, 2015 at 10:35:01AM +0200, Daniel Pocock wrote: >> This should probably be released in an update to wheezy. > > Well, if you can pursuade the release team. We have grub2 for Xen > in Jessie now and it can be used on Wheezy as well. > Can you be

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-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

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 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

Package: xen-utils-4.1 Version: 4.1.3-7 Severity: normal The function is_disk_image in /usr/lib/xen-4.1/bin/pygrub at line 45 distinguishes a partitioned disk from a partition by looking for 0xaa55 at offset 0x1fe in the image, but this is the bootsector signature, not the partition table signature. extlinux and other bootloaders put this signature there on bootable partitions (which don't

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.4-amd64 Version: 4.4.1-9 Severity: critical Justification: breaks the whole system Dear Maintainer, After upgrading the R610 server from Debian 7 to Debian 8, the dom0 becomes unresponsive via ssh after an hour or so, although the domUs still remain accessible. Initially we thought it may be a disk space issue on / or /boot so action was taken to increase those

This patch removes the extra command `install pygrub` because this is already done by the setup.py script. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- This patch need to be applied after the patch named "Fix pygrub install." tools/pygrub/Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/tools/pygrub/Makefile

If we pass 0 as pygrub --entry argument (i.e. we want to boot first item), default value is used instead. This is dueto wrong check for range of allowed values of index - 0 is index of first item. Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com> Patch: --- diff --git a/tools/pygrub/src/pygrub b/tools/pygrub/src/pygrub index 1845485..eedfdb2 100644 --- a/tools/pygrub/src/pygrub +++

Hello! My Dom0 config: Xubuntu 8.10 + "Xen-3.3.1 and kernel-2.6.18-xen.hg" I have Nexenta CP2 RC1 (Opensolaris b104) on ZFS file system. I installed this OS in HVM. For PV i used pygrub. My config file: ''ncp2.pygrub'' bootloader = "/usr/bin/pygrub" boot = "c" memory = 512 name = "NexentaPV" uuid =

Hi Bastian, I'd like to propose backporting the following changesets from upstream xen-unstable into the xen-3 package. With these it is possible to boot a default installation of Squeeze (using d-i) in a domU using pygrub. 20480:c2c2e67b8198 pygrub: if default entry is "saved" then use first entry. 20481:8f4e0adc2b3b pygrub: expands tabs before displaying menus. 20485:086a6a0c3f37

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.

I have NexentaCP2 (Opensolaris b104+). Parameters for the kernel: ''zfs-bootfs=syspool/rootfs-nmu-000,bootpath=/xpvd/xdf@0:a'' Pygrub returns: ''zfs-bootfs=syspool/30,bootpath=/xpvd/xdf@0:a'' Result: Boot with pygrub don''t work. What is "30" in syspool/30 ? _______________________________________________ Xen-users mailing list

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1346945306 -7200 # Node ID 8a2eef481d3ab3ca5692dd0083c95cf314fe1da3 # Parent 19d367bf07b7687b831c212a57a70e73ea14d3b7 pygrub: always append --args If a bootloader entry in menu.lst has no additional kernel command line options listed and the domU.cfg has ''bootargs="--args=something"'' the additional

From: pbonzini@redhat.com # HG changeset patch # User Paolo Bonzini <pbonzini@redhat.com> # Date 1319096986 -7200 # Node ID bd1f7361d3d7f4c767af21317fb4ec7ea1372f42 # Parent 1b110e895e285f43f14532e14c77597e54a0bcd2 pygrub will still try the next partition if run_grub exits with a "real" error, thus hiding the root cause from the trace. Defining a separate exception for "no

I just tripped over this issue with pygrub. The code is written such that saying bootloader="pygrub" should cause the correct path to be used, the attached patch simply fixes this path to be correct. I don't have an HVM capable test machine handy (so I can't actually confirm this works) but I think changing the default "kernel" for an HVM guest to point to the correct

Keir, This would also be appropriate for 3.1.0, since the /usr/lib fix makes pygrub work on ia64 Presently pygrub only looks in /efi/redhat/elilo.conf. It should check for other distributions, plus a couple fallback locations. Signed-off-by: Aron Griffis <aron@hp.com> diff -r 6d64f9eefad5 -r 67df28389f46 tools/pygrub/src/pygrub --- a/tools/pygrub/src/pygrub Wed May 02 14:50:56 2007