summaryrefslogtreecommitdiff
path: root/pxelinux.doc
blob: e6baa81ba43f18cc0f66fb1e7f3265619b70969e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
                               PXELINUX

    A bootloader for Linux using the PXE network booting protocol

		Copyright (C) 1994-2001 H. Peter Anvin

This program is provided under the terms of the GNU General Public
License, version 2 or, at your option, any later version.  There is no
warranty, neither expressed nor implied, to the function of this
program.  Please see the included file COPYING for details.

----------------------------------------------------------------------

PXELINUX is a SYSLINUX derivative, for booting Linux off a network
server, using a network ROM conforming to the Intel PXE (Pre-Execution
Environment) specification.  PXELINUX is *not* a program that is
intended to be flashed or burned into a PROM on the network card; if
you want that, check out NILO (http://www.nilo.org/).  NILO can also
be used to create a PXE-compliant boot PROM for most network cards
which have drivers for Linux or FreeBSD.


    ++++ HOW TO CONFIGURE PXELINUX ++++

PXELINUX operates in many ways like SYSLINUX.  If you are not familiar
with SYSLINUX, read syslinux.doc first, since this documentation only
explains the differences.

On the TFTP server, create the directory "/tftpboot", and copy the
following files to it:

	pxelinux.0		- from the SYSLINUX distribution

	any kernel or initrd images you want to boot

Finally, create the directory "/tftpboot/pxelinux.cfg".  The
configuration file (equivalent of syslinux.cfg -- see syslinux.doc for
the options here) will live in this directory.  Because more than one
system may be booted from the same server, the configuration file name
depends on the IP address of the booting machine.  PXELINUX will
search for its config file on the boot server in the following way:

  First, it will search for the config file using its own IP address
  in upper case hexadecimal, e.g. 192.0.2.91 -> C000025B
  (you can use the included progam "gethostip" to compute the
  hexadecimal IP address for any host.)

  If that file is not found, it will remove one hex digit and try
  again.  Ultimately, it will try looking for a file named "default"
  (in lower case).

  As an example, for 192.0.2.91, it will try C000025B, C000025,
  C00002, C0000, C000, C00, C0, C, and default, in that order.

It should be noted that all filename references are relative to the
directory pxelinux.0 lives in (usually /tftpboot).  PXELINUX
generally requires that filenames (including any relative path) are 31
characters or shorter in length.

PXELINUX does not support MTFTP, and I have no immediate 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.


    ++++ SETTING UP THE TFTP SERVER ++++

PXELINUX currently requires that the boot server has a TFTP server
which supports the "tsize" TFTP option (RFC 1784/RFC 2349).  The
"tftp-hpa" TFTP server, which support options, is available at:

	http://www.kernel.org/pub/software/network/tftp/
	ftp://www.kernel.org/pub/software/network/tftp/

... and on any kernel.org mirror (see http://www.kernel.org/mirrors/).

Another TFTP server which supports this is atftp by Jean-Pierre
Lefebvre:

	ftp://ftp.mamalinux.com/pub/atftp/

Unfortunately, the Intel LANDesk Service Agent II prior to version
0.99h (PXE PDK V2.4) seems to have a host of serious bugs.  Among
other things, it requests the TFTP "blksize" option, but will be
mortally confused if this option is actually accepted by the server!
There are three possible workarounds for this bug:

1. Use a TFTP server with doesn't support "blksize".

   Unfortunately, PXELINUX requires the "tsize" option to be
   supported, and it is very unusual for TFTP servers to implement one
   and not the other.  Both the tftp-hpa and atftp TFTP servers (see
   above) therefore can be configured to disable the blksize option.
   Use "-r blksize" for tftp-hpa, "--no-blksize" for atftp.

2. Use MTFTP for the initial bootstrap.  You need an MTFTP server with
   the appropriate DHCP setup to do this.

3. Use appropriate DHCP options that the client will attempt MTFTP
   before trying conventional TFTP.  It seems that the client will not
   request the "blksize" option if it has tried MTFTP and failed.
   These DHCP options are beyond the scope of this document.

These systems also seem to break if PMTU discovery is enabled on the
TFTP server.  This has to be disabled in the kernel on the TFTP
server.  On Linux, you can disable PMTU discovery by setting:

	echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

Note that this may cause bad performance for other services on the machine.


    ++++ SETTING UP THE DHCP SERVER ++++

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 dhcpd.conf
syntax:

        allow booting;
        allow bootp;

	# Standard configuration directives...

        option domain-name "<domain name>";
        option subnet-mask <subnet mask>;
        option broadcast-address <broadcast address>;
        option domain-name-servers <dns servers>;
        option routers <default router>;

	# Group the PXE bootable hosts together
	group {
		# PXE-specific configuration directives...
		next-server <TFTP server address>;

		# You need an entry like this for every host
		# unless you're using dynamic addresses
	        host <hostname> {
        	        hardware ethernet <ethernet address>;
               		fixed-address <hostname>;
        	}
	}

If this does not work for your configuration, 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":

        allow booting;
        allow bootp;

	# Standard configuration directives...

        option domain-name "<domain name>";
        option subnet-mask <subnet mask>;
        option broadcast-address <broadcast address>;
        option domain-name-servers <dns servers>;
        option routers <default router>;

	# Group the PXE bootable hosts together
	group {
		# PXE-specific configuration directives...
	        option dhcp-class-identifier "PXEClient";
		next-server <pxe boot server address>;

		# You need an entry like this for every host
		# unless you're using dynamic addresses
	        host <hostname> {
        	        hardware ethernet <ethernet address>;
               		fixed-address <hostname>;
        	}
	}

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:

        allow booting;
        allow bootp;

	# Standard configuration directives...

        option domain-name "<domain name>";
        option subnet-mask <subnet mask>;
        option broadcast-address <broadcast address>;
        option domain-name-servers <dns servers>;
        option routers <default router>;

	# Group the PXE bootable hosts together
	group {
		# PXE-specific configuration directives...
	        option dhcp-class-identifier "PXEClient";
		option vendor-encapsulated-options 09:0f:80:00:0c:4e:65:74:77:6f:72:6b:20:62:6f:6f:74:0a:07:00:50:72:6f:6d:70:74:06:01:02:08:03:80:00:00:47:04:80:00:00:00:ff;
		next-server <TFTP server>;

		# You need an entry like this for every host
		# unless you're using dynamic addresses
	        host <hostname> {
        	        hardware ethernet <ethernet address>;
               		fixed-address <hostname>;
        	}
	}

Note that this *will not* boot some clients that *will* boot with the
"conventional TFTP" configuration; Intel Boot Client 3.0 and later are
known to fall into this category.

Note that if your particular TFTP daemon runs under chroot (tftp-hpa
will do this if you specify the -s (secure) option; this is
recommended), you most likely should not include the /tftpboot prefix.


    ++++ SOME NOTES ++++

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.


    ++++ CURRENTLY KNOWN PROBLEMS ++++

The following problems are known with PXELINUX, so far:

+ Requires a TFTP server which supports the "tsize" option.
+ The error recovery routine doesn't work quite right.  For right now,
  it just does a hard reset - seems good enough.
+ There may be funnies with memory management.  The PXE spec has no
  decent way of telling it to free up all memory and unchain any
  interrupts; it allows the base stack to be unloaded, but not the
  UNDI driver.
+ There seems to be a problem with sending ACK "storms"; a number of
  ACK packets fired off without the proper delay in between.  I
  suspect this is a PXE firmware problem, rather than a PXELINUX
  problem.
+ We should probably call the UDP receive function in the keyboard
  entry loop, so that we answer ARP requests.
+ Boot sectors don't work yet... they probably need auxilliary information
  (such as device) to work at all.

If you have additional problems, please contact the SYSLINUX mailing
list (see syslinux.doc for the address.)