Re: [Xen-users] "Boot loader did not return any data" to make HVM to PV

[Flako <subforos@xxxxxxxxx>]

2012/10/19 Alexandre Kouznetsov <alk@xxxxxxxxxx>:
> El 19/10/12 07:39, Flako escribió:
>
>> The truth is that every tutorial I see it differently and I do not
>> know where this error.
>
> Which one you followed?
>
>
>> When I start the domU, pvgrub shows the options but when I select the
>> kenel-xen, returns the error "Boot loader did not return any data!"
>
> You can test pygrub manually:
>
> # touch /var/run/xend/boot/xenbl.bogus
> # /usr/lib/xen-default/bin/pygrub  \
>  '--output=/var/run/xend/boot/xenbl.bogus' \
>  '/mnt/xendomain/ajrPrueba_pv/SLED10_SP2_i586_disco3'
> # cat /var/run/xend/boot/xenbl.bogus
> (see the path of extracted kernel and initrd images, check if they really
> was extracted. Delete them manually aftewards)
> # rm /var/run/xend/boot/xenbl.bogus
> ("rm /var/run/xend/boot/*" might work, but check first)
>
> pygrub will look for kernel and menu.list on the first image mentioned in
> the config. In your case it's SLED10_SP2_i586_disco3. Change it if your boot
> device is the other one.
>
> Note that you will probably need to move your disk image(s) from a
> partitioned block (or loop) device to a raw one. I would use kpartx and dd
> for that, but i have never done that with "tap:qcow2" backends. Use with
> care. Maybe I'm outdated on this.
>
>
>> The truth is that no more look, I'm lost in the different ways of
>> doing HVM to PV.
>
> A common issue is the attempt to mix instructions from different tutorials
> (they might use different approach, incompatible to each other). The other
> side is that it's the way to get the understanding of what's going on,
> instead of blind execution. If this is your case, make sure you know what's
> you are doing.
>
>> /--xend.log file when I start the domU
>> [...]
>>
>>         [2012-10-18 12:25:53 27501] DEBUG (XendBootloader:130) Launching
>> bootloader as ['/usr/bin/pygrub',
>> '--output=/var/run/xend/boot/xenbl.3769', '/dev/xvdz']
>> +++
>> this is where the menu shows pvgrub (/ dev/xvdz1 is mountable and
>> contains the root of linux)
>> +++
>>         [2012-10-18 12:27:31 3511] ERROR (XendBootloader:231) Boot loader
>> didn't return any data!
>
> It seems like pygrub was able to retrieve menu.list file, but not the boot
> image. See below for comment about xen.gz.
>
>
>> /-- domU /grub/menu.list
>> title Xen -- SUSE Linux Enterprise Desktop 10 SP2 xen
>>      root (hd0,0)
>>      kernel /boot/xen.gz
>>      module /boot/vmlinuz-2.6.16.60-0.85.1-xen root=/dev/xvda1
>> vga=0x317 noresume splash=silent showopts clocksource=jiffies
>> console=xvc0
>>      module /boot/initrd-2.6.16.60-0.85.1-xen
>> \-- domU /grub/menu.list
>
> I agree with James Pifer.
> xen.gz is the bootable image of the hypervisor itself. It is executed on the
> host baremetal system once, and immediately boots Dom0. I has nothing to do
> in DomU image.
>
> DomU's menu.list should look very much similar to a normal "xenless" machine
> (or HVM guest), except that it will specify a xen enabled kernel (stored
> within DomU' disk image) and a xen style root device. The initrd shall
> include modules for xenblk and xennet.
>
> In resume, fixing menu.list might do the trick. Also, consider moving to a
> more "native" storage backend, instead of using "tap:qcow" compatibility
> wrapper.
>

James:
   With the correction of menu.list worked (thanks)

Alexandre:
  What you say is true about following tutorials, I try to follow one
that "works" :). (sometimes it is difficult to follow when they are
based on different Linux)

   It pygrub manually running seems not to work because they qcow2
disk (as you say), I see from log xen called as:

DEBUG (XendBootloader: 130) Launching bootloader as
['/usr/bin/pygrub', '- output = / var/run/xend/boot/xenbl.8748', '/
dev / xvdz'].

Where /dev/xvdz what genre previously associated
SLED10_SP2_i586_disco3 disk. (I miss xvdz generate manually for
testing)

When you say "consider moving to a more 'native' storage backend" What
do you mean?
What is the most native backend?

Normally use tap: qcow2 by the reduction of disk space, is slower than
raw but for basic use of linux root I think is acceptable.
For intensive use (database or file server) use disk phy+lvm
Bad idea to combine qcow2 phy and the way I'm doing? which option
would be better?

Thank you both.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users