[gPXE] Booting xen-3.3 with gpxe as a multiboot image

[Nathan Mitchell]

Josh, 

        Thanks for the reply. 

	Yes I did try both orders and they all fail.

	Well, I have had success using a modern version of pxelinux, after being chainloaded from gpxe, 
	to load the images over http. My hope was to load xen without the use of pxelinux at all. My
	understanding was that gpxe had multiboot support and could do the task all by itself. In the end, if
	we have to, we will use pxelinux or perhaps a local boot solution.

        -- Nathan


On Jun 18, 2010, at 10:45 AM, Joshua Oreman wrote:

> On Fri, Jun 18, 2010 at 8:18 AM, Nathan Mitchell <nmitchel at mcs.anl.gov> wrote:
>> Everyone,
>> 
>>           I've busy on other tasks, so its been awhile getting back to you.
>> 
>>           I've tried all the suggestions thus far to little effect. I uncompressed all the modules, reordered them, and I've also tried Shao's idea.
>> 
>>           The mboot.c32 techniques always seem to fail, no matter how its loaded, leading me to suspect a incompatibility with the two pieces
>>            of software.
>> 
>>           As for booting xen directly with gpxe, still no success, but I was able to get the xen kernel to give me messages finally. It does appear
>>           getting past the point where I thought it was hanging, only to get stuck later on.
>> 
>> [...]
>> http://140.221.37.24/initrd.img-2.6.24-24-xen.HTTP 0x1d9a4 response "HTTP/1.1 200 OK"
>> [...]
>> http://140.221.37.24/vmlinuz-2.6.24-24-xen.HTTP 0x1df14 response "HTTP/1.1 200 OK"
>> [...]
>> http://140.221.37.24/xen-3.3.HTTP 0x1e0c4 response "HTTP/1.1 200 OK"
> 
> Reversing the order as Stefan suggested will not work because the
> images are passed to Xen in the order they're loaded, so giving it
> initrd.img first will make it try to load the initrd as the kernel
> (which will fail). I'm guessing it didn't work in the correct order
> either?
> 
>>        As you can see, its failing because something isn't an elf binary. I've done some checking, and have reasonably proven
>>        that my images are not corrupted. Having little else to point to from my own searches, I'm forced to conclude that this
>>        is being caused by gpxe somehow. Especially since when I chainload pxelinux, xen loads fine.  Here is the output from that
>>        as a comparison:
>> [...]
>> TFTP 0x1dde4 requesting "xen-3.3.gz"
>> [...]
>> TFTP 0x1ddf4 requesting "vmlinuz-2.6.24-24-xen"
>> [...]
>> TFTP 0x1ddf4 requesting "initrd.img-2.6.24-24-xen"
> 
> This one works because they're being loaded in the right order.
> 
> You might try using gpxelinux.0 + mboot.c32 to get the PXELINUX method
> working over HTTP.
> 
> -- Josh