Cards that cause trouble no matter what

Some versions of the Promise ATA RAID cards are known to cause problems no matter if you boot from them or not. I have received several reports that conclusively show that the Promise ATA RAID BIOS overwrites random location in low memory. This BIOS is considered utterly unsupportable. This phenomenon has been observed even when the ATA RAID is not the boot device (e.g. using PXELINUX.)

Problematic network cards

The following network cards are known to have problems with PXELINUX; and this is what you can do about it. This page is updated when new information becomes available; if you have additional information please send it to hpa+cards@zytor.com.

Basically all PXE implementations

A fair number of PXE implementations has problems with releasing base memory once booting is complete. This should not affect you if you're running Linux, but other operating systems, such as DOS under MEMDISK, may have less memory available than they should. PXELINUX 1.65 or higher will display a message:

Failed to free base memory, sorry...

... when that happens. It should not cause problems other than the loss of some memory; usually about 64K worth. PXELINUX 2.03 or later will display an error code in conjunction with the message; reporting that error code might assist in identifying the location of the problem.

Most, possibly all, PXE implementations are completely broken if they receive fragmented IP packets; also, a lot of them will request a blksize of 1468 or thereabouts, corresponding to an MTU of 1500. Therefore, your boot server should never use an MTU that is larger than the MTU the packets may encounter during the transfer (typically 1500), and you should disable the blksize option (-r blksize in tftp-hpa) if you have to use an MTU smaller than 1500. Fortunately it's rare these days that you'll have that kind of network between your TFTP server and your clients.

SiS900

A number of problems have been reported with SiS900-based cards (at least with "BootRom V1.09 Intel UNDI, PXE-2.0, build-082.") See this message for a workaround.

Intel Boot Agent 4.0.19

A lot of people have reported problems with Intel Boot Agent 4.0.19 not performing the initial bootstrap correctly. On the other hand, versions 4.0.17, 4.0.21, and 4.1.01 have all been reported to work correctly. This problem also seems to occur on version 4.0.18 as well. You will likely see symptoms similar to the following bolded output from a Sony VAIO PCG-GRX520 Version R0216B0:

If your network adapter is on the motherboard, you will probably need to request a BIOS upgrade from your system or motherboard vendor. Alternatively, with a little bit of googling, one can locate BIOS image editors capable of replacing "Expansion ROM" images following the main BIOS. Using this technique, it's possible to extract and modify the UNDI network driver and/or the Intel Boot Agent Expansion ROM. THIS IS DANGEROUS. DO NOT ATTEMPT IF YOU DO NOT UNDERSTAND EXACTLY WHAT YOU ARE DOING.

Early Intel Pro/100+ Server cards

According to the Intel release notes, some early versions of the Intel Pro/100+ Server cards will occationally bail with a "media test failure." This is a hardware problem.

Many 3Com cards

A lot of 3Com cards with PXE boot ROMs have been reported as having problems with PXELINUX. 3Com MBA v4.30 or later is believed to work on all supported network cards, however, not necessarily embedded on motherboards. If your boot ROM is older, you can download a firmware upgrade at: http://support.3com.com/infodeli/tools/nic/mba.htm

I would like to obtain information of various 3Com MBA versions and whether or not they work. Please send such reports to hpa+cards@zytor.com.

PXE stacks based on Intel's 0.99 series code

A lot of older PXE stacks are based on Intel LANDesk Service Agent II, versions 0.99, which were released by Intel as "PXE PDK v2.x", despite being what can best be described as alpha quality. These stacks have numerous problems and can trivially be crashed.

If you can, upgrade your firmware.

Unfortunately, firmware upgrade to a recent source base are frequently unavailable for these cards, especially motherboard cards where the PXE stack is integrated with the system BIOS. If so, these stacks can usually be made to work with the following workarounds:

Disable path MTU discovery on the boot servers.

Some versions of these stacks are known to crash if the boot server supports path MTU discovery on UDP. For a Linux server, path MTU discovery can be disabled by setting the sysctl entry net.ipv4.ip_no_pmtu_disc to 1:

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

Note that that may cause bad performance for other services which may be running on the boot server, especially if they have to talk over WAN links. DHCP or TFTP services should generally not be affected.

Newer versions of tftp-hpa will automatically disable path MTU discovery for the TFTP service only if run on Linux.

Disable the blksize TFTP option on your TFTP server.

Some version of these stacks are known to request the blksize option and fail to complete the initial bootstrap transfer if the option is granted by the server (i.e. they got what they asked for.) For tftp-hpa, specify -r blksize to disable blksize, for atftp specify --no-blksize. For other TFTP servers, see your TFTP server documentation. Note that disabling blksize may have a significant impact on the performance of all TFTP clients. Other services are not affected.

Broadcom 57711

HP Proliant BL460c G6 servers with Broadcom BCM 57711 10Gbit NICs were reported to have an issue with gpxelinux.0 (gPXE + PXELINUX) as of v4.02. The workaround (implemented in v4.04 as gpxe/gpxelinuxk.0; emphasis on the single "k") was to:

Problematic CD-ROM controllers

At least one Promise ATA-type controller with BIOS (model number unknown) does not work with ISOLINUX since it hard-codes the location of the El Torito boot catalogue from the Windows 2000 CD-ROM and will only boot from this location!!!!!! The reporter of this bug was able to get it to boot by hacking mkisofs to put the boot catalogue in the same location as the Windows 2000 one.

Keyboard Issues with Dell OptiPlex GX520 and GX620

There is an apparent issue with the latest bios (A11) on this model that is known to cause this problem.
The fix is to downgrade to version A10.

UPDATE: a possible workaround for this problem has been identified. Syslinux 3.70 or later is believed to not be affected.

USB related problems

No BIOS USB boot support by the BIOS

To overcome this BIOS limitation, you can boot this USB drive with PLoP Bootmanager.

Note: If you enable the USB support of PLoP Bootmanager, USB keyboards and USB mice won't work anymore.

Slow USB boot

You can enhance USB booting speed, when your BIOS only supports USB1.1 speed, while your USB controllers support USB2.0, with PLoP Bootmanager.

Are you using the "-s" argument (aka "slow") when installing SYSLINUX? Do you really need this argument so to successfully boot in/with this particular hardware?

USB drives larger than 128GiB (=137GB)

Some BIOSes have problems with booting USB drives larger than 128GiB (137GB) (28-bit LBA limit). (If the drive can also be connected via SATA, it is entirely possible that it will boots fine.)
When Syslinux,another bootloader or an OS that uses BIOS calls to read from the drive, wants to access any data beyond this 128GiB limit, it won't get what it wants.

To overcome this BIOS limitation, you can boot this USB drive with PLoP Bootmanager.

USB-Geometry

Geometry-related issues are one of the more common reasons
preventing booting in some systems while the same drive may work in
others. The BIOS inspects the drive, then estimates the geometry
based on the total size of the drive and on some key content on it.
If it fails to estimate properly, it can either be assumed
unbootable or exhibit strange failures when attempting to read
blocks (e.g. unable to find <somefile> or only
showing the Syslinux copyright banner but no other message).

Check to ensure that the LBA addresses match the CHS addresses and
that the FAT VBR (Volume Boot Record; aka BPB or BIOS parameter
block) matches these values too.

Some systems also refuse some attempted geometries on some
drives (i.e. you are trying to change "sectors per track"
and "heads per cylinder") such that even if the partitions are
aligned to the geometry properly, it may still refuse to boot.
Partitioning with "cylinder alignment", or with "MiB alignment",
or with no alignmet at all, would probably not affect the
chances of successfully booting; but using an adequate drive
geometry that most BIOS can recognize, will.

Depending on the system, you may find better luck with a USB drive
with a single partition of either FAT16 or FAT32 starting at the
standard CHS 0,1,1 and ending on the edge of a cylinder.

For example, if a drive has a size of 128 MB (or slightly larger),
it should be assumed with 64 heads per cylinder and
32 sectors per track. Its partition should then end at
C/H/S: 127 / 63 / 32 .

Drives larger than 1 GB should be regarded as having 255
heads per cylinder and 63 sectors per track. E.g. a drive of
15'794'176 blocks (7.5 GB) should have its partition end at
C/H/S: 982 / 254 / 63 .

Drives larger than 16'434'495 blocks should bear its partition
end at C/H/S: 1023 / 254 / 63 . Setting the
partition's ENDing LBA to the full drive size may or may not
hamper its bootability.

LOCALBOOT

Certain models of computers, sometimes specific to BIOS and BIOS extension versions, do not work well with at least certain (but sometimes all) LOCALBOOT options (as of v3.70, available in all variants however PXELINUX interprets the option differently). As a workaround, use chain.c32 like this:

This is also equivalent to the command line "chain.c32 hd0". Omitting the partition number (as in these examples), implies partition number 0 (MBR).

LOCALBOOT on HP ProLiant servers

The LOCALBOOT option doesn't work reliably on G5 and older HP ProLiant servers because of BIOS defect QXCR1001064253.

LOCALBOOT on Dell Latitude E6400

The E6400 with BIOS A14, A25, A27, and A28 (probably all) has an issue with using "LOCALBOOT 0" from PXELINUX. "LOCALBOOT -1" in PXELINUX is known to work. This issue probably also affects the E6500 and possibly the E5500, E5400, Precision M4400 and M6400 as in the past model selections like these from the same generation share a lot of their BIOS code.

LOCALBOOT on Dell Latitude E6410

This is currently under discussion with Dell. Currently, when using LOCALBOOT on a Dell Latitude E6410 with BIOS revisions A04 and A07, different results will occur. -1 results in a reboot. 0 results in a hang. This issue probably also affects the E6510 and possibly the E5510, E5410, Precision M4500 and M6500 as in the past model selections like these from the same generation share a lot of their BIOS code.

LOCALBOOT on Dell PowerEdge c6220

'LOCALBOOT 0' will hang or reboot the machine. This was tested with 4.04, 4.06-pre14, 4.10-pre17 and 4.10-pre22 (all with BIOS version 1.0.28 A02) The chain.c32 workaround will work properly, or you can install the patch from this post: http://www.syslinux.org/archives/2012-July/017880.html

LOCALBOOT on IBM x3850 X5

The LOCALBOOT cannot work properly on IBM x3850 X5 server. The solution is users have to update the uEFI firmware with the latest version 1.32 then using chain.c32 module and following syntax to boot up the first hard drive: