Hardware Compatibility

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:

Intel(R) Boot Agent Version 4.0.18 Copyright (C) 1997-2001, Intel Corporation CLIENT MAC ADDR: 08 00 42 42 42 42 GUID: D4E54B40-4B65-11C6-8C44-080042424242 CLIENT IP: 10.0.0.98 MASK: 255.0.0.0 DHCP IP: 10.0.0.17 GATEWAY IP: 10.0.0.17 TFTP. PXE-T04: unsupported request from 10.0.0.98 PXE-E36: Error received from TFTP server PXE-M0F: Exiting Intel PXE ROM.

If you have a card or system with Intel Boot Agent 4.0.19, please contact the manufacturer for an upgrade.

If you have an Intel-branded network card (not on the motherboard), you might be able to find a flash upgrade at: http://support.intel.com/support/network/adapter/index.htm

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 occasionally 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 versions 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:

• Edit gpxe/Makefile to use undionly.kpxe instead of undionly.kkpxe and;
• Edit gpxe/pxelinux.gpxe to change "set use-cached 1" to "set use-cached 0" (as "set use-cached 1" is not supported with .kpxe image).

http://www.mail-archive.com/gpxe@etherboot.org/msg01002.html
http://www.syslinux.org/archives/2010-October/015782.html

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.

It might be worth to look at the ifplop.c32 COM32 module.

Are you using the "-s" argument (aka "slow") when installing SYSLINUX? Do you really need this argument so as 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 boot fine.) When either 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.

It might be worth to look at the ifplop.c32 COM32 module.

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 properly aligned to the geometry, 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.

Suggested CHS values according to size are also relevant (and might also apply) for building isohybrid images.

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:

LABEL localboot
 MENU LABEL Boot from first hard drive
 COM32 chain.c32
 APPEND hd0

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: Dell OptiPlex 790 PXELINUX localboot reboot loop based on commit 0a0e0e41cad93cd16c323cf16f40264a21eedd6c of the git.kernel.org/pub/scm/boot/syslinux/syslinux.git repository.

diff --git a/core/pxelinux.asm b/core/pxelinux.asm index e8818a6..27dc595 100644 --- a/core/pxelinux.asm +++ b/core/pxelinux.asm @@ -132,6 +132,13 @@ _start1: mov ds,ax mov es,ax +  ; Copy chunk of memory used by Dell BIOS on OptiPlex 790s +  ; Allows control to return to PXE Boot Agent for localboot + mov esi,47cch + mov edi,DellBIOSChunk + mov ecx,13 + rep movsd +  %if 0 ; debugging code only... not intended for production use  ; Clobber the stack segment, to test for specific pathologies mov di,STACK_BASE @@ -289,6 +296,14 @@ local_boot:  ; Restore the environment we were called with pm_call reset_pxe call cleanup_hardware + +  ; Copy Dell BIOS chunk back into place + cld + mov esi,DellBIOSChunk + mov edi,47cch + mov ecx,13 + rep movsd + lss sp,[InitStack] pop gs pop fs @@ -564,3 +579,6 @@ IPInfo: .ServerIP resd 1 .GatewayIP resd 1 .Netmask resd 1 + + section .earlybss +DellBIOSChunk resd 13  ; 52 bytes to store Dell BIOS chunk

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 the following syntax to boot up the first hard drive:

LABEL localboot
 MENU LABEL Boot from first hard drive
 COM32 chain.c32
 APPEND hd0 0

localboot.lua

As there are a lot of computer models that don't work properly with LOCALBOOT, a Syslinux user has written a Lua script that uses DMI data to identify known-bad models and automatically uses chain.c32 to boot these. The script will default to LOCALBOOT for all unknown computer models, except for all known-bad models where it will use chain.c32. It is maintained on github:

https://github.com/IServ-GmbH/localboot.lua

Chromebook

Syslinux 6.03 might fail to boot in some hardware (e.g. some Chromebooks). Trying Syslinux 6.04-pre1 (or later) by using the official upstream pre-built (no 'make') binaries is recommended. Feedback is appreciated.