Then, it'll use that ISO to create a bootable media, which you can then use to install Windows 10 on devices using UEFI. Now that you have a USB bootable media with support for UEFI, you can start.
Contents.BIOS Systems Boot process overview. Stage 1: Part 1 - Load MBR - At boot, the BIOS loads the 440 byte boot code at the start of the disk ( /usr/lib/syslinux/bios/mbr.bin or /usr/lib/syslinux/bios/gptmbr.bin). Stage 1: Part 2 - Search active partition.
The Stage 1 MBR boot code looks for the partition that is marked as active (boot flag in MBR disks). Let us assume this is the /boot partition, for example. Stage 2: Part 1 - Execute volume boot record - The Stage 1 MBR boot code executes the Volume Boot Record (VBR) of the /boot partition.
In the case of Syslinux, the VBR boot code is the starting sector of /boot/syslinux/ldlinux.sys which is created by the extlinux -install command. Note that ldlinux.sys is not the same as ldlinux.c32. Stage 2: Part 2 - Execute /boot/syslinux/ldlinux.sys - The VBR will load the rest of /boot/syslinux/ldlinux.sys. The sector location of /boot/syslinux/ldlinux.sys should not change, otherwise syslinux will not boot. Note: In the case of, the above method will not work since files move around resulting in changing of the sector location of ldlinux.sys.
Therefore, in Btrfs the entire ldlinux.sys code is embedded in the space following the VBR and is not installed at /boot/syslinux/ldlinux.sys unlike the case of other filesystems. Stage 3 - Load /boot/syslinux/ldlinux.c32 - The /boot/syslinux/ldlinux.sys will load the /boot/syslinux/ldlinux.c32 (core module) that contains the rest of the core part of syslinux that could not be fit into ldlinux.sys (due to file-size constraints). The ldlinux.c32 file should be present in every Syslinux installation and should match the version of ldlinux.sys installed in the partition. Otherwise Syslinux will fail to boot.
See for more info. Stage 4 - Search and Load configuration file - Once Syslinux is fully loaded, it looks for /boot/syslinux/syslinux.cfg (or /boot/syslinux/extlinux.conf in some cases) and loads it if it is found. If no configuration file is found, you will be dropped to a Syslinux boot: prompt. This step and the rest of non-core parts of Syslinux ( /boot/syslinux/.c32 modules, excluding lib.c32 and ldlinux.c32) require /boot/syslinux/lib.c32 (library) modules to be present.
The lib.c32 library modules and non-core.c32 modules should match the version of ldlinux.sys installed in the partition.Installation on BIOSthe package. Warning: The syslinux-installupdate script sets a default root partition that possibly will not match your particular system.
It is important to point Syslinux to the correct root partition by editing /boot/syslinux/syslinux.cfg, or the OS will fail to boot. See.The syslinux-installupdate script will install the bootloader code (usually to the VBR), copy.c32 modules to /boot/syslinux/, set the boot flag and install the boot code in the MBR. It can handle and disks along with software RAID:If you use a separate boot partition, make sure that it is mounted. Note: If you are trying to rescue an installed system with a live CD, be sure to into it before executing these commands.
If you do not chroot first, you must prepend all file paths (not /dev/ paths) with the mount point.Your boot partition, on which you plan to install Syslinux, must contain a FAT, ext2, ext3, ext4, or Btrfs file system. You do not have to install it on the root directory of a file system, e.g., with device /dev/sda1 mounted on /boot. For example, you can install Syslinux in the syslinux subdirectory:# mkdir /boot/syslinuxCopy all.c32 files from /usr/lib/syslinux/bios/ to /boot/syslinux/ if you desire to use any menus or configurations other than a basic boot prompt. Do not symlink them.# cp /usr/lib/syslinux/bios/.c32 /boot/syslinux/Now install the bootloader.
For FAT, ext2/3/4, or btrfs boot partition use extlinux, where the device has been mounted:# extlinux -install /boot/syslinuxAlternatively, for a FAT boot partition use syslinux, where the device is unmounted:# syslinux -directory syslinux -install /dev/sda1After this, proceed to install the Syslinux bootstrap code appropriate for the partition table:. mbr.bin will be installed for an, or. gptmbr.bin will be installed for aas described in the next sections.See for further general information. Note: For a partitionless install, there is no need to install the Syslinux boot code to the MBR. You could skip below and jump to. MBR partition tableFor an, ensure your boot partition is marked as 'active' in your partition table (the 'boot' flag is set).
Applications capable of doing this include. It should look like this:# fdisk -l /dev/sda.Device Boot Start End Blocks Id System/dev/sda1. 2048 10 83 Linux/dev/sda2 119000 83 LinuxInstall the MBR:# dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/bios/mbr.bin of=/dev/sdaAn alternative MBR which Syslinux provides is: altmbr.bin. This MBR does not scan for bootable partitions; instead, the last byte of the MBR is set to a value indicating which partition to boot from. Here is an example of how altmbr.bin can be copied into position:# printf 'x5' cat /usr/lib/syslinux/bios/altmbr.bin - dd bs=440 count=1 iflag=fullblock of=/dev/sdaIn this case, a single byte of value 5 (hexadecimal) is appended to the contents of altmbr.bin and the resulting 440 bytes are written to the MBR on device sda. Syslinux was installed on the first logical partition ( /dev/sda5) of the disk.GUID partition tableFor a, ensure that attribute bit 2 'Legacy BIOS bootable' is set for the /boot partition.
For it can be set using the 'legacyboot' flag. Using the command to set the attribute is:# sgdisk /dev/sda -attributes=1:set:2This will set the attribute 'legacy BIOS bootable' on partition 1 of /dev/sda. To check:# sgdisk /dev/sda -attributes=1:show 1:2:1 (legacy BIOS bootable)Install the MBR:# dd bs=440 count=1 conv=notrunc if=/usr/lib/syslinux/bios/gptmbr.bin of=/dev/sdaUEFI Systems. Note:.
efi64 denotes x8664 UEFI systems, for IA32 (32-bit) EFI replace efi64 with efi32 in the below commands. For Syslinux, the kernel and initramfs files need to be in the (aka ESP), as Syslinux does not (currently) have the ability to access files outside its own partition (i.e. Outside ESP in this case). For this reason, it is recommended to mount ESP at /boot. The automatic install script /usr/bin/syslinux-installupdate does not support UEFI install. The configuration syntax of syslinux.cfg for UEFI is same as that of BIOS.Limitations of UEFI Syslinux.
UEFI Syslinux application syslinux.efi cannot be signed by sbsign (from ) for UEFI Secure Boot. Bug report:. Using TAB to edit kernel parameters in UEFI Syslinux menu might lead to garbaged display (text on top of one another). Bug report:. UEFI Syslinux does not support chainloading other EFI applications like UEFI Shell or Windows Boot Manager. Enhancement request:. In some cases, UEFI Syslinux might not boot in some Virtual Machines like /OVMF or or some products/versions and in some UEFI emulation environments like DUET.
A Syslinux contributor has confirmed no such issues present on VMware Workstation 10.0.2 and Syslinux-6.02 or later. Bug reports:, and. Memdisk is not available for UEFI. Enhancement request:Installation on UEFI. Note: In the commands related to UEFI, esp denotes the mountpoint of the aka ESP. Install the and packages from the.
Then setup Syslinux in the ESP as follows:. Copy Syslinux files to ESP:# mkdir -p esp/EFI/syslinux# cp -r /usr/lib/syslinux/efi64/.
esp/EFI/syslinux. Setup boot entry for Syslinux using:# efibootmgr -create -disk /dev/sdX -part Y -loader /EFI/syslinux/syslinux.efi -label 'Syslinux' -verbosewhere /dev/sdXY is the partition containing the bootloader. Create or edit esp/EFI/syslinux/syslinux.cfg by following. Note:. The config file for UEFI is esp/EFI/syslinux/syslinux.cfg, not /boot/syslinux/syslinux.cfg. Files in /boot/syslinux/ are BIOS specific and not related to UEFI Syslinux. When booted in BIOS mode, will not be able to set EFI nvram entry for /EFI/syslinux/syslinux.efi.
To work around, place resources at the default EFI location: esp/EFI/syslinux/. esp/EFI/BOOT/. and esp/EFI/syslinux/syslinux.efi - esp/EFI/BOOT/bootx64.efiConfigurationThe Syslinux configuration file, syslinux.cfg, should be created in the same directory where you installed Syslinux. In our case, /boot/syslinux/ for BIOS systems and esp/EFI/syslinux/ for UEFI systems.The bootloader will look for either syslinux.cfg (preferred) or extlinux.conf. Note: If you are using, make sure to copy from /usr/lib/syslinux/efi64/ (or efi32 for IA32 (32-bit) EFI systems), otherwise you will be presented with a black screen. In that case, boot from a live medium and use to make the appropriate changes.This configuration uses the same menu design as the Arch Install CD, its config can be found at.
The can be downloaded from there, too. Note: For Windows, this skips the system's own boot manager ( bootmgr), which is required for a few important updates to complete. In such cases it may be advisable to temporarily set the MBR boot flag to the Windows partition (eg. With ), let the update finish installing, and then reset the flag to the Syslinux partition (eg. With Windows's own ). Chainloading a disk's MBRIf you are unsure about which drive your BIOS thinks is 'first', you can instead use the MBR identifier, or if you are using GPT, the filesystem labels. To use the MBR identifier, run the command# fdisk -l /dev/sdb Disk /dev/sdb: 128.0 GB, 60 bytes255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectorsUnits = sectors of 1.
512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0xf00f1fd3Device Boot Start End Blocks Id System/dev/sdb1 20 2097152 7 HPFS/NTFS/exFAT/dev/sdb2 4135296 7 HPFS/NTFS/exFATreplacing /dev/sdb with the drive you wish to chainload. Using the hexadecimal number under Disk identifier: 0xf00f1fd3 in this case, the syntax in syslinux.cfg is/boot/syslinux/syslinux.cfg.LABEL windowsMENU LABEL WindowsCOM32 chain.c32APPEND mbr:0xf00f1fd3.For more details about chainloading, see.Chainloading other boot loadersIf you have installed on the same partition, you can chainload it by using:/boot/syslinux/syslinux.cfg.LABEL grub2MENU LABEL Grub2COM32 chain.c32APPEND file=./grub/boot.img.Alternatively, it is also possible to load as a linux kernel by prepending lnxboot.img to core.img. The file lnxboot.img is part of core/grub and can be found in /usr/lib/grub/i386-pc./boot/syslinux/syslinux.cfg.LABEL grub2lnxMENU LABEL Grub2 (lnxboot)LINUX./grub/i386-pc/lnxboot.imgINITRD./grub/i386-pc/core.img.This may be required for booting from ISO images.Chainloading other Linux systems. Reason: Among other inaccuracies.
1 There is no obligation to install yet another boot loader if you already have one related to the other partition/OS (e.g. GRUB2 installed in the MBR or in the VBR of the partition being chainloaded to). 2 Syslinux (in any of its derivatives) is never 'installed to the MBR', so mentioning the MBR in this section without any explanation of what it is being meant or how to do it in practical terms is just adding confusion. 3 Typos and misspelling. 4No need to explain (yet again) how to install some (other) bootloader to some (other) partition / OS; just how to chainload from Syslinux to that other partition / bootloader / OS. (Discuss in )Chainloading another bootloader such as Windows' is pretty obvious, as there is a definite bootloader to chain to. But with Syslinux, it is only able to load files residing on the same partition as the configuration file.
Thus, if you have another version of Linux on a separate partition, without a shared /boot, it becomes necessary to employ EXTLINUX rather than the other OS's default bootloader (eg. Essentially, EXTLINUX can be installed on the partition superblock/ and be called as a separate bootloader right from the MBR installed by Syslinux. EXTLINUX is part of The Syslinux Project and is included with the package.The following instructions assume you have Syslinux installed already. These instructions will also assume that the typical Arch Linux configuration path of /boot/syslinux is being used and the chainloaded system's / is on /dev/sda3.From a booted Linux (likely the partition that Syslinux is set up to boot), mount the other system's root partition to your desired mount point. In this example this will be /mnt.
Also, if a separate /boot partition is used on the second operating system, that will also need to be mounted. The example assumes this is /dev/sda2.# mount /dev/sda3 /mnt# mount /dev/sda2 /mnt/boot (only necessary for separate /boot)Install EXTLINUX to the partition VBR, and copy necessary.c32 files# extlinux -i /mnt/boot/syslinux/ (first create the directory if necessary)# cp /usr/lib/syslinux/bios/.c32 /mnt/boot/syslinuxCreate /mnt/boot/syslinux/syslinux.cfg. You can use the other Linux's bootloader menu file for reference. Below is an example:/mnt/boot/syslinux/syslinux.cfg on /dev/sda3 TIMEOUT 10UI menu.c32LABEL OtherLinuxLINUX /boot/vmlinuz-linuxINITRD /boot/initramfs-linux.imgAPPEND root=/dev/sda3 rw quietLABEL MAINCOM32 chain.c32APPEND hd0 0And then add an entry to your main syslinux.cfg/boot/syslinux/syslinux.cfg LABEL OtherLinuxCOM32 chain.c32APPEND hd0 3Note that the other Linux entry in /boot/syslinux/syslinux.cfg will need to be edited each time you update this OS's kernel unless it has symlinks to its latest kernel and initrd in /. Since we are booting the kernel directly and not chainloading the other-OS's default bootloader.Using memtestInstall from the.Use this LABEL section to launch:/boot/syslinux/syslinux.cfg.LABEL memtestMENU LABEL Memtest86+LINUX./memtest86+/memtest.bin. Note: If you are using PXELINUX, change the name from memtest.bin to memtest since PXELINUX treats the file with.bin extension as a boot sector and loads only 2KB of it. HDTdisplays hardware information.
Like before, the.c32 file has to be copied from /boot/syslinux/. Additional lib.c32 library modules might be needed too.For PCI info, copy /usr/share/hwdata/pci.ids to /boot/syslinux/pci.ids and add the following to your configuration file:/boot/syslinux/syslinux.cfg LABEL hdtMENU LABEL Hardware InfoCOM32 hdt.c32Reboot and power off. Note: As of Syslinux 6.03, poweroff.c32 only works with APM and not with ACPI. For a possible solution, see.Use the following sections to reboot or power off your machine:/boot/syslinux/syslinux.cfg LABEL rebootMENU LABEL RebootCOM32 reboot.c32LABEL poweroffMENU LABEL Power OffCOM32 poweroff.c32Clear menuTo clear the screen when exiting the menu, add the following line:/boot/syslinux/syslinux.cfg MENU CLEARKeyboard layoutIf you often have to edit your boot command with diverse parameters in the Syslinux boot prompt, then you might want to remap your keyboard layout.
This allows you to enter '=', '/' and other characters easily on a non-US keyboard. Note: keytab-lilo, which is included in the package, is a perl script invoking the loadkeys program.To create a compatible keymap (e.g. A german one) run:# keytab-lilo /usr/share/kbd/keymaps/i386/qwerty/us.map.gz /usr/share/kbd/keymaps/i386/qwertz/de.map.gz /boot/syslinux/de.ktlNow edit syslinux.cfg and add:/boot/syslinux/syslinux.cfg KBDMAP de.ktlSee the for more details.Hiding the menuUse the option:/boot/syslinux/syslinux.cfg MENU HIDDENto hide the menu while displaying only the timeout. Press any key to bring up the menu.PXELINUX. Note: You will need to change nbdhost and/or nfsroot, respectively, to match your network configuration (the address of the NFS/NBD server)PXELINUX uses the same configuration syntax as SYSLINUX; refer to the upstream documentation for more information.The kernel and initramfs will be transferred via TFTP, so the paths to those are going to be relative to the TFTP root.
Otherwise, the root filesystem is going to be the NFS mount itself, so those are relative to the root of the NFS server.To actually load PXELINUX, replace filename '/grub/i386-pc/core.0'; in /etc/dhcpd.conf with filename '/pxelinux.0' (or with filename '/lpxelinux.0').Booting ISO9660 image files with memdiskSyslinux supports booting from ISO images directly using the module, see for examples.Serial consoleSee.Boot another OS onceIt is possible to temporarily change the default Syslinux action and boot another label only during the next boot. The following command shows how to boot the archfallback label once:# extlinux -o archfallback /boot/syslinuxDuring the next boot, the specified label will be booted without any Syslinux prompt showing up.
The default Syslinux boot behaviour will be restored on the next reboot.Troubleshooting Failed to load ldlinuxAn error message such as 'Failed to load ldlinux.c32' during the initial boot can be triggered by many diverse reasons.One potential reason could be a change in file system tools or in a file system structure, depending on its own version. Note: There is no direct and unique correspondence between a message such as Failed to load ldlinux.c32 and a problem related to the file system:.
Other alternative symptoms, instead of this message, could also indicate a problem related to the file system. The message does not necessarily mean that the problem is related to the file system; there are other possible reasons for this type of messages.See also (the whole page might be relevant for troubleshooting too).Using the Syslinux promptYou can type in the LABEL name of the entry that you want to boot (as per your syslinux.cfg). If you used the example configurations, just type:boot: archIf you get an error that the configuration file could not be loaded, you can pass your needed boot parameters, e.g.:boot:./vmlinuz-linux root=/dev/sda2 rw initrd=./initramfs-linux.imgIf you do not have access to boot: in, and therefore temporarily unable to boot the kernel again,1. Create a temporary directory, in order to mount your root partition (if it does not exist already): # mkdir -p /newroot2. Mount / under /newroot (in case /boot/ is on the same partition, otherwise you will need to mount them both). Note: Busybox cannot mount /boot if it is on its own ext2 partition. # mount /dev/sda-z1-9 /newroot3.
Use vim and edit syslinux.cfg again to suit your needs and save file. Fsck fails on root partitionIn the case of a badly corrupted root partition (in which the journal is damaged), in the ramfs emergency shell, mount the root file system:# mount /dev/ root partition /newrootAnd grab the tune2fs binary from the root partition (it is not included in Syslinux):# cp /newroot/sbin/tune2fs /sbin/Follow the instructions at to create a new journal for the root partition.No Default or UI found on some computersCertain motherboard manufacturers have less compatibility for booting from USB devices than others. While an ext4 formatted USB drive may boot on a more recent computer, some computers may hang if the boot partition containing the kernel and initrd are not on a FAT16 partition.
To prevent an older machine from loading ldlinux and failing to read syslinux.cfg, create a partition (≤ 2 GB) and format to using:# mkfs.fat -F 16 /dev/sda1then install and configure Syslinux.Missing operating system. Check that you have installed gptmbr.bin for GPT and mbr.bin for MBR partition table.
A 'Missing operating system' message comes from mbr.bin while gptmbr.bin would show a 'Missing OS' message. Check whether the partition that contains /boot has the 'boot' flag enabled.
Check whether the first partition at the boot device starts at sector 1 rather than sector 63 or 2048. Check this with fdisk -l. If it starts at sector 1, you can move the partition(s) with gparted from a rescue disk. Or, if you have a separate boot partition, you can back up /boot with# cp -a /boot /boot.bakand then boot up with the Arch install disk. Next, use cfdisk to delete the /boot partition, and recreate it.
This time it should begin at the proper sector, 63. Now mount your partitions and chroot into your mounted system, as described in the. Restore /boot with the command# cp -a /boot.bak/ /boot/Check if /etc/fstab is correct, run:# syslinux-installupdate -iamand reboot.You will also get this error if you are trying to boot from a md 1 array and created the array with a too new version of the metadata that Syslinux does not understand. As of August 2013 by default mdadm will create an array with version 1.2 metadata, but Syslinux does not understand metadata newer than 1.0. If this is the case you will need to recreate your array using the -metadata=1.0 flag to mdadm.Windows boots up, ignoring SyslinuxSolution: Make sure the partition that contains /boot has the boot flag enabled.
Also, make sure the boot flag is not enabled on the Windows partition. See the above.The MBR that comes with Syslinux looks for the first active partition that has the boot flag set. The Windows partition was likely found first and had the boot flag set. If you wanted, you could use the MBR that Windows or MS-DOS fdisk provides.Menu entries do nothingYou select a menu entry and it does nothing, it just 'refreshes' the menu. This usually means that you have an error in your syslinux.cfg file.
Hit Tab to edit your boot parameters. Alternatively, press Esc and type in the LABEL of your boot entry (e.g. Another cause could be that you do not have a kernel installed.
Find a way to access your file system (through live CD, etc) and make sure that /mount/vmlinuz-linux exists and does not have a size of 0. If this is the case, reinstall your kernel.Cannot remove ldlinux.sysThe ldlinux.sys file has the set, which prevents it from being deleted or overwritten. This is because the sector location of the file must not change or else Syslinux has to be reinstalled.
To remove it, run:# chattr -i /boot/syslinux/ldlinux.sys# rm /boot/syslinux/ldlinux.sysWhite block in upper left corner when using vesamenuProblem:As of linux-3.0, the modesetting driver tries to keep the current contents of the screen after changing the resolution (at least it does so with my Intel, when having Syslinux in text mode).
- 4Options
- 8Examples
- 8.6DHCP Config - ISC dhcpd options
- 9Known issues
- 13Notes
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.
All unqualified filenames are relative to the Current Working Directory.
Configuration
The basic configuration is the same for all Syslinux variants. This document explains only some of the differences specifically applicable to PXELINUX.
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.
[5.00+] Also copy 'ldlinux.c32' from the Syslinux distribution to the '/tftpboot' directory on the TFTP server.
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.
Before a generic explanation, let's see first an example. When:
- the bootloader file name is '/mybootdir/pxelinux.0'; and,
- the client UUID is 'b8945908-d6a6-41a9-611d-74a6ab80b83d'; and,
- the Ethernet MAC address is '88:99:AA:BB:CC:DD'; and,
- the IP address is '192.168.2.91', or in uppercase hexadecimal, 'C0A8025B';
then PXELINUX will try the following configuration files (in this order):
Let's see now what exactly the above example represents.
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 as 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
Hardcoded 'after-options' are applied after DHCP options (and override them) while hardcoded 'before-options' are applied prior to DHCP options. The default behavior takes the lowest 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.
Hardcoded options:
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!
Example:
Filename syntax
PXELINUX supports the following special pathname conventions:
- ::filename
- 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):
TFTP servers
For best results, use a TFTP server with support for the 'tsize' TFTP option (RFC 1784/RFC 2349).
Please check out the Hardware Compatibility reference page to see if your PXE stacks need any special workarounds.
Some TFTP servers that have been successfully used with PXELINUX include:
- The 'tftp-hpa' TFTP server (highly portable and port of the BSD TFTP server code) supports options and is available at:
http://www.kernel.org/pub/software/network/tftp/ or ftp://ftp.kernel.org/pub/software/network/tftp/
- and on any kernel.org mirror (http://www.kernel.org/mirrors/).
- Another TFTP server supporting options is 'atftp' by Jean-Pierre Lefebvre:
- 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
In the Parameters folder, add a key called
In the registry, add the folder
HKLMSystemCurrentControlSetServicesTFTPDParameters
. 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): Here, the boot file name is obtained from the PXE server.
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 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.
DHCP Config - ISC dhcpd options
ISC dhcp 3.0 supports a rather nice syntax for specifying custom options. The following syntax can be used in 'dhcpd.conf' if you are running this version of dhcpd:
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:
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.
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 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'.
vendor options
That removes the need to muck with the dhcp-parameter-request-list.
vendor options - handcrafted
Known issues
[-3.63] Requires a TFTP server with support for the 'tsize' option.
- The error recovery routine doesn't work quite right. For now, it just does a hard reset - seems good enough.
- We should probably call the UDP receive function in the keyboard entry loop, so that we answer ARP requests.
- Boot sectors/disk images are not supported yet... They probably need auxilliary information (such as device) to work at all.
- pxechain.com, as of PXELINUX 4.00, was broken. See Common Problems. See also pxechn.c32.
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/
... 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 as 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.
On RIS Server, create the following folder structure:
NOTE: SetupEnglishImages 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.
Download the latest version of Syslinux from: http://www.kernel.org/pub/linux/utils/boot/syslinux/
From Redhat AS4u3 CD1 (or cd of the distro you wish to deploy), in the directory 'imagespxeboot' copy the following files into 'SetupEnglishImagesPXELinuxi386templates' on the RIS server.
Rename these files to:
e.g.:
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 'SetupEnglishImagesPXELinuxi386templates' on the RIS server.
In 'SetupEnglishImagesPXELinuxi386templates' create a file 'pxelinux.sif' and give it the following content:
In 'SetupEnglishImagesPXELinuxi386templatespxelinux.cfg' create a file called 'default' and give it the following content:
In 'SetupEnglishImagesPXELinuxi386templatesconf' create a file called 'x86.conf' (this will list all of our 32bit OS installs) and give it the following content:
In 'SetupEnglishImagesPXELinuxi386templatesconf' create a file called 'x64.conf' (this will list all of our 64bit OS installs) and give it the following content:
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.
Directory Structure:
/tftpboot/pxelinux.cfg/default:
/tftpboot/pxelinux.cfg/graphics.conf:
Change ALLOWOPTIONS to 1 (one) so as to be able to edit any of the entries while booted with PXE on the menu system for testing purposes. Also change NOESCAPE to 0 (zero) for the same reasons.
/tftpboot/pxelinux.cfg/fixes.menu:
/tftpboot/pxelinux.cfg/setup.menu:
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:
About 'architecture-type':
- 06 (EFI IA32) is sometimes (mis)used for legacy (CSM) boot of x64 machines by some vendors.
- 07 (EFI BC) is sometimes (mis)used for EFI x64 boot by some vendors.
- Each bootloader needs its respective 'ldlinux.*' module too:
Alternatively, the PXE directory can be organized by architecture number. This allows the namespace to be managed on the TFTP server (usually with symlinks), rather than requiring changes to DHCP:
- 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 as to share in-common Syslinux configuration files.
- See also PXELINUX-Multi-Arch.
Notes:
- Instead of 'pxelinux.0', the alternative 'lpxelinux.0' (with initial lowercase letter 'L') can be used for BIOS clients.
- The 'syslinux.efi' file for EFI IA32 is different from the one for EFI X64; each architecture/firmware has its own 'syslinux.efi'.
- The 'syslinux.efi' file for EFI X64 is the same binary for disk booting EFI X64 and for network booting EFI X64.
- The 'syslinux.efi' file for EFI IA32 is the same binary for disk booting EFI IA32 and for network booting EFI IA32.
- Each 'syslinux.efi' file can be renamed (e.g. to 'bootx64.efi'); just beware to use the adequate path(s) and name(s) in the dhcp configuration file.
Resources
- RFC 2132 - March 1997 - DHCP Options and BOOTP Vendor Extensions
- RFC 4578 - November 2006 - DHCP Options for PXE
- RFC 5071 - December 2007 - DHCP Options used by PXELINUX
- RFC 5494 - April 2009 - IANA Guidelines for ARP
- RFC 5970 - September 2010 - DHCPv6 Options for Network Boot
Retrieved from 'https://wiki.syslinux.org/wiki/index.php?title=PXELINUX&oldid=4690'