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 <nmitc...@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
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
