similar to: Bug#603391: pygrub: unintelligible error messages

Confirmed this issue. To reproduce: Install a fresh Wheezy AMD64 guest under Xen 4.1 (hypervirtualized, boot from the debian-7.1.0-amd64-CD-1.iso). Use "entire disk" automatic layout for partitioning, this creates /dev/xvda1 for / and /dev/xvda5 for swap. It will create /boot/grub/grub.cfg with many references to (/dev/xvda,msdos1) which works fine when the machine is booted

The image argument to pygrub does not need to be an integer. The "invalid literal for int()" error probably means that your menu.lst contains something like "root=(/dev/sda)". The root should be specified in grub notation like "root=(hd0)". You might want to have a look at /boot/grub/devices.map. To map /dev/sda to hd0, you could add an entry like: (hd0) /dev/sda

Package: xen-utils-4.0 Version: 4.0.1-1 Severity: normal File: pygrub The pygrub awesome error messages are captured below. Please tell me what pygrub was doing and why it failed. I also don't understand why <image> is supposed to be an integer. # '/usr/lib/xen-4.0/bin/pygrub' '--kernel=/vmlinuz' '--ramdisk=/initrd.img' '/dev/sda3' linux (kernel

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

On Sat, 2013-09-28 at 20:59 -0700, Tril wrote: > Backtrace from manual run of the buggy GrubConf.py: > # python /usr/lib/xen-4.1/lib/python/grub/GrubConf.py grub2 grub.cfg > WARNING:root:Unknown directive load_video > WARNING:root:Unknown directive terminal_output > WARNING:root:Unknown image directive load_video > Traceback (most recent call last): > File

Package: xen-utils-4.0 Version: 4.0.1-2 Severity: normal File: pygrub pygrub error when trying to run a image created by xen-create-image with partitions option. ---------------------------------------------------------------------------------------------------------------------------------------- [2011-10-02 21:36:08 1512] DEBUG (XendDomainInfo:101) XendDomainInfo.create(['vm',

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

Processing commands for control at bugs.debian.org: > reassign 745419 src:xen 4.1.4-3+deb7u1 Bug #745419 [xen-utils-4.1] xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record Bug reassigned from package 'xen-utils-4.1' to 'src:xen'. No longer marked as found in versions xen/4.1.4-3+deb7u1. Ignoring request to alter fixed versions of

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

On Tue, 2013-10-01 at 09:10 -0700, Tril wrote: > Sorry didn't work. Hrm, odd, it worked when based on the upstream xen-unstable tree. Perhaps something else is needed against 4.1 for the backport to work. > Aso it will only handle this special case, not the > general case of /dev/something. Right, in this context there isn't really a general case since for things to work with

I double-checked, I edited the file correctly. I don't know python much, but it seems the lower stack traces are deeper than the upper ones, which means somehow your calling "self.disk =" inside a set_disk method seems to have re-entered itself as if set_disk is a handler for self.disk =...

On Mon, 2013-10-07 at 21:13 -0700, Tril wrote: > I double-checked, I edited the file correctly. > > I don't know python much, but it seems the lower stack traces are > deeper than the upper ones, which means somehow your calling > "self.disk =" inside a set_disk method seems to have re-entered itself > as if set_disk is a handler for self.disk =... It should be

got it, added underscore, my mistake. Patch works.

Sorry didn't work. Aso it will only handle this special case, not the general case of /dev/something. # python GrubConf.py grub2 /home/tehadmin/snail-grub.cfg WARNING:root:Unknown directive load_video WARNING:root:Unknown directive terminal_output WARNING:root:Unknown image directive load_video Traceback (most recent call last): File "GrubConf.py", line 467, in <module>

You get these if you install Debian Wheezy as HVM and then try to convert to PV. This is Debian bug #603391. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Tested-by: Tril <tril@metapipe.net> --- tools/pygrub/examples/debian-wheezy-hvm.grub2 | 104 +++++++++++++++++++++++++ tools/pygrub/src/GrubConf.py | 6 +- 2 files changed, 109 insertions(+), 1

Hardware: 2x Intel Xeon Quad-Core 2.33GHz 24GB FBDIMM RAM 2x 2TB HDD in RAID-1 Intel Server Board S5400SF Setup: Arch Linux x86_64 Xen 4.1.2 Grub2 Multiboot Synopsis: I set up a new VM for Debian Squeeze following instructions here: http://www.howtoforge.com/installing-debian-squeeze-6.0-domu-on-centos-5.5-x86_64-dom0. Partitioning & installation completed correctly. When I tried to run the

I''ve followed the howto at virtuatopia.com<http://www.virtuatopia.com/index.php/Building_a_Xen_Virtual_Guest_Filesystem_on_a_Disk_Image_%28Cloning_Host_System%29>to clone existing machines, then create them as PV guests. It has worked a couple of times for me, but I''ve run into a problem I don''t understand. When I run "xm create name", I get an error that

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important Tags: security patch When you use xl toolstack, you can't reboot domUs. When you switch back to xm toolstack, than reboot works again. I think the problem with the debian packaged version is the same as in this thread: http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html I also think it's a security issue,

Hi, I''m trying to boot a PV VM I just installed (following http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer) without success. My XEN installation is xen-unstable 54c8c9eaee92+ on a Debian unstable machine (x86_64), kernel 3.3.4+. The VM I installed is, again, a Debian unstable x86_64. The installation went smoothly; I used an 8GB file as a disk back-end. I went