Description

PXELINUX is a Syslinux derivative,
for booting from a network server using a network ROM conforming to
the Intel PXE (Pre-Execution Environment) specification.
PXELINUX is not a program intended to be flashed or burned into
a PROM on the network card.
For such possibility, check out iPXE (http://ipxe.org/).

If you want to create PXE-compliant boot PROM
for your network card (to use with PXELINUX, for example),
check out NetBoot (http://netboot.sourceforge.net/).

Working directory

The initial Current Working Directory is either
as supplied by DHCP option 210(pxelinux.pathprefix),
the hardcoded path-prefix or
the parent directory of the PXELINUX file,
as indicated by DHCP fields sname and file(sname="192.168.2.3" and
file="boot/pxelinux.0"
result in
"tftp://192.168.2.3/boot/",
or in
"192.168.2.3::boot/"
in older PXELINUX format)
with the precedence as specified under the #Options section of this document.

After attempting the file as specified in the DHCP
or hardcoded options,
PXELINUX will probe the following paths,
prefixed with "pxelinux.cfg/",
under the initial Working Directory.

The client UUID, if provided by the PXE stack.

Note that some BIOSes do not have a valid UUID, and it might end up reporting something like all 1's.

This value is represented in the standard UUID format using lowercase hexadecimal digits, e.g. "b8945908-d6a6-41a9-611d-74a6ab80b83d".

The hardware type (using its ARP type code) and address, all in lowercase hexadecimal with dash separators.

For example, for an Ethernet (ARP type "1") with address "88:99:AA:BB:CC:DD", it would search for the filename "01-88-99-aa-bb-cc-dd".

The client's own IPv4 address in uppercase hexadecimal, followed by removing hex characters, one at a time, from the end. For example, "192.168.2.91" → "C0A8025B".

The included program, "gethostip", can be used to compute the hexadecimal IP address for any host.

Lowercase "default".

Note that all references to filenames are relative to the
directory in which "pxelinux.0" lives.

PXELINUX generally requires for filenames (including any relative path)
to be 127 characters or shorter in length.

[3.20+] If PXELINUX cannot find a configuration file,
it will reboot after the timeout interval has expired.
This keeps a machine from getting stuck indefinitely due to a boot server failure.

Options

[1.62+] Depending on the specific DHCP server,
the following nonstandard DHCP options might be available
so to customize the specific behaviour of PXELINUX.
See RFC 5071 for some additional information about these options.
Options for PXELINUX can be specified by DHCP options,
or hardcoded into the binary.

Option priority

DHCP options

Option 208 pxelinux.magic

Earlier versions of PXELINUX required this option to be set to F1:00:74:7E(241.0.116.126) for PXELINUX to be able to recognize any special DHCP options whatsoever. As of PXELINUX 3.55, this option is deprecated and is no longer required.

Option 209 pxelinux.configfile

Specify the initial PXELINUX configuration file name, which may be qualified or unqualified.

Option 210 pxelinux.pathprefix

Specify the PXELINUX common path prefix, instead of deriving it from the boot file name. This almost certainly needs to end in whatever character the TFTP server OS uses as a pathname separator, e.g. slash (/) for Unix.

Option 211 pxelinux.reboottime

Specify, in seconds, the time to wait before reboot in the event of TFTP failure. "0" (zero) means wait "forever" (in reality, it waits approximately 136 years).

Hardcoded options

[3.83+] The program "pxelinux-options"
can be used to hard-code DHCP options into the
"pxelinux.0" image file.
This is sometimes useful when the DHCP server is under different
administrative control.

HTTP and FTP

Older versions of PXELINUX supported HTTP by using a hybrid bootloader
that also contained gPXE/iPXE,
with such images named either gpxelinux.0 or ipxelinux.0.

Since version 5.10, a special PXELINUX binary, lpxelinux.0,
natively supports HTTP and FTP transfers, greatly increasing load speed
and allowing for standard HTTP scripts to present PXELINUX's configuration file.
To use HTTP or FTP, use standard URL syntax as filename;
use DHCP options to transmit a suitable URL prefix to the client,
or use the "pxelinux-options" tool provided in the "utils" directory
to program it directly into the lpxelinux.0 file.

While using HTTP/FTP (syntax), trying to use pxelinux.0
(i.e. without the letter "l" prefix) without
iPXE/gPXE running underneath,
will result in a "file not found" warning without any
explanation as to the cause!

Filename syntax

Suppress the common filename prefix, i.e. passes the string "filename" unmodified to the server.

IP address::filename

(e.g. 192.168.2.3::filename)

Suppress the common filename prefix, and send a request to an alternate TFTP server.

Instead of an IP address, a DNS name can be used.

It will be assumed to be fully qualified if it contains dots; otherwise the local domain as reported by the DHCP server (option 15) will be added.

The double colon symbol ("::") was chosen because it is unlikely to
conflict with operating system usage.
However, if you happen to have an environment for which the special
treatment of "::" is a problem,
please contact the Syslinux mailing list.

[4.00+], PXELINUX also supports standard URL syntax.

Keeppxe

Normally, PXELINUX will unload the PXE and UNDI stacks before invoking the kernel.
In special circumstances (for example, when using MEMDISK to boot an
operating system with an UNDI network driver) it might be desirable to
keep the PXE stack in memory.
If the option "keeppxe" is given on the kernel command line,
then PXELINUX will keep the PXE and UNDI stacks in memory.
(If you don't know what this means, you probably don't need it.)

Examples

Configuration filename

For DHCP siaddr "192.168.2.3",
file "mybootdir/pxelinux.0",
client UUID "b8945908-d6a6-41a9-611d-74a6ab80b83d",
Ethernet MAC address "88:99:AA:BB:CC:DD"
and IPv4 address "192.168.2.91",
the following files will be attempted in this order
(after "config-file" options):

atftp is likely going to perform better than "tftp-hpa" on a large boot server, but may not be quite as widely portable.

If your boot server is running Windows (and you can't change that), try "tftpd32" by Philippe Jounin (you need version 2.11 or later; previous versions had a bug which made it incompatible with PXELINUX):

Eric Cook of Intel also reports that the TFTPD server from Win2000 Server RIS can be used:

The trick is to install RIS, but don't configure it with the GUI.
Instead, do the following:
In the registry, add the folder
\HKLM\System\CurrentControlSet\Services\TFTPD\Parameters.
In the Parameters folder, add a key called Directory,
with a value of the TFTP root directory path. With the Services GUI,
configure the TFTPD service for Automatic start and start it.
If you DO configure the RIS in Win2k,
you end up with the MS PXE stuff, which is ugly to get rid of.

However, Christian "Dr. Disk" Hechelmann reports having success with using the Windows RIS as-is, and has sent a nice writeup on how to set it up. See Windows Remote Install System.

DHCP config - Simple

The PXE protocol uses a very complex set of extensions to DHCP or BOOTP.
However, most PXE implementations -- this includes all
Intel ones version 0.99n and later -- seem to be able
to boot in a "conventional" DHCP/TFTP configuration.
Assuming you don't have to support any very old or otherwise severely
broken clients, this is probably the best configuration unless you
already have a PXE boot server on your network.

A sample DHCP setup, using the "conventional TFTP" configuration,
would look something like the following, using ISC dhcp (2.0 or later)
"dhcpd.conf" syntax:

Note that if your particular TFTP daemon runs under chroot
(tftp-hpa will do this if you specify
the "-s" (secure) option;
this is highly recommended),
you almost certainly should not include the /tftpboot prefix in the
filename statement.

DHCP Config - PXE-1

If the simple config does not work for your environment, you probably
should set up a "PXE boot server" on port 4011 of your TFTP server;
a free PXE boot server is available at:
http://www.kano.org.uk/projects/pxe/

With such a boot server defined, your DHCP configuration should look
the same except for an "option dhcp-class-identifier"(ISC dhcp 2) or
"option vendor-class-identifier"(ISC dhcp 3):

DHCP Config - Encapsulated

If the "conventional TFTP" configuration doesn't work on your clients,
and setting up a PXE boot server is not an option, you can attempt the
following configuration.
It has been known to boot some configurations correctly; however,
there are no guarantees:

Note: In earlier versions of PXELINUX,
this would only work as a "site-option-space".
Since PXELINUX 2.07, this will work both as a
"site-option-space" (unencapsulated) and as a
"vendor-option-space" (type 43 encapsulated.)
This may avoid messing with the
"dhcp-parameter-request-list", as detailed below.

[PXELINUX 2.07+] This is supported both as a
"site-option-space",
and as a "vendor-option-space".

Inside your PXELINUX-booting group or class (wherever you have the
PXELINUX-related options, such as the "filename" option), you would add,
for example:

Note that the configfile is relative to the pathprefix:
this will look for a config file called
/tftpboot/pxelinux/files/configs/common
on the TFTP server.

The "option dhcp-parameter-request-list"
statement forces the DHCP server to send the PXELINUX-specific options,
even though they are not explicitly requested.
Since the DHCP request is done before PXELINUX is loaded,
the PXE client won't know to request them.

In ISC dhcp versions greater than 3.0,
site-local option spaces start at 224, not 128
(to be compliant with RFC 3942),
so you should define the PXELINUX options 208-211
as regular DHCP options,
rather than site local ones. For example:

Note that the configfile is relative to the pathprefix:
this will look for a config file called
/tftpboot/pxelinux/files/configs/common
on the TFTP server.

The "option dhcp-parameter-request-list"
statement forces the DHCP server to send the PXELINUX-specific options,
even though they are not explicitly requested.
Since the DHCP request is done before PXELINUX is loaded,
the PXE client won't know to request them.

Using ISC dhcp 3.0 you can create a lot of these strings on the fly.
For example, to use the hexadecimal form of the hardware address as the
configuration file name,
you could do something like:

If you have additional problems, please contact the Syslinux mailing list.
Before you post something, please make sure you have checked that your
kernel files are not named using extensions that have special meanings:

Broken PXE stacks

Lots of PXE stacks, especially old ones,
have various problems of varying degrees of severity.
Please check out the Hardware Compatibility reference page for
possible workarounds.

PXE stack on a floppy

If your network card doesn't have a PXE boot ROM, there are a couple of
PXE stacks available.

Etherboot is a ROM kit that allows you to create your own PXE boot ROM
(version 5.3.7 or later required), as well as make one that can be run
from a boot floppy. The Etherboot home page is at:
http://www.etherboot.org/ ... and you can use ROM-o-matic to automatically create
customized boot ROMs for your needs. See:
http://rom-o-matic.net/

NetBoot is a ROM kit that may allow you to create your own PXE boot ROM,
and possibly also run one from a floppy. It is available at:
http://netboot.sourceforge.net/

A multi-hardware boot floppy is included with Windows Server 2000 and 2003.
A company called Argon Technology used to offer a free-as-in-beer
updated version, but it seems to have gone fully commercial.
This floppy (which can also be burned to a CD using El Torito in
floppy-emulation mode), is known to work with PXELINUX 2.03 or later only.

Deploy Linux from Windows WDS/RIS server using PXELinux

Note 1:
For this example we will use the Simple Menu System only,
but it is easy to modify the following procedure so to use
the vesamenu system or no menu.

Note 2:
For WDS, it is best to run it in Mixed Mode (makes life easier).
Alternatively, see WDSLINUX for setting it up with WDS only.

NOTE:
Setup\English\Images is the location of the other RIS images.
You can also change the name PXELinux to anything you want
if for example you wish to have a seperate option in RIS for each distro you deploy.

From Redhat AS4u3 CD1 (or cd of the distro you wish to deploy),
in the directory "images\pxeboot" copy the following files into
"Setup\English\Images\PXELinux\i386\templates" on the RIS server.

vmlinuz
initrd.img

Rename these files to:

vmlinuz-<distro>-<arch>
initrd-<distro>-<arch>.img

e.g.:

vmlinuz-rhas43-x86
initrd-rhas43-x86.img

Place the renamed "vmlinuz" file in the folder "\knl".
Place the renamed "initrd.img" file in the folder "\img".

NOTE:
You must use the files vmlinuz and initrd.img from the distro version
you intend to deploy (although sometimes you can get away with using
older or newer ones for older / newer versions).

From the Syslinux distribution file downloaded, extract the file
"pxelinux.0"
(and, since version 5.00, also extract the corresponding
"ldlinux.c32" file) to
"Setup\English\Images\PXELinux\i386\templates"
on the RIS server.

In "Setup\English\Images\PXELinux\i386\templates"
create a file "pxelinux.sif" and give it the following Contents:

Now if you Boot to your RIS server,
on the OS list screen you should see one called Linux.
Choosing this will boot PXELinux and take you to the main menu
to choose your arch type and then the distro you would like to install.

Using the new Syslinux features for vesamenu can make for a
very easy to use and pleasant interface.

Custom Menu Example with sub-menus

Many advanced options here.
Read full documentation on Syslinux to understand it all.

Its password protected from modification during PXE boot,
very useful to prevent tampering.

Note: this example uses the legacy way to generate submenus,
which is compatible with older Syslinux versions.
Syslinux 3.62 supports a slightly different syntax,
which is faster and somewhat more flexible.

Notes

Error recovery

If the boot fails, PXELINUX (unlike SYSLINUX) will not wait forever;
rather, if it has not received any input for approximately five minutes
after displaying an error message, it will reset the machine.
This allows an unattended machine to recover in case it had bad enough
luck of trying to boot at the same time the TFTP server goes down.

Please check out the Hardware Compatibility reference page
to see if your PXE stacks need any special workarounds.

MTFTP

PXELINUX does not support MTFTP, and there are no plans of doing so.
It is of course possible to use MTFTP for the initial boot,
if you have such a setup.
MTFTP server setup is beyond the scope of this document.

UEFI

The "(l)pxelinux.0" bootloaders are capable of netbooting
BIOS-based clients.
Hardware using UEFI has to use the adequate
"syslinux.efi"
(for EFI IA32 or for EFI X64, respectively)
instead of using "(l)pxelinux.0".

For example, in the dhcp configuration file, something similar
to the following conditions could be used:

The respective library modules for each firmware (if they are needed), cannot share the same directory between each other, since they have the same file name. Use individual configuration files for each architecture/firmware, and if necessary also add a relevant PATH directive in each of them.

The parent directory for the network bootloaders could be the same for all of them, if each bootloader is named differently. In such case, relevant PATH directives might be needed.

Optionally, use additional directives, such as INCLUDEand/orCONFIG, so to share in-common Syslinux configuration files.