Gerry Reno
2009-Dec-31 04:27 UTC
[Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
I converted a kvm guest to a PV guest converting grub2 to grub and running update-grub in the guest but it does not want to start. I remembered to adjust the indexing from hd0,5 in grub2 to hd0,4 in grub legacy but for some reason pygrub cannot boot it. I don''t even get a grub prompt. Can anyone see anything wrong with this config? The host is running latest pv_ops dom0 kernel and so is the guest. Both are ubuntu 9.10. The original /boot was on /dev/vda5 which I changed everywhere to /dev/xvda5 before shutting down the guest. The root is on /dev/mapper/... (lvm). name = "CLOUD-CC-1" maxmem = 1024 memory = 1024 vcpus = 1 bootloader = "/usr/bin/pygrub" on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] vif = [ "mac=00:16:1a:2a:ef:56,bridge=virbr0" ] # vi *.py # # xm create CLOUD-CC-1.py Using config file "./CLOUD-CC-1.py". Error: Boot loader didn''t return any data! -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 04:40 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Thu, Dec 31, 2009 at 11:27 AM, Gerry Reno <greno@verizon.net> wrote:> I converted a kvm guest to a PV guest converting grub2 to grub and running > update-grub in the guest but it does not want to start. I remembered to > adjust the indexing from hd0,5 in grub2 to hd0,4 in grub legacy but for some > reason pygrub cannot boot it. I don''t even get a grub prompt. Can anyone > see anything wrong with this config?> bootloader = "/usr/bin/pygrub" > disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ]First of all, where on earth did you get your conversion instructions from? If you install it as HVM, and use the same disk image for PV, then you should''ve map it as disk. i.e disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda,w" ] instead of disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] second, AFAIK pygrub doesn''t really care about boot sectors or MBR. That means you could have whatever bootloader originally on the HVM domU (grub2, extlinux, grub, etc.) and you don''t have even have to install grub or run update-grub to make pygrub works. What you DO need: - an active/bootable partition table. This is necessary only if you map the disk image as disk on domU (i.e. xvda instead of xvda1). pygrub will then read config from this partition. - a /boot/grub/menu.lst on the active partition. This file must contain the correct grub entries. -- Fajar -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 05:17 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Thu, Dec 31, 2009 at 11:27 AM, Gerry Reno <greno@verizon.net> wrote: > >> I converted a kvm guest to a PV guest converting grub2 to grub and running >> update-grub in the guest but it does not want to start. I remembered to >> adjust the indexing from hd0,5 in grub2 to hd0,4 in grub legacy but for some >> reason pygrub cannot boot it. I don''t even get a grub prompt. Can anyone >> see anything wrong with this config? >> > > >> bootloader = "/usr/bin/pygrub" >> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] >> > > First of all, where on earth did you get your conversion instructions from? >This looks like it: http://lists.centos.org/pipermail/centos-virt/2009-November/001306.html> If you install it as HVM, and use the same disk image for PV, then you > should''ve map it as disk. i.e > > disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda,w" ] > > instead of > > disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] >Yep, tried that. Same error.> second, AFAIK pygrub doesn''t really care about boot sectors or MBR. > That means you could have whatever bootloader originally on the HVM > domU (grub2, extlinux, grub, etc.) and you don''t have even have to > install grub or run update-grub to make pygrub works. What you DO > need: > - an active/bootable partition table.Got that.> This is necessary only if you > map the disk image as disk on domU (i.e. xvda instead of xvda1). > pygrub will then read config from this partition. > - a /boot/grub/menu.lst on the active partition. This file must > contain the correct grub entries. > >The original kvm guest had: /dev/vda5 /boot /dev/mapper/vg.... / So I changed all references of /dev/vda5 to /dev/xvda5 in guest. I figured the lvm would take care of itself. I also tried booting this with the host kernel/initrd but it gets just so far and then the kernel panics. Haven''t figured out yet how to get to the /boot partition so I can make changes. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 05:32 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Thu, Dec 31, 2009 at 12:17 PM, Gerry Reno <greno@verizon.net> wrote:>>> bootloader = "/usr/bin/pygrub" >>> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] >>> >> >> First of all, where on earth did you get your conversion instructions >> from? >> > > This looks like it: > http://lists.centos.org/pipermail/centos-virt/2009-November/001306.htmlThe example there says to map the disk as xvda :)> The original kvm guest had: > /dev/vda5 /boot > /dev/mapper/vg.... / > > So I changed all references of /dev/vda5 to /dev/xvda5 in guest. I figured > the lvm would take care of itself.yes, you need to change it on the guest. Let''s try some things: (1) Keep the disk mapped as xvda on domU config file. (2) assign /var/lib/xen/images/CLOUD-CC-1.img to a loopback device, and use kpartx on it (something like "LOOP=`losetup -f`;losetup $LOOP /var/lib/xen/images/CLOUD-CC-1.img;kpartx -av $LOOP") (3) run "fdisk -l $LOOP" (4) mount the partition on domU (something like "mount /dev/mapper/loop0p5 /mnt/tmp") (5) ls -la /mnt/tmp /mnt/tmp/boot/grub/menu.lst (or whatever your mount point is) (6) paste the content of menu.lst (relevant parts only, no need to paste commented entries) (7) run "/usr/bin/pygrub -i /var/lib/xen/images/CLOUD-CC-1.img" -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 06:01 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Thu, Dec 31, 2009 at 12:17 PM, Gerry Reno <greno@verizon.net> wrote: > >>>> bootloader = "/usr/bin/pygrub" >>>> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvda5,w" ] >>>> >>>> >>> First of all, where on earth did you get your conversion instructions >>> from? >>> >>> >> This looks like it: >> http://lists.centos.org/pipermail/centos-virt/2009-November/001306.html >> > > The example there says to map the disk as xvda :) > > >> The original kvm guest had: >> /dev/vda5 /boot >> /dev/mapper/vg.... / >> >> So I changed all references of /dev/vda5 to /dev/xvda5 in guest. I figured >> the lvm would take care of itself. >> > > yes, you need to change it on the guest. > > Let''s try some things: > (1) Keep the disk mapped as xvda on domU config file. > (2) assign /var/lib/xen/images/CLOUD-CC-1.img to a loopback device, > and use kpartx on it (something like "LOOP=`losetup -f`;losetup $LOOP > /var/lib/xen/images/CLOUD-CC-1.img;kpartx -av $LOOP") > (3) run "fdisk -l $LOOP" > (4) mount the partition on domU (something like "mount > /dev/mapper/loop0p5 /mnt/tmp") > (5) ls -la /mnt/tmp /mnt/tmp/boot/grub/menu.lst (or whatever your > mount point is) > (6) paste the content of menu.lst (relevant parts only, no need to > paste commented entries) > (7) run "/usr/bin/pygrub -i /var/lib/xen/images/CLOUD-CC-1.img" > >Here are the results: root@grp-01-23-02:/var/lib/xen/images# LOOP=`losetup -f` root@grp-01-23-02:/var/lib/xen/images# echo $LOOP /dev/loop0 root@grp-01-23-02:/var/lib/xen/images# losetup $LOOP /var/lib/xen/images/CLOUD-CC-1.img root@grp-01-23-02:/var/lib/xen/images# root@grp-01-23-02:/var/lib/xen/images# kpartx -av $LOOP add map loop0p1 (252:5): 0 251160147 linear /dev/loop0 63 add map loop0p2 (252:6): 0 498015 linear /dev/loop0 251160210 add map loop0p5 (252:7): 0 497952 252:6 63 root@grp-01-23-02:/var/lib/xen/images# root@grp-01-23-02:/var/lib/xen/images# fdisk -l $LOOP Disk /dev/loop0: 128.8 GB, 128849018880 bytes 255 heads, 63 sectors/track, 15665 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000438c1 Device Boot Start End Blocks Id System /dev/loop0p1 * 1 15634 125580073+ 8e Linux LVM /dev/loop0p2 15635 15665 249007+ 5 Extended /dev/loop0p5 15635 15665 248976 83 Linux root@grp-01-23-02:/var/lib/xen/images# root@grp-01-23-02:/var/lib/xen/images# ls /mnt boot iso root@grp-01-23-02:/var/lib/xen/images# mkdir /mnt/tmp root@grp-01-23-02:/var/lib/xen/images# mount /dev/mapper/loop0p5 /mnt/tmp root@grp-01-23-02:/var/lib/xen/images# ls -la /mnt/tmp /mnt/tmp/boot/grub/menu.lst ls: cannot access /mnt/tmp/boot/grub/menu.lst: No such file or directory /mnt/tmp: total 87516 drwxr-xr-x 5 root root 1024 2009-12-30 14:57 . drwxr-xr-x 5 root root 4096 2009-12-31 00:50 .. -rw-r--r-- 1 root root 623709 2009-10-16 12:44 abi-2.6.31-14-server -rw-r--r-- 1 root root 105771 2009-10-16 12:44 config-2.6.31-14-server -rw-r--r-- 1 root root 105086 2009-12-27 20:05 config-2.6.31.6 drwxr-xr-x 2 root root 1024 2009-12-30 18:13 grub drwxr-xr-x 2 root root 5120 2009-12-30 14:03 grub_backup -rw-r--r-- 1 root root 7424257 2009-12-12 20:06 initrd.img-2.6.31-14-server -rw-r--r-- 1 root root 68728004 2009-12-27 21:10 initrd.img-2.6.31.6-fromHost drwx------ 2 root root 12288 2009-12-06 23:36 lost+found -rw-r--r-- 1 root root 128796 2009-10-23 12:24 memtest86+.bin -rw-r--r-- 1 root root 2129198 2009-10-16 12:44 System.map-2.6.31-14-server -rw-r--r-- 1 root root 2087202 2009-12-27 20:58 System.map-2.6.31.6 -rw-r--r-- 1 root root 1335 2009-10-16 12:50 vmcoreinfo-2.6.31-14-server -rw-r--r-- 1 root root 3934784 2009-10-16 12:44 vmlinuz-2.6.31-14-server -rw-r--r-- 1 root root 3953856 2009-12-27 20:58 vmlinuz-2.6.31.6 root@grp-01-23-02:/var/lib/xen/images# ls -la /mnt/tmp/grub/menu.lst -rw-r--r-- 1 root root 4631 2009-12-30 15:56 /mnt/tmp/grub/menu.lst root@grp-01-23-02:/var/lib/xen/images# root@grp-01-23-02:/var/lib/xen/images# cat /mnt/tmp/grub/menu.lst | sed -e ''/^$/d'' -e ''/ *#.*$/d'' default 0 timeout 3 hiddenmenu title Ubuntu 9.10, kernel 2.6.31.6 root (hd0,4) kernel /vmlinuz-2.6.31.6 root=/dev/mapper/grp--01--40--51-root ro quiet splash title Ubuntu 9.10, kernel 2.6.31.6 (recovery mode) root (hd0,4) kernel /vmlinuz-2.6.31.6 root=/dev/mapper/grp--01--40--51-root ro single title Ubuntu 9.10, kernel 2.6.31-14-server root (hd0,4) kernel /vmlinuz-2.6.31-14-server root=/dev/mapper/grp--01--40--51-root ro quiet splash initrd /initrd.img-2.6.31-14-server title Ubuntu 9.10, kernel 2.6.31-14-server (recovery mode) root (hd0,4) kernel /vmlinuz-2.6.31-14-server root=/dev/mapper/grp--01--40--51-root ro single initrd /initrd.img-2.6.31-14-server title Ubuntu 9.10, memtest86+ root (hd0,4) kernel /memtest86+.bin root@grp-01-23-02:/var/lib/xen/images# root@grp-01-23-02:/var/lib/xen/images# /usr/bin/pygrub -i /var/lib/xen/images/CLOUD-CC-1.img Traceback (most recent call last): File "/usr/bin/pygrub", line 676, in <module> fs = fsimage.open(file, get_fs_offset(file)) IOError: [Errno 95] Operation not supported root@grp-01-23-02:/var/lib/xen/images# -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 06:27 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Thu, Dec 31, 2009 at 1:01 PM, Gerry Reno <greno@verizon.net> wrote:> root@grp-01-23-02:/var/lib/xen/images# fdisk -l $LOOP > > Disk /dev/loop0: 128.8 GB, 128849018880 bytes > 255 heads, 63 sectors/track, 15665 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Disk identifier: 0x000438c1 > > Device Boot Start End Blocks Id System > /dev/loop0p1 * 1 15634 125580073+ 8e Linux LVM > /dev/loop0p2 15635 15665 249007+ 5 Extended > /dev/loop0p5 15635 15665 248976 83 LinuxThis is just wrong. In sooo many levels. The active partition is LVM? /boot is on logical partition? Come on ... grub/grub2 PROBABLY won''t care about it if you install them on MBR, but it won''t work if you install them on the boot sector (/dev/vda5), or use other bootloaders (like syslinux/extlinux), or use pygrub. /boot needs to be active, primary partition. It''s probably not your fault though (I think I got similar results with opensuse), so if that''s the default layout you got when installing the OS you should file a bug to your distro (Ubuntu?). At this point it''s probably easiest to just create another virtual disk with one primary partition, and copy the contents of the original /boot there. It''s A LOT easier compared to messing up with existing partition table. Your domU config should then look something like this disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] Don''t forget to umount all the disk images after these tests (umount, kpartx -dv, losetup -d). Forgetting that can lead to data corruption. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 06:46 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Thu, Dec 31, 2009 at 1:01 PM, Gerry Reno <greno@verizon.net> wrote: > > >> root@grp-01-23-02:/var/lib/xen/images# fdisk -l $LOOP >> >> Disk /dev/loop0: 128.8 GB, 128849018880 bytes >> 255 heads, 63 sectors/track, 15665 cylinders >> Units = cylinders of 16065 * 512 = 8225280 bytes >> Disk identifier: 0x000438c1 >> >> Device Boot Start End Blocks Id System >> /dev/loop0p1 * 1 15634 125580073+ 8e Linux LVM >> /dev/loop0p2 15635 15665 249007+ 5 Extended >> /dev/loop0p5 15635 15665 248976 83 Linux >> > > This is just wrong. In sooo many levels. The active partition is LVM? > /boot is on logical partition? Come on ... > grub/grub2 PROBABLY won''t care about it if you install them on MBR, > but it won''t work if you install them on the boot sector (/dev/vda5), > or use other bootloaders (like syslinux/extlinux), or use pygrub. > /boot needs to be active, primary partition. > > It''s probably not your fault though (I think I got similar results > with opensuse), so if that''s the default layout you got when > installing the OS you should file a bug to your distro (Ubuntu?). >This was all setup by the ubuntu installer.> At this point it''s probably easiest to just create another virtual > disk with one primary partition, and copy the contents of the original > /boot there. It''s A LOT easier compared to messing up with existing > partition table. Your domU config should then look something like this > > disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", > "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] >If I do this then maybe I can straighten the original partition table out; remove the last two partitions and create a primary active partition for /boot.> Don''t forget to umount all the disk images after these tests (umount, > kpartx -dv, losetup -d). Forgetting that can lead to data corruption. >Thanks for the reminder and thanks for taking a look at this. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 06:58 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@verizon.net> wrote:>> At this point it''s probably easiest to just create another virtual >> disk with one primary partition, and copy the contents of the original >> /boot there. It''s A LOT easier compared to messing up with existing >> partition table. Your domU config should then look something like this >> >> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", >> "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] >> > > If I do this then maybe I can straighten the original partition table out; > remove the last two partitions and create a primary active partition for > /boot.If you want to use a new disk image for /boot, then yes, the disk image only need one small partition. You can still use LVM from the orginal disk -- no need to migrate/copy that. If you want to modify the existing partition table manually, BE CAREFUL. fdisk uses cylinders as unit by default, so you should switch to sectors. Here''s an example: # fdisk -l /dev/xvda Disk /dev/xvda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/xvda1 1 1000 8032468+ 8e Linux LVM /dev/xvda2 1001 1305 2449912+ 5 Extended /dev/xvda5 * 1001 1305 2449881 83 Linux # fdisk -lu /dev/xvda Disk /dev/xvda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/xvda1 63 16064999 8032468+ 8e Linux LVM /dev/xvda2 16065000 20964824 2449912+ 5 Extended /dev/xvda5 * 16065063 20964824 2449881 83 Linux Now if you recreate the partition table using cyulinders as unit, the Linux partition will start on the wrong sector. It will be unusable. However if you use sectors as unit (fdisk -u) you can recreate the partition table to be like this # fdisk -lu /dev/xvda Disk /dev/xvda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/xvda1 * 16065063 20964824 2449881 83 Linux /dev/xvda2 63 16064999 8032468+ 8e Linux LVM Partition table entries are not in disk order pygrub can work with that. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 18:03 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@verizon.net> wrote: > >>> At this point it''s probably easiest to just create another virtual >>> disk with one primary partition, and copy the contents of the original >>> /boot there. It''s A LOT easier compared to messing up with existing >>> partition table. Your domU config should then look something like this >>> >>> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", >>> "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] >>> >>> >> If I do this then maybe I can straighten the original partition table out; >> remove the last two partitions and create a primary active partition for >> /boot. >> > > If you want to use a new disk image for /boot, then yes, the disk > image only need one small partition. You can still use LVM from the > orginal disk -- no need to migrate/copy that. > > If you want to modify the existing partition table manually, BE > CAREFUL. fdisk uses cylinders as unit by default, so you should switch > to sectors. Here''s an example: > > # fdisk -l /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 1 1000 8032468+ 8e Linux LVM > /dev/xvda2 1001 1305 2449912+ 5 Extended > /dev/xvda5 * 1001 1305 2449881 83 Linux > > # fdisk -lu /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 63 16064999 8032468+ 8e Linux LVM > /dev/xvda2 16065000 20964824 2449912+ 5 Extended > /dev/xvda5 * 16065063 20964824 2449881 83 Linux > > Now if you recreate the partition table using cyulinders as unit, the > Linux partition will start on the wrong sector. It will be unusable. > However if you use sectors as unit (fdisk -u) you can recreate the > partition table to be like this > > # fdisk -lu /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 * 16065063 20964824 2449881 83 Linux > /dev/xvda2 63 16064999 8032468+ 8e Linux LVM > > Partition table entries are not in disk order > > pygrub can work with that. > >The more I thought about this the more I think this is not a distro problem. It is a pygrub deficiency and pygrub needs to grow the ability to handle these types of partitionings. KVM has no problem booting these guests. And even though the partitioning isn''t optimal it is still valid. We can''t go asking distros to modify their valid partitioning just to make it ''optimal'' for pygrub. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Boris Derzhavets
2009-Dec-31 18:46 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
> We can''t go asking distros to modify their valid > partitioning just to make it ''optimal'' for pygrub.It''s up to you. View for instance :- http://lxer.com/module/newswire/view/114282/index.html Boris --- On Thu, 12/31/09, Gerry Reno <greno@verizon.net> wrote: From: Gerry Reno <greno@verizon.net> Subject: Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data! To: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Date: Thursday, December 31, 2009, 1:03 PM Fajar A. Nugraha wrote:> On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@verizon.net> wrote: > >>> At this point it''s probably easiest to just create another virtual >>> disk with one primary partition, and copy the contents of the original >>> /boot there. It''s A LOT easier compared to messing up with existing >>> partition table. Your domU config should then look something like this >>> >>> disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", >>> "tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] >>> >>> >> If I do this then maybe I can straighten the original partition table out; >> remove the last two partitions and create a primary active partition for >> /boot. >> > > If you want to use a new disk image for /boot, then yes, the disk > image only need one small partition. You can still use LVM from the > orginal disk -- no need to migrate/copy that. > > If you want to modify the existing partition table manually, BE > CAREFUL. fdisk uses cylinders as unit by default, so you should switch > to sectors. Here''s an example: > > # fdisk -l /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 1 1000 8032468+ 8e Linux LVM > /dev/xvda2 1001 1305 2449912+ 5 Extended > /dev/xvda5 * 1001 1305 2449881 83 Linux > > # fdisk -lu /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 63 16064999 8032468+ 8e Linux LVM > /dev/xvda2 16065000 20964824 2449912+ 5 Extended > /dev/xvda5 * 16065063 20964824 2449881 83 Linux > > Now if you recreate the partition table using cyulinders as unit, the > Linux partition will start on the wrong sector. It will be unusable. > However if you use sectors as unit (fdisk -u) you can recreate the > partition table to be like this > > # fdisk -lu /dev/xvda > > Disk /dev/xvda: 10.7 GB, 10737418240 bytes > 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > Units = sectors of 1 * 512 = 512 bytes > > Device Boot Start End Blocks Id System > /dev/xvda1 * 16065063 20964824 2449881 83 Linux > /dev/xvda2 63 16064999 8032468+ 8e Linux LVM > > Partition table entries are not in disk order > > pygrub can work with that. > >The more I thought about this the more I think this is not a distro problem. It is a pygrub deficiency and pygrub needs to grow the ability to handle these types of partitionings. KVM has no problem booting these guests. And even though the partitioning isn''t optimal it is still valid. We can''t go asking distros to modify their valid partitioning just to make it ''optimal'' for pygrub. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Pasi Kärkkäinen
2009-Dec-31 19:14 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Thu, Dec 31, 2009 at 01:03:29PM -0500, Gerry Reno wrote:> Fajar A. Nugraha wrote: > >On Thu, Dec 31, 2009 at 1:46 PM, Gerry Reno <greno@verizon.net> wrote: > > > >>>At this point it''s probably easiest to just create another virtual > >>>disk with one primary partition, and copy the contents of the original > >>>/boot there. It''s A LOT easier compared to messing up with existing > >>>partition table. Your domU config should then look something like this > >>> > >>>disk = [ "tap:aio:/var/lib/xen/images/CLOUD-CC-1-boot.img,xvda,w", > >>>"tap:aio:/var/lib/xen/images/CLOUD-CC-1.img,xvdb,w" ] > >>> > >>> > >>If I do this then maybe I can straighten the original partition table out; > >>remove the last two partitions and create a primary active partition for > >>/boot. > >> > > > >If you want to use a new disk image for /boot, then yes, the disk > >image only need one small partition. You can still use LVM from the > >orginal disk -- no need to migrate/copy that. > > > >If you want to modify the existing partition table manually, BE > >CAREFUL. fdisk uses cylinders as unit by default, so you should switch > >to sectors. Here''s an example: > > > ># fdisk -l /dev/xvda > > > >Disk /dev/xvda: 10.7 GB, 10737418240 bytes > >255 heads, 63 sectors/track, 1305 cylinders > >Units = cylinders of 16065 * 512 = 8225280 bytes > > > > Device Boot Start End Blocks Id System > >/dev/xvda1 1 1000 8032468+ 8e Linux LVM > >/dev/xvda2 1001 1305 2449912+ 5 Extended > >/dev/xvda5 * 1001 1305 2449881 83 Linux > > > ># fdisk -lu /dev/xvda > > > >Disk /dev/xvda: 10.7 GB, 10737418240 bytes > >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > >Units = sectors of 1 * 512 = 512 bytes > > > > Device Boot Start End Blocks Id System > >/dev/xvda1 63 16064999 8032468+ 8e Linux LVM > >/dev/xvda2 16065000 20964824 2449912+ 5 Extended > >/dev/xvda5 * 16065063 20964824 2449881 83 Linux > > > >Now if you recreate the partition table using cyulinders as unit, the > >Linux partition will start on the wrong sector. It will be unusable. > >However if you use sectors as unit (fdisk -u) you can recreate the > >partition table to be like this > > > ># fdisk -lu /dev/xvda > > > >Disk /dev/xvda: 10.7 GB, 10737418240 bytes > >255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors > >Units = sectors of 1 * 512 = 512 bytes > > > > Device Boot Start End Blocks Id System > >/dev/xvda1 * 16065063 20964824 2449881 83 Linux > >/dev/xvda2 63 16064999 8032468+ 8e Linux LVM > > > >Partition table entries are not in disk order > > > >pygrub can work with that. > > > > > > The more I thought about this the more I think this is not a distro > problem. It is a pygrub deficiency and pygrub needs to grow the ability > to handle these types of partitionings. KVM has no problem booting > these guests. And even though the partitioning isn''t optimal it is > still valid. We can''t go asking distros to modify their valid > partitioning just to make it ''optimal'' for pygrub. >Well you could always run it as Xen HVM fully virtualized guest. That would be pretty close to running it as KVM guest. If you want to run it as Xen PV (paravirtualized) guest, then you need to have the disk configuration so that pygrub can work. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 21:55 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Boris Derzhavets wrote:> > > We can''t go asking distros to modify their valid > > partitioning just to make it ''optimal'' for pygrub. > > It''s up to you. View for instance :- > http://lxer.com/module/newswire/view/114282/index.html > > Boris >Boris, I don''t even know why pygrub is having such a problem with the partitioning. There is only one 83 partition and it contains /boot. Why can''t pygrub see this? It''s a normal Linux partition, not LVM or anything exotic. It is apparently because pygrub cannot even read extended partitions. And how long have extended partition reading algorithms been around? 20 years? -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 22:10 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Fri, Jan 1, 2010 at 1:03 AM, Gerry Reno <greno@verizon.net> wrote:> The more I thought about this the more I think this is not a distro problem. > It is a pygrub deficiency and pygrub needs to grow the ability to handle > these types of partitionings.AFAIK the "original" DOS MBR is only able to boot from primary, bootable partition. Other distros (RHEL for example) honors that. pygrub is not perfect. In this particular case, it''s using the partition information to simply determine which partition contains the grub config file. It behaves similar to DOS MBR, in that it looks for primary, bootable partition. This has worked good enough so far. You could probably make it work with Ubuntu''s partitioning scheme. However my guess is the developers have more important things in on their hands, so if you want it fixed you should submit patches (similar to Sun, which has contributed patches that allows pygrub to work with zfs).> KVM has no problem booting these guests.That''s because KVM (and also Xen HVM) reads and executes the code in the disk''s MBR (in your case, grub). pygrub doesn''t.> And > even though the partitioning isn''t optimal it is still valid. We can''t go > asking distros to modify their valid partitioning just to make it ''optimal'' > for pygrub.Not to make it "optimal" for pygrub. Make it compatible with legacy DOS MBR and other bootloaders. As a side not, you MIGHT be able to use pvgrub. It uses something like this on domU config file kernel="/usr/lib/xen/boot/pv-grub-x86_64.gz" extra="(hd0,1)/boot/grub/menu.lst" Since the config file is specified directly as "extra" line, it should not need to use the information in partition table to determine which partition is active. -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Boris Derzhavets
2009-Dec-31 22:44 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
>It is apparently because pygrub cannot even read extended partitionsYes, i guess /boot should mounted on /dev/xvda1 (primary). When building Unumtu 9.10 DomU from scratch it shouldn''t be a problem to make "pygrub" happy. I didn''t follow this thread and might miss something. Take /boot out of LVM. Boris. --- On Thu, 12/31/09, Gerry Reno <greno@verizon.net> wrote: From: Gerry Reno <greno@verizon.net> Subject: Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data! To: "xen-users@lists.xensource.com" <xen-users@lists.xensource.com> Date: Thursday, December 31, 2009, 4:55 PM Boris Derzhavets wrote:> > > We can''t go asking distros to modify their valid > > partitioning just to make it ''optimal'' for pygrub. > > It''s up to you. View for instance :- > http://lxer.com/module/newswire/view/114282/index.html > > Boris >Boris, I don''t even know why pygrub is having such a problem with the partitioning. There is only one 83 partition and it contains /boot. Why can''t pygrub see this? It''s a normal Linux partition, not LVM or anything exotic. It is apparently because pygrub cannot even read extended partitions. And how long have extended partition reading algorithms been around? 20 years? -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 23:10 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> As a side not, you MIGHT be able to use pvgrub. It uses something like > this on domU config file > > kernel="/usr/lib/xen/boot/pv-grub-x86_64.gz" > extra="(hd0,1)/boot/grub/menu.lst" > > Since the config file is specified directly as "extra" line, it should > not need to use the information in partition table to determine which > partition is active. >I tried this and things are starting to work a little. Here''s what i get using pv-grub: # xm create CLOUD-CC-1.py Using config file "./CLOUD-CC-1.py". Started domain CLOUD-CC-1 (id=17) root@grp-01-23-02:/var/lib/xen/images# xm console CLOUD-CC-1 Xen Minimal OS! start_info: 0xb8e000(VA) nr_pages: 0x40000 shared_inf: 0xafdd1000(MA) pt_base: 0xb91000(VA) nr_pt_frames: 0xb mfn_list: 0x98e000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: (hd0,4)/boot/grub/menu.lst stack: 0x94d9a0-0x96d9a0 MM: Init _text: 0x0(VA) _etext: 0x5f90d(VA) _erodata: 0x77000(VA) _edata: 0x7fb00(VA) stack start: 0x94d9a0(VA) _end: 0x98dfa8(VA) start_pfn: b9f max_pfn: 40000 Mapping memory range 0x1000000 - 0x40000000 setting 0x0-0x77000 readonly skipped 0x1000 MM: Initialise page allocator for d97000(d97000)-40000000(40000000) MM: done Demand map pfns at 40001000-2040001000. Heap resides at 2040002000-4040002000. Initialising timer interface Initialising console ... done. gnttab_table mapped at 0x40001000. Initialising scheduler Thread "Idle": pointer: 0x2040002010, stack: 0xfb0000 Initialising xenbus Thread "xenstore": pointer: 0x20400027c0, stack: 0xfc0000 Dummy main: start_info=0x96daa0 Thread "main": pointer: 0x2040002f70, stack: 0xfd0000 "main" "(hd0,4)/boot/grub/menu.lst" vbd 51712 is hd0 ******************* BLKFRONT for device/vbd/51712 ********** backend at /local/domain/0/backend/tap/17/51712 And it just gets stuck right here in state "-b-----". -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2009-Dec-31 23:17 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Boris Derzhavets wrote:> >It is apparently because pygrub cannot even read extended partitions > > Yes, i guess > /boot should mounted on /dev/xvda1 (primary). > When building Unumtu 9.10 DomU from scratch it shouldn''t be a problem > to make "pygrub" happy. > > I didn''t follow this thread and might miss something. Take /boot out > of LVM. > > Boris.. >No. /boot is not in LVM. It''s in an extended partition but it is a regular /dev/xvda5 Linux partition holding the /boot filesystem. It seems the only problem is that pygrub cannot read extended partitions. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Fajar A. Nugraha
2009-Dec-31 23:28 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
On Friday, January 1, 2010, Gerry Reno <greno@verizon.net> wrote:> > I tried this and things are starting to work a little. Here''s what i get using pv-grub:> > Thread "main": pointer: 0x2040002f70, stack: 0xfd0000 > "main" "(hd0,4)/boot/grub/menu.lst"shouldn''t it be (hd0,4)/grub/menu.lst on your setup? -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2010-Jan-01 00:26 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Friday, January 1, 2010, Gerry Reno <greno@verizon.net> wrote: > >> I tried this and things are starting to work a little. Here''s what i get using pv-grub: >> > > >> Thread "main": pointer: 0x2040002f70, stack: 0xfd0000 >> "main" "(hd0,4)/boot/grub/menu.lst" >> > > > shouldn''t it be (hd0,4)/grub/menu.lst on your setup? > >Yes. And I just tried it and it still does the exact same thing. It gets stuck in the same place. Not sure what is causing this. Here''s xend.log: [2009-12-31 18:08:50 1852] DEBUG (XendDomainInfo:92) XendDomainInfo.create([''vm'', [''name'', ''CLOUD-CC-1''], [''memory'', 1024], [''maxmem'', 1024], [''on_poweroff'', ''destroy''], [''on_reboot'', ''restart''], [''on_crash'', ''restart''], [''vcpus'', 1], [''on_xend_start'', ''ignore''], [''on_xend_stop'', ''ignore''], [''image'', [''linux'', [''kernel'', ''/usr/lib/xen/boot/pv-grub-x86_64.gz''], [''videoram'', 4], [''args'', ''(hd0,4)/boot/grub/menu.lst'']]], [''s3_integrity'', 1], [''device'', [''tap'', [''uname'', ''tap:aio:/var/lib/xen/images/CLOUD-CC-1.img''], [''dev'', ''xvda''], [''mode'', ''w'']]], [''device'', [''vif'', [''bridge'', ''virbr0''], [''mac'', ''00:16:1a:2a:ef:56'']]]]) [2009-12-31 18:08:50 1852] DEBUG (XendDomainInfo:2296) XendDomainInfo.constructDomain [2009-12-31 18:08:50 1852] DEBUG (balloon:166) Balloon: 6713852 KiB free; need 4096; done. [2009-12-31 18:08:50 1852] DEBUG (XendDomain:452) Adding Domain: 18 [2009-12-31 18:08:50 1852] DEBUG (XendDomainInfo:2497) XendDomainInfo.initDomain: 18 256 [2009-12-31 18:08:50 1852] DEBUG (XendDomainInfo:2521) _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, memory_static_min=0x0. [2009-12-31 18:08:50 1852] DEBUG (balloon:166) Balloon: 6713736 KiB free; need 1052672; done. [2009-12-31 18:08:50 1852] INFO (image:173) buildDomain os=linux dom=18 vcpus=1 [2009-12-31 18:08:50 1852] DEBUG (image:659) domid = 18 [2009-12-31 18:08:50 1852] DEBUG (image:660) memsize = 1024 [2009-12-31 18:08:50 1852] DEBUG (image:661) image = /usr/lib/xen/boot/pv-grub-x86_64.gz [2009-12-31 18:08:50 1852] DEBUG (image:662) store_evtchn = 1 [2009-12-31 18:08:50 1852] DEBUG (image:663) console_evtchn = 2 [2009-12-31 18:08:50 1852] DEBUG (image:664) cmdline = (hd0,4)/boot/grub/menu.lst [2009-12-31 18:08:50 1852] DEBUG (image:665) ramdisk [2009-12-31 18:08:50 1852] DEBUG (image:666) vcpus = 1 [2009-12-31 18:08:50 1852] DEBUG (image:667) features [2009-12-31 18:08:50 1852] DEBUG (image:668) flags = 0 [2009-12-31 18:08:50 1852] INFO (XendDomainInfo:2160) createDevice: tap : {''bootable'': 1, ''uname'': ''tap:aio:/var/lib/xen/images/CLOUD-CC-1.img'', ''mode'': ''w'', ''dev'': ''xvda'', ''uuid'': ''5f81dc14-8c87-efb5-57d5-cbd4cbf55a5f''} [2009-12-31 18:08:50 1852] DEBUG (DevController:95) DevController: writing {''virtual-device'': ''51712'', ''device-type'': ''disk'', ''protocol'': ''x86_64-abi'', ''backend-id'': ''0'', ''state'': ''1'', ''backend'': ''/local/domain/0/backend/tap/18/51712''} to /local/domain/18/device/vbd/51712. [2009-12-31 18:08:50 1852] DEBUG (DevController:97) DevController: writing {''domain'': ''CLOUD-CC-1'', ''frontend'': ''/local/domain/18/device/vbd/51712'', ''uuid'': ''5f81dc14-8c87-efb5-57d5-cbd4cbf55a5f'', ''bootable'': ''1'', ''dev'': ''xvda'', ''state'': ''1'', ''params'': ''aio:/var/lib/xen/images/CLOUD-CC-1.img'', ''mode'': ''w'', ''online'': ''1'', ''frontend-id'': ''18'', ''type'': ''tap''} to /local/domain/0/backend/tap/18/51712. [2009-12-31 18:08:50 1852] INFO (XendDomainInfo:2160) createDevice: vif : {''bridge'': ''virbr0'', ''mac'': ''00:16:1a:2a:ef:56'', ''uuid'': ''42c00899-08a8-6eaf-fc22-05bd3cbda6d1''} [2009-12-31 18:08:50 1852] DEBUG (DevController:95) DevController: writing {''mac'': ''00:16:1a:2a:ef:56'', ''handle'': ''0'', ''protocol'': ''x86_64-abi'', ''backend-id'': ''0'', ''state'': ''1'', ''backend'': ''/local/domain/0/backend/vif/18/0''} to /local/domain/18/device/vif/0. [2009-12-31 18:08:50 1852] DEBUG (DevController:97) DevController: writing {''bridge'': ''virbr0'', ''domain'': ''CLOUD-CC-1'', ''handle'': ''0'', ''uuid'': ''42c00899-08a8-6eaf-fc22-05bd3cbda6d1'', ''script'': ''/etc/xen/scripts/vif-bridge'', ''mac'': ''00:16:1a:2a:ef:56'', ''frontend-id'': ''18'', ''state'': ''1'', ''online'': ''1'', ''frontend'': ''/local/domain/18/device/vif/0''} to /local/domain/0/backend/vif/18/0. [2009-12-31 18:08:51 1852] DEBUG (XendDomainInfo:3052) Storing VM details: {''on_xend_stop'': ''ignore'', ''shadow_memory'': ''0'', ''uuid'': ''2b2a7135-71aa-cad2-daec-cc1985804fac'', ''on_reboot'': ''restart'', ''start_time'': ''1262300931.01'', ''on_poweroff'': ''destroy'', ''bootloader_args'': '''', ''on_xend_start'': ''ignore'', ''on_crash'': ''restart'', ''xend/restart_count'': ''0'', ''vcpus'': ''1'', ''vcpu_avail'': ''1'', ''bootloader'': '''', ''image'': "(linux (kernel /usr/lib/xen/boot/pv-grub-x86_64.gz) (args ''(hd0,4)/boot/grub/menu.lst'') (videoram 4) (notes))", ''name'': ''CLOUD-CC-1''} [2009-12-31 18:08:51 1852] DEBUG (XendDomainInfo:1622) Storing domain details: {''console/ring-ref'': ''2262891'', ''console/port'': ''2'', ''name'': ''CLOUD-CC-1'', ''console/limit'': ''1048576'', ''vm'': ''/vm/2b2a7135-71aa-cad2-daec-cc1985804fac'', ''domid'': ''18'', ''store/port'': ''1'', ''cpu/0/availability'': ''online'', ''memory/target'': ''1048576'', ''control/platform-feature-multiprocessor-suspend'': ''1'', ''store/ring-ref'': ''2262892'', ''console/type'': ''xenconsoled''} [2009-12-31 18:08:51 1852] DEBUG (DevController:95) DevController: writing {''protocol'': ''x86_64-abi'', ''state'': ''1'', ''backend-id'': ''0'', ''backend'': ''/local/domain/0/backend/console/18/0''} to /local/domain/18/device/console/0. [2009-12-31 18:08:51 1852] DEBUG (DevController:97) DevController: writing {''domain'': ''CLOUD-CC-1'', ''frontend'': ''/local/domain/18/device/console/0'', ''uuid'': ''638c11f0-81c5-464e-b601-4fd7b183fe01'', ''frontend-id'': ''18'', ''state'': ''1'', ''location'': ''2'', ''online'': ''1'', ''protocol'': ''vt100''} to /local/domain/0/backend/console/18/0. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vif. [2009-12-31 18:08:51 1852] DEBUG (XendDomainInfo:1709) XendDomainInfo.handleShutdownWatch [2009-12-31 18:08:51 1852] DEBUG (DevController:144) Waiting for 0. [2009-12-31 18:08:51 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vif/18/0/hotplug-status. [2009-12-31 18:08:51 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vif/18/0/hotplug-status. [2009-12-31 18:08:51 1852] DEBUG (DevController:643) hotplugStatusCallback 1. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vkbd. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices ioports. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices tap. [2009-12-31 18:08:51 1852] DEBUG (DevController:144) Waiting for 51712. [2009-12-31 18:08:51 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/tap/18/51712/hotplug-status. [2009-12-31 18:08:51 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/tap/18/51712/hotplug-status. [2009-12-31 18:08:51 1852] DEBUG (DevController:643) hotplugStatusCallback 1. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices console. [2009-12-31 18:08:51 1852] DEBUG (DevController:144) Waiting for 0. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vscsi. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vbd. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices irq. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vfb. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices pci. [2009-12-31 18:08:51 1852] DEBUG (DevController:139) Waiting for devices vtpm. [2009-12-31 18:08:51 1852] INFO (XendDomain:1180) Domain CLOUD-CC-1 (18) unpaused. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2010-Jan-01 00:35 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
Fajar A. Nugraha wrote:> On Friday, January 1, 2010, Gerry Reno <greno@verizon.net> wrote: > >> I tried this and things are starting to work a little. Here''s what i get using pv-grub: >> > > >> Thread "main": pointer: 0x2040002f70, stack: 0xfd0000 >> "main" "(hd0,4)/boot/grub/menu.lst" >> > > > shouldn''t it be (hd0,4)/grub/menu.lst on your setup? > >Yes. And I just tried it and it still does the exact same thing. It gets stuck in the same place. Not sure what is causing this. Here''s xend.log: Sorry, sent wrong log entry last time... Here''s the right one.> [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:92) XendDomainInfo.create([''vm'', [''name'', ''CLOUD-CC-1''], [''memory'', 1024], [''maxmem'', 1024], [''on_poweroff'', ''destroy''], [''on_reboot'', ''restart''], [''on_crash'', ''restart''], [''vcpus'', 1], [''on_xend_start'', ''ignore''], [''on_xend_stop'', ''ignore''], [''image'', [''linux'', [''kernel'', ''/usr/lib/xen/boot/pv-grub-x86_64.gz''], [''videoram'', 4], [''args'', ''(hd0,4)/grub/menu.lst'']]], [''s3_integrity'', 1], [''device'', [''tap'', [''uname'', ''tap:aio:/var/lib/xen/images/CLOUD-CC-1.img''], [''dev'', ''xvda''], [''mode'', ''w'']]], [''device'', [''vif'', [''bridge'', ''virbr0''], [''mac'', ''00:16:1a:2a:ef:56'']]]]) > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:2296) XendDomainInfo.constructDomain > [2009-12-31 19:30:52 1852] DEBUG (balloon:166) Balloon: 6713852 KiB free; need 4096; done. > [2009-12-31 19:30:52 1852] DEBUG (XendDomain:452) Adding Domain: 19 > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:2497) XendDomainInfo.initDomain: 19 256 > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:2521) _initDomain:shadow_memory=0x0, memory_static_max=0x40000000, memory_static_min=0x0. > [2009-12-31 19:30:52 1852] DEBUG (balloon:166) Balloon: 6713736 KiB free; need 1052672; done. > [2009-12-31 19:30:52 1852] INFO (image:173) buildDomain os=linux dom=19 vcpus=1 > [2009-12-31 19:30:52 1852] DEBUG (image:659) domid = 19 > [2009-12-31 19:30:52 1852] DEBUG (image:660) memsize = 1024 > [2009-12-31 19:30:52 1852] DEBUG (image:661) image = /usr/lib/xen/boot/pv-grub-x86_64.gz > [2009-12-31 19:30:52 1852] DEBUG (image:662) store_evtchn = 1 > [2009-12-31 19:30:52 1852] DEBUG (image:663) console_evtchn = 2 > [2009-12-31 19:30:52 1852] DEBUG (image:664) cmdline = (hd0,4)/grub/menu.lst > [2009-12-31 19:30:52 1852] DEBUG (image:665) ramdisk = > [2009-12-31 19:30:52 1852] DEBUG (image:666) vcpus = 1 > [2009-12-31 19:30:52 1852] DEBUG (image:667) features = > [2009-12-31 19:30:52 1852] DEBUG (image:668) flags = 0 > [2009-12-31 19:30:52 1852] INFO (XendDomainInfo:2160) createDevice: tap : {''bootable'': 1, ''uname'': ''tap:aio:/var/lib/xen/images/CLOUD-CC-1.img'', ''mode'': ''w'', ''dev'': ''xvda'', ''uuid'': ''51e87d34-9a09-7798-ab23-261c327884e1''} > [2009-12-31 19:30:52 1852] DEBUG (DevController:95) DevController: writing {''virtual-device'': ''51712'', ''device-type'': ''disk'', ''protocol'': ''x86_64-abi'', ''backend-id'': ''0'', ''state'': ''1'', ''backend'': ''/local/domain/0/backend/tap/19/51712''} to /local/domain/19/device/vbd/51712. > [2009-12-31 19:30:52 1852] DEBUG (DevController:97) DevController: writing {''domain'': ''CLOUD-CC-1'', ''frontend'': ''/local/domain/19/device/vbd/51712'', ''uuid'': ''51e87d34-9a09-7798-ab23-261c327884e1'', ''bootable'': ''1'', ''dev'': ''xvda'', ''state'': ''1'', ''params'': ''aio:/var/lib/xen/images/CLOUD-CC-1.img'', ''mode'': ''w'', ''online'': ''1'', ''frontend-id'': ''19'', ''type'': ''tap''} to /local/domain/0/backend/tap/19/51712. > [2009-12-31 19:30:52 1852] INFO (XendDomainInfo:2160) createDevice: vif : {''bridge'': ''virbr0'', ''mac'': ''00:16:1a:2a:ef:56'', ''uuid'': ''d75188b9-39c1-3f84-5eac-03a520eb58c3''} > [2009-12-31 19:30:52 1852] DEBUG (DevController:95) DevController: writing {''mac'': ''00:16:1a:2a:ef:56'', ''handle'': ''0'', ''protocol'': ''x86_64-abi'', ''backend-id'': ''0'', ''state'': ''1'', ''backend'': ''/local/domain/0/backend/vif/19/0''} to /local/domain/19/device/vif/0. > [2009-12-31 19:30:52 1852] DEBUG (DevController:97) DevController: writing {''bridge'': ''virbr0'', ''domain'': ''CLOUD-CC-1'', ''handle'': ''0'', ''uuid'': ''d75188b9-39c1-3f84-5eac-03a520eb58c3'', ''script'': ''/etc/xen/scripts/vif-bridge'', ''mac'': ''00:16:1a:2a:ef:56'', ''frontend-id'': ''19'', ''state'': ''1'', ''online'': ''1'', ''frontend'': ''/local/domain/19/device/vif/0''} to /local/domain/0/backend/vif/19/0. > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:3052) Storing VM details: {''on_xend_stop'': ''ignore'', ''shadow_memory'': ''0'', ''uuid'': ''9a0579aa-b25f-42d6-133a-d1fc195d34e8'', ''on_reboot'': ''restart'', ''start_time'': ''1262305852.36'', ''on_poweroff'': ''destroy'', ''bootloader_args'': '''', ''on_xend_start'': ''ignore'', ''on_crash'': ''restart'', ''xend/restart_count'': ''0'', ''vcpus'': ''1'', ''vcpu_avail'': ''1'', ''bootloader'': '''', ''image'': "(linux (kernel /usr/lib/xen/boot/pv-grub-x86_64.gz) (args ''(hd0,4)/grub/menu.lst'') (videoram 4) (notes))", ''name'': ''CLOUD-CC-1''} > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:1622) Storing domain details: {''console/ring-ref'': ''2262891'', ''console/port'': ''2'', ''name'': ''CLOUD-CC-1'', ''console/limit'': ''1048576'', ''vm'': ''/vm/9a0579aa-b25f-42d6-133a-d1fc195d34e8'', ''domid'': ''19'', ''store/port'': ''1'', ''cpu/0/availability'': ''online'', ''memory/target'': ''1048576'', ''control/platform-feature-multiprocessor-suspend'': ''1'', ''store/ring-ref'': ''2262892'', ''console/type'': ''xenconsoled''} > [2009-12-31 19:30:52 1852] DEBUG (DevController:95) DevController: writing {''protocol'': ''x86_64-abi'', ''state'': ''1'', ''backend-id'': ''0'', ''backend'': ''/local/domain/0/backend/console/19/0''} to /local/domain/19/device/console/0. > [2009-12-31 19:30:52 1852] DEBUG (DevController:97) DevController: writing {''domain'': ''CLOUD-CC-1'', ''frontend'': ''/local/domain/19/device/console/0'', ''uuid'': ''aa8e6dec-31ff-428d-d1d8-6176e4790892'', ''frontend-id'': ''19'', ''state'': ''1'', ''location'': ''2'', ''online'': ''1'', ''protocol'': ''vt100''} to /local/domain/0/backend/console/19/0. > [2009-12-31 19:30:52 1852] DEBUG (XendDomainInfo:1709) XendDomainInfo.handleShutdownWatch > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vif. > [2009-12-31 19:30:52 1852] DEBUG (DevController:144) Waiting for 0. > [2009-12-31 19:30:52 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/vif/19/0/hotplug-status. > [2009-12-31 19:30:52 1852] DEBUG (DevController:643) hotplugStatusCallback 1. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vkbd. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices ioports. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices tap. > [2009-12-31 19:30:52 1852] DEBUG (DevController:144) Waiting for 51712. > [2009-12-31 19:30:52 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/tap/19/51712/hotplug-status. > [2009-12-31 19:30:52 1852] DEBUG (DevController:629) hotplugStatusCallback /local/domain/0/backend/tap/19/51712/hotplug-status. > [2009-12-31 19:30:52 1852] DEBUG (DevController:643) hotplugStatusCallback 1. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices console. > [2009-12-31 19:30:52 1852] DEBUG (DevController:144) Waiting for 0. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vscsi. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vbd. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices irq. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vfb. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices pci. > [2009-12-31 19:30:52 1852] DEBUG (DevController:139) Waiting for devices vtpm. > [2009-12-31 19:30:52 1852] INFO (XendDomain:1180) Domain CLOUD-CC-1 (19) unpaused. > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2724) XendDomainInfo.destroy: domid=19 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2199) Destroying device model > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2206) Releasing devices > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2219) Removing vif/0 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:1134) XendDomainInfo.destroyDevice: deviceClass = vif, device = vif/0 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2219) Removing console/0 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:1134) XendDomainInfo.destroyDevice: deviceClass = console, device = console/0 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2219) Removing vbd/51712 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:1134) XendDomainInfo.destroyDevice: deviceClass = tap, device = vbd/51712 > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2204) No device model > [2009-12-31 19:31:16 1852] DEBUG (XendDomainInfo:2206) Releasing devices-Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Gerry Reno
2010-Jan-01 02:33 UTC
Re: [Xen-users] Xen 3.4.1: pygrub Error: Boot loader didn''t return any data!
I finally got the converted guest to boot using pv-grub. The last problem was that pv-grub does not like tap:aio so I tried file: and it started working. -Gerry _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users