PXE Dispatcher for iPXE - Printable Version

PXE Dispatcher for iPXE - Printable Version

+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: PXE Dispatcher for iPXE (/showthread.php?tid=3)

PXE Dispatcher for iPXE - robinsmidsrod - 2011-04-05 18:10

I have created a simple Perl-based script which can be hooked into any web server that supports a standard CGI interface.

You can find the code at: http://github.com/robinsmidsrod/pxe-dispatcher

What I usually do is to symlink this script in the root of my TFTP root (/srv/tftp/ on Ubuntu, which I use) and then I share out that folder as a Samba share (so I can edit the files from a Windows desktop machine). At the end I create a symlink in /var/www/tftp that points to /srv/tftp. This way I can easily boot from either TFTP or HTTP with the same files.

If I create /srv/tftp/pxeboot/default.pxe, this script will automatically be executed by iPXE on boot. If default.pxe doesn't exist, pxelinux.0 is booted if it exists. pxelinux.0 should be installed alongside pxeboot.cgi.

The more interesting part of the script is the part that allows you to create custom boot scripts by MAC of the client. They should be named something like /srv/tftp/pxeboot/0025b35fd52f.pxe. The content of the file is just a normal iPXE script.

My laptop has a boot script file which contains the following code:

Code:

#!ipxe

echo

echo Booting HP laptop

chain freedos.pxe

And for that to work I have a separate file named /srv/tftp/pxeboot/freedos.pxe with the following code in it:

Code:

#!ipxe

echo

echo Booting FreeDOS for ${hostname} from SAN

set keep-san 1

set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.freedos

sanboot ${root-path}

echo Boot from ${root-path} failed, dropping to shell

shell

This enables me to boot FreeDOS on my laptop entirely from an iSCSI target.

Another script I have is named ubuntu-install.pxe and it contains the following code:

Code:

#!ipxe

echo

echo Installing Ubuntu for ${hostname} from SAN

# Setup iSCSI root path

set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.ubuntu

set skip-san-boot 1

set keep-san 1

# Hook iSCSI target

sanboot ${root-path}

# Boot kernel+initrd for Ubuntu install

kernel http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/linux

initrd http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/initrd.gz

imgargs linux ks=http://boot.smidsrod.lan/ubuntu-10.10-amd64-server/boot/ks.cfg

boot

echo Booting failed, dropping to shell

shell

For booting Ubuntu, I just use a script similar to the FreeDOS variant, just with the strings "freedos" replaced with "ubuntu".

Hope some of you will find it useful, and I would love if any of you have any ideas for improvements. If you make any improvements, do send me a pull request on GitHub.

RE: PXE Dispatcher for iPXE - mcb30 - 2011-04-05 18:24

(2011-04-05 18:10)robinsmidsrod Wrote: I have created a simple Perl-based script which can be hooked into any web server that supports a standard CGI interface.

Very neat. I especially like the idea of sending back a fixed script that causes iPXE to call the same CGI script again but with additional parameters for ${uuid} etc.

(2011-04-05 18:10)robinsmidsrod Wrote: And for that to work I have a separate file named /srv/tftp/pxeboot/freedos.pxe with the following code in it:

Code:

#!ipxe echo echo Booting FreeDOS for ${hostname} from SAN set keep-san 1 set root-path iscsi:nas.smidsrod.lan::::iqn.2011-02.lan.smidsrod:${hostname}.boot.freedos sanboot ${root-path} echo Boot from ${root-path} failed, dropping to shell shell

You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

RE: PXE Dispatcher for iPXE - robinsmidsrod - 2011-04-05 18:34

(2011-04-05 18:24)mcb30 Wrote: You need something like

Code:

sanboot ${root-path} ||

to prevent the script from exiting immediately if the sanboot command fails.

Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

RE: PXE Dispatcher for iPXE - mcb30 - 2011-04-05 20:22

(2011-04-05 18:34)robinsmidsrod Wrote:
(2011-04-05 18:24)mcb30 Wrote: You need something like

Code:

sanboot ${root-path} ||
to prevent the script from exiting immediately if the sanboot command fails.
Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

The sanboot command will never return successfully. If it returns at all, it will return with a failure, which will terminate the script before reaching the "drop to shell" line. (See http://ipxe.org/scripting#error_handling).

RE: PXE Dispatcher for iPXE - robinsmidsrod - 2011-04-05 22:51

(2011-04-05 20:22)mcb30 Wrote:
(2011-04-05 18:34)robinsmidsrod Wrote:
(2011-04-05 18:24)mcb30 Wrote: You need something like

Code:

sanboot ${root-path} ||
to prevent the script from exiting immediately if the sanboot command fails.
Actually, I don't expect the sanboot command to return in this case, and as you can see, I drop to the shell if it actually returns.

The sanboot command will never return successfully. If it returns at all, it will return with a failure, which will terminate the script before reaching the "drop to shell" line. (See http://ipxe.org/scripting#error_handling).

This behaviour does seem a bit counter-intuitive. I'm not entirely sure what would be the best behaviour, but failure to actually connect to the SAN URL and failure to actually boot the SAN drive (e.g. missing boot sector) could be considered different.
Failing to connect to the iSCSI target would for me indicate a hard fail, and should throw an exception, but failure to boot the drive is a sort of soft fail, because the problem is with the contents of the drive, and not in communicating with it. I would consider the last one a case of success (in a way).

RE: PXE Dispatcher for iPXE - mcb30 - 2011-04-06 00:01

(2011-04-05 22:51)robinsmidsrod Wrote: This behaviour does seem a bit counter-intuitive. I'm not entirely sure what would be the best behaviour, but failure to actually connect to the SAN URL and failure to actually boot the SAN drive (e.g. missing boot sector) could be considered different.
Failing to connect to the iSCSI target would for me indicate a hard fail, and should throw an exception, but failure to boot the drive is a sort of soft fail, because the problem is with the contents of the drive, and not in communicating with it. I would consider the last one a case of success (in a way).

For the sake of backwards compatibility, the sanboot command will have to fail for either reason. As mentioned elsewhere, I'm looking at implementing separate hook/unhook commands, which would allow you to do something like

Code:

sanhook ${root-path} || goto cannot_connect_to_target

sanboot || goto cannot_boot_from_target

sanunhook

Syntax may change before implementation.

RE: PXE Dispatcher for iPXE - Sha0 - 2011-08-08 15:46

Cool stuff! Smile

For what it's worth, I might just mention that .pxe is used as the file extension for NBPs (Network Bootstrap Programs) under [at least] PXELINUX and 3Com Boot Services.

Personally, I prefer .ipxe as the extension for iPXE scripts. Smile

RE: PXE Dispatcher for iPXE - robinsmidsrod - 2011-08-08 16:10

At first I had .gpxe as the extension (before I noticed the iPXE project), and then I switched it to .ipxe, and eventually I switched it to .pxe because it actually works with both gPXE and iPXE. Some of the more advanced features obviously doesn't work with gPXE, but pxe-dispatcher itself doesn't emit any iPXE-specific script commands.

RE: PXE Dispatcher for iPXE - mymycracra - 2011-10-14 11:14

Hi robin,

Juste wanted to let you know that the PXE dispatcher doesn't with the latest pxelinux (cf http://forum.ipxe.org/showthread.php?tid=1024).

Regards,
JM

RE: PXE Dispatcher for iPXE - robinsmidsrod - 2011-10-14 11:36

"Doesn't work" is a bit vague. Could you add some more detail, or explain in what part of the process things fail? If it is indeed a failure, I'd appreciate a bug report here: https://github.com/robinsmidsrod/pxe-dispatcher/issues