iPXE discussion forum

I have a problem in my xenserver installation procedure.

I want to boot with ipxe and this script:


All imgfetch work, and the files transfer successful.

Than the mboot.c32 image boots and want to load xen.gz

"Loading xen.gz ..."

Now it stays here .... stops.

I look into the source of mboot.c and find, that it want to unpack the .gz file - but where it want to get it ? It doesn´t find it or what can happen ?

With imgstat I can list all imgs and parameter I set = looks all correct.

I try also with

imgargs mboot.c32 tftp://192.168.0.1/xen6/boot/xen.gz ...

or

imgargs mboot.c32 http://192.168.0.1/ks/xen6/boot/xen.gz ...

and no imgfetch ... but nothing - always the same point it stops.

Maybe I have misunderstand something and I cannot boot like this with ipxe.

Wie pxelinux the install is like this:


The question now is - where is the image I download with imgfetch ?

Or how can I handle this.

Thanks for reading until here :-)

Jochen

You shouldn't imgfetch anything. But do something like this to load the rest of the command line with relative paths based on where you booted ipxe from. So if you load ipxe.pxe from the root of that tftp server mentioned above, it should be something like this:

(2012-03-02 19:36)robinsmidsrod Wrote: [ -> ]

Code:

chain xen6/boot/mboot.c32 xen6/boot/xen.gz .... xen6/boot/vmlinuz  .... xen6/boot/install.img

The environment is different to normal pxe scenario:

First we have a dhcp proxy and tftpd server on

192.168.0.4

From there we send to the nic card of the server with normal pxe call a ipxe.dsk floppy disk. Boot this ipxe system and load with a cgi call the script I wrote above.

chain http://192.168.0.1/gpxe.cgi?MAC=${net0/mac}

This script return a script for ipxe like that:


I want to redirect the "old" pxe target 192.168.0.4 to .1

The problem is, that I can "download" the mboot.c32 file and than it starts and want to load xen.gz - but the only message I get is that


I don´t know much about mboot.c32 and from where it want to load his files (I know the "relativ to pxe servers root) - I want to do all with http, but I cannot write


Somewhere I have a probleme - but I cannot find it <snief>

thnx
Jochen

I noticed this part in your generated script:

Are you really trying to get your TFTP server to execute a CGI script? I don't know of any TFTP server that supports generated content, like that. I think you need to change that line to http to make it actually execute your CGI script.

Also, have you tried just chaining directly to xen.gz instead of using mboot.c32? iPXE has some support for Multiboot images, and it might just work.

What kind of boot image is this xen.gz file?

Resurrecting this thread as I, too, am having problems with Xen and some others. There are workarounds (like wrapping it all up in an ISO, using ISOlinux and SANbooting...but that is...`unclean`), I'd really like to keep the boot as close to "iPXE Native" as possible. Im summary, we'd like to use iPXE to multiboot from an http address without resorting to a wrapper.

This code from https://gist.github.com/2769396 shows how it's possible to boot the VMware installer directly from iPXE without using mboot.c32. You might be able to adapt it to your Xen loader.

That didn't work, but again Robin, you've shown me some things to look for, and how to look for them. Thank you!

ESXi5 works, Xen Works (sort of), but ESXi4.1 is still vexing me. I have the edited ISO file, and that works (very well, in fact). Documenting how it works is harder than trying to get everything working in iPXE.

(2012-08-09 14:06)robinsmidsrod Wrote: [ -> ]This code from https://gist.github.com/2769396 shows how it's possible to boot the VMware installer directly from iPXE without using mboot.c32. You might be able to adapt it to your Xen loader.

Code:

# Based on details from http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc_50%2FGUID-2F0D4696-3681-4C13-9552-5280C6406376.html
set base-url http://XXX.XXX.XXX.XXX/
kernel ${base-url}tboot.b00
imgargs tboot.b00 ks=${base-url}ks.cfg
module ${base-url}b.b00
module ${base-url}useropts.gz
module ${base-url}k.b00
module ${base-url}a.b00
module ${base-url}s.v00
module ${base-url}weaselin.v00
module ${base-url}tools.t00
module ${base-url}imgdb.tgz
module ${base-url}imgpayld.tgz
boot

Dear Robin,
Have you tested this scriplet? On which version of ESX and which version/commit of iPXE? I'm having same problems, as described here: http://forum.ipxe.org/showthread.php?tid...33#pid8733 on the latest ver of ESX (5.1). Only boot via mboot.c32 and tftpboot works.

I've gotten feedback that ESXi 5.1 doesn't seem to work with this approach (although 5.0 used to work). I'm not a regular esxi user, so I'm not sure what they might've changed.

Be aware that mboot.c32 actually decompresses the files before handing them over to the kernel. iPXE doesn't do that. If the files are gzipped you might need to manually gunzip them and rename them back to the original name (even with the .gz extension) for things to work. I can't recall who on our IRC channel debugged this approach a lot, but I seem to recall they got stuck somewhere. My suggestion is to just enable IMAGE_COMBOOT support in iPXE and use mboot.c32 for now.

(2013-07-20 17:36)robinsmidsrod Wrote: [ -> ]If the files are gzipped you might need to manually gunzip them and rename them back to the original name (even with the .gz extension) for things to work.

Tried that but without any result. Same as with gzipped.

(2013-07-20 17:36)robinsmidsrod Wrote: [ -> ]My suggestion is to just enable IMAGE_COMBOOT support in iPXE and use mboot.c32 for now.

With mboot.c32 it works fine, even over HTTP. But the goal is to get the same with iPXE, any idea?

The only idea I have is to enable debugging for comboot and figure out how you can enable debugging on the esxi side so it can actually tell you more about why things are failing.

What does file(1) tell you about all those files you're trying to load with multiboot, are they all normal uncompressed linux initrds, or something else?

(2013-07-24 12:46)robinsmidsrod Wrote: [ -> ]What does file(1) tell you about all those files you're trying to load with multiboot, are they all normal uncompressed linux initrds, or something else?

As you can see, some of these files are gzip files, but some are special vmware-tar format files (mainly drivers).

I followed the thread on http://lists.ipxe.org/pipermail/ipxe-dev...01846.html and http://lists.ipxe.org/pipermail/ipxe-dev...01846.html but with the same results as described there.

Modules are being loaded (httpd logs shows some GETs) but probably not uncompressed. The main file (loaded with kernel option) and ungzipped:


Also the mboot.c32 is modified by VMware in some way (comparing to original syslinux's version) to load these files... Only something like this works (with mboot from ESX installation ISO):

Tested on ESXi ver 5.1.0U1 (Update 1 @ 2013-05-04-001).

Okay, here is what you need to do. I'm going to use tboot.b00 as an example.


The important thing is that all files need to be uncompressed, but the filename loaded must stay the same.

(2013-07-24 14:05)robinsmidsrod Wrote: [ -> ]The important thing is that all files need to be uncompressed, but the filename loaded must stay the same.

Already tested, as described in ipxe-devel lists (ref in previous post):

Brandon Penglase Wrote:3. All of the modules are actually gzip'd. I used this script
(http://node4.smart-serv.net/~brandon/esxi-script.sh also attached)
to extract almost all of the modules, and rename them back to what
they were called. The ones I don't gunzip are the ones ending in .gz
or similar format, as iPXE does handle them, and it seems the kernel
wants to unpack them itself. From what I was finding, the kernel
would never boot for me when I included all of these as-shipped from
VMWare.

Result? Same as with compressed version - fade-to-black afrer boot command

Then I have no other good solutions for a pure iPXE-based boot. Use mboot.c32 and try to ask vmware why it's not working? I do know there are people dealing with iPXE at VMware, so they should know what you're talking about.

(2013-07-25 12:30)robinsmidsrod Wrote: [ -> ]Then I have no other good solutions for a pure iPXE-based boot. Use mboot.c32 and try to ask vmware why it's not working? I do know there are people dealing with iPXE at VMware, so they should know what you're talking about.

Ok, thanks for your help

So to go back in time and answer the original poster's question, the following snippet of an iPXE script will work to boot the XenServer 6.2 installer, provided two conditions are met.

First, that the contents of the ISO hierarchy are mirrored into a webserver directory, e.g. /var/www/xenserver

Second, that the mboot.c32 from boot/pxelinux/mboot.c32 is symlinked to the root of this hierarchy, e.g. ln -s boot/pxelinux/mboot.c32 /var/www/xenserver/mboot.c32