http://syslinux.zytor.com/
{ PXELINUX Questions }
{ What is PXELINUX? }
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 do I Configure
PXELINUX? }
PXELINUX operates in many ways like SYSLINUX. If you are not familiar
with SYSLINUX, read the SYSLINUX FAQ first, since this documentation only explains the
differences.
On the TFTP server, create the directory "/tftpboot",
and copy pxelinux.0 (from the SYSLINUX distribution) and any kernel or
initrd images that you want to boot.
Finally, create the directory "/tftpboot/pxelinux.cfg". The configuration file (equivalent of syslinux.cfg -- see the SYSLINUX FAQ 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.
(See also the section on special DHCP options.)
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 63 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.
{ How Should I Setup my TFTP
server? }
PXELINUX currently requires that the boot server has a TFTP server which
supports the "tsize" TFTP option (RFC 1784/RFC 2349).
Also, please do check out the problematic hardware reference page to see if your PXE stacks need any special
workarounds.
Some TFTP servers which have been successfully used with PXELINUX
include:
The "tftp-hpa" TFTP server, a highly portable update and port
of the BSD TFTP server code 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/
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 runs Windows (and you can't fix that), try tftpd32
by Philippe Jounin:
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.
{ How Should I Setup My 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 togethergroup {
# PXE-specific configuration directives...next-server TFTP_server_address;
filename "/tftpboot/pxelinux.0";
# You need an entry like this for every host # unless you're using dynamic addresseshost hostname {
hardware ethernet ethernet_address; fixed-address hostname; } }
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.
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" ("option
vendor-class-identifier" if you are using ISC dhcp 3.0):
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 togethergroup {
# 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; } }
Here, the boot file name is obtained from the PXE server.
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 togethergroup {
# 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;
filename "/tftpboot/pxelinux.0";
# 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.
{ Can I send information to
PXELINUX via special options in the DHCP response? }
PXELINUX (starting with version 1.62) supports the following nonstandard
DHCP options, which depending on your DHCP server you may be able to use to
customize the specific behaviour of PXELINUX:
Option 208: pxelinux.magic
Must be set to F1:00:74:7E (241.0.116.126) for PXELINUX to recognize any
special DHCP options whatsoever.
Option 209: pxelinux.configfile
Specifies the PXELINUX configuration file name.
Option 210: pxelinux.pathprefix
Specifies 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
Specifies, in seconds, the time to wait before reboot in the event of TFTP
failure. 0 means wait "forever" (in reality, it waits approximately
136 years.)
ISC dhcp 3.0 supports a rather nice syntax for specifying custom options; you can
use the following syntax in dhcpd.conf if you are running this version of
dhcpd:
option space pxelinux; option pxelinux.magic code 208 = string; option pxelinux.configfile code 209 = text; option pxelinux.pathprefix code 210 = text; option pxelinux.reboottime code 211 = unsigned integer 32;
Then, inside your PXELINUX-booting group or class (whereever you have
the PXELINUX-related options, such as the filename option), you can add, for
example:
# Always include the following lines for all PXELINUX clients site-option-space "pxelinux"; option pxelinux.magic f1:00:74:7e; if exists dhcp-parameter-request-list { # Always send the PXELINUX options append dhcp-parameter-request-list 208, 209, 210, 211; } # These lines should be customized to your setup option pxelinux.configfile "configs/common"; option pxelinux.pathprefix "/tftpboot/pxelinux/files/"; option pxelinux.reboottime 30; filename "/tftpboot/pxelinux/pxelinux.bin";
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 "append dhcp-parameter-request-list" is an undocumented
(as of DHCP 3.0rc2pl1) option which forces the DHCP server to send the
PXELINUX-specific options, even though they are not explicitly requested.
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:
site-option-space "pxelinux"; option pxelinux.magic f1:00:74:7e; if exists dhcp-parameter-request-list { # Always send the PXELINUX options append dhcp-parameter-request-list 208, 209, 210, 211; } option pxelinux.configfile = concat("pxelinux.cfg/", binary-to-ascii(16, 8, ":", hardware)); filename "/tftpboot/pxelinux.bin";
If you used this from a client whose Ethernet address was
58:FA:84:CF:55:0E, this would look for a configuration file named
"/tftpboot/pxelinux.cfg/1:58:fa:84:cf:55:e".
{ What Happens When a Boot
Fails? }
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.
{ What Problems Are There
Currently With PXELINUX? }
·
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.
·
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.
{ MEMDISK documentation }
{ What is MEMDISK? }
MEMDISK is meant to allow booting legacy operating systems via PXE, and
as a workaround for BIOSes where ISOLINUX image support doesn't work.
MEMDISK simulates a disk by claiming a chunk of high memory for the disk
and a (very small - 2K typical) chunk of low (DOS) memory for the driver
itself, then hooking the INT 13h (disk driver) and INT 15h (memory query) BIOS
interrupts.
{ How can I use MEMDISK? }
MEMDISK is an auxillary module used in conjunction with one of the
SYSLINUX bootloaders, usually PXELINUX or ISOLINUX. You need a disk image as
well as the memdisk file itself. As far as the bootloader is concerned, memdisk is the
"kernel" and disk image is the initial ramdisk (initrd).
You can use MEMDISK straight off the boot loader command line like the
following:
memdisk initrd=diskimg.img
... where, of course, diskimg.img is the name of the disk image file. The memdisk file and
the disk image need to be present in the appropriate location (for PXELINUX, on
your TFTP server, for ISOLINUX, in the /isolinux directory on your CD, etc.)
Normally, however, you would put something like following in the
configuration file:
label dos kernel memdisk append initrd=dosboot.img
{ How should the image be
constructed? }
The image file should contain a disk image, either a floppy disk or hard
disk image. The disk image should not be compressed.
If the disk image is one of the following sizes, it's assumed to be a
floppy image:
|
368,640
bytes |
360K floppy (old 5.25") |
|
737,280
bytes |
720K floppy (old 3.5") |
|
1,222,800
bytes |
1200K floppy (standard 5.25") |
|
1,474,560
bytes |
1440K floppy (standard 3.5") |
|
2,949,120
bytes |
2880K floppy (enhanced 3.5") |
For any other size, the image is assumed to be a hard disk image, and
should have an MBR and a partition table. The C/H/S geometry is determined by
examining the partition table, so the image does need to contain a valid
partition table which convers the entirety of the image for proper operation.
It is also possible to specify the geometry manually, overriding the autodetect
feature, by specifying the following command-line options:
|
|
Specify the number of cylinders (max 1024[*])
|
|
|
Specify the number of heads (max 256[*]) |
|
|
Specify the number of sectors (max 63) |
|
|
The image is a floppy disk image |
|
|
The image is a hard disk image |
[*] MS-DOS only allows max 255 heads, and only allows 255 cylinders on
floppy disks.
{ Additional notes }
To recompile MEMDISK from sources, you will need to make sure that you
have a fairly recent binutils installed. I have been using binutils-2.11.90.0.8
in the form of the binutils-2.11.90.0.8-9 RPM from RedHat 7.2.
{ SYSLINUX Questions }
{ What is SYSLINUX? }
SYSLINUX is a boot loader for the Linux operating system which operates
off an MS-DOS/Windows FAT filesystem. It is intended to simplify first-time
installation of Linux, and for creation of rescue- and other special-purpose
boot disks.
SYSLINUX can be used, when properly set up, to completely eliminate the
need for distribution of raw diskette images for boot floppies. A SYSLINUX
floppy can be manipulated using standard MS-DOS (or any other OS that can
access an MS-DOS filesystem) tools once it has been created.
{ What SYSLINUX is Not... }
SYSLINUX is probably not suitable as a general purpose boot loader. It
can only boot Linux from a FAT filesystem, and not, for example, ext2. Since a
native Linux implementation will typically use ext2, another boot loader (e.g.
LILO) is probably more suitable. In a system which actually contains DOS or Windows,
LOADLIN may be simpler to use.
However, SYSLINUX has shown itself to be quite useful in a number of
special-purpose applications.
{ How do I Create a Bootable
Floppy? }
In order to create a bootable Linux floppy using SYSLINUX, prepare a
normal MS-DOS formatted floppy. Copy one or more Linux kernel files to it, then
execute the DOS command:
syslinux
[-s] a:
(or whichever drive letter is appropriate; the [] meaning -s is
optional)
If you're running in a Win95/98/ME DOS box, you should execute the
command lock a: first. If you're running in a WinNT/2K DOS box, you
will probably get a dialog box about not getting exclusive access and with
Abort/Retry/Ignore buttons; people have reported that selecting
"Ignore" makes the command complete correctly.
Under Linux, execute the command:
syslinux
[-s] [-o offset] /dev/fd0
(or, again, whichever device is the correct one.)
This will alter the boot sector on the disk and copy a file named
LDLINUX.SYS into its root directory.
The -s option, if given, will install a "safe, slow and stupid"
version of SYSLINUX. This version may work on some very buggy BIOSes on which
SYSLINUX would otherwise fail. If you find a machine on which the -soption is required to make it
boot reliably, please send as much info about your machine as you can, and
include the failure mode.
The -o option is used with a disk image file and specifies the byte offset of
the filesystem image in the file.
On boot time, by default, the kernel will be loaded from the image named
LINUX on the boot floppy. This default can be changed, see the section on the
SYSLINUX config file.
If the Shift or Alt keys are held down during boot, or the Caps or
Scroll locks are set, SYSLINUX will display a LILO-style "boot:"
prompt. The user can then type a kernel file name followed by any kernel
parameters. The SYSLINUX loader does not need to know about the kernel file in
advance; all that is required is that it is a file located in the root
directory on the disk.
{ How do I Configure
SYSLINUX? }
All the configurable defaults in SYSLINUX can be changed by putting a
file called SYSLINUX.CFG in the root directory of the boot floppy. This is a
text file in either UNIX or DOS format, containing one or more of the following
items (case is insensitive for keywords; upper case is used here to indicate
that a word should be typed verbatim):
All options here applies to PXELINUX as well as SYSLINUX unless
otherwise noted. See pxelinux.doc for additional information on PXELINUX.
DEFAULT kernel options...
Sets the default command line. If SYSLINUX boots automatically, it will
act just as if the entries after DEFAULT had been typed in at the
"boot:" prompt, except that the option "auto" is
automatically added, indicating an automatic boot.
If no configuration file is present, or no DEFAULT entry is present in
the config file, the default is kernel name "linux", with no options.
APPEND options...
Add one or more options to the kernel command line. These are added both
for automatic and manual boots. The options are added at the very beginning of
the kernel command line, usually permitting explicitly entered kernel options
to override them. This is the equivalent of the LILO "append" option.
IPAPPEND flag_val [PXELINUX only]
The IPAPPEND option is available only on PXELINUX, and indicates (if the
flag value is 1) that an option of the following format should be generated and
added:
ip=<client-ip>:<boot-server-ip>:<gw-ip>:<netmask>
... based on the input from the DHCP/BOOTP or PXE boot server.
LABEL label
KERNEL image
APPEND options...
IPAPPEND flag_val [PXELINUX only]