If you have a large number of machines which already have a PXE implementation (such as network cards with an existing Intel PXE ROM), then you may want to avoid having to reflash each machine's network card individually. You can achieve this by using chainloading.
To enable chainloading, you need to place a copy of iPXE on your TFTP server. Your machines will download this copy of iPXE from the TFTP server each time that they boot.
Download http://boot.ipxe.org/undionly.kpxe and save it to your TFTP server directory.
Configure your DHCP server to hand out
undionly.kpxe as the boot file. If you are using ISC dhcpd then you need to edit
/etc/dhcpd.conf to contain
next-server X.X.X.X; filename "undionly.kpxe";
where X.X.X.X is the IP address of your TFTP server.
At this point, you should be able to boot one of your PXE-capable machines, and see it download iPXE from the TFTP server. If everything has worked, then you should see the iPXE startup banner appear:
iPXE -- Open Source Boot Firmware -- http://ipxe.org
When the chainloaded iPXE starts up, it will issue a fresh DHCP request and boot whatever the DHCP server hands out. The DHCP server is currently set up to hand out the iPXE image, which means that you will be stuck in an infinite loop: PXE will load iPXE which will load iPXE which will load iPXE which will load iPXE…
One way that you can break this infinite loop is to configure the DHCP server to hand out iPXE only for the first DHCP request; the second DHCP request will return the “real” boot filename.
Another way to break the infinite loop is to build iPXE with an embedded script that directs iPXE to boot from a fixed URL. For example, if you create the script file
#!ipxe dhcp chain http://boot.ipxe.org/demo/boot.php
and then build your own version of iPXE with this script embedded:
make bin/undionly.kpxe EMBED=demo.ipxe
then the chainloaded iPXE will always boot from
http://boot.ipxe.org/demo/boot.php regardless of the DHCP server configuration.