When I'm finished collecting all the details for this, I'll post this bug report in the forums with the title "Bugfix for PXE booting".

In Slax v6.1.2 there's a bug with the "Slax as PXE server" boot option.

Explanation

To boot successfully, a PXE client has to fetch these files, in order:

tftp://10.*.*.1/pxelinux.cfg/pxelinux.0
tftp://10.*.*.1/pxelinux.cfg/default
tftp://10.*.*.1/vmlinuz
tftp://10.*.*.1/initrd.gz

The bug occurs when it fails to load the 'default' file. PXELINUX has the notion of a "path prefix". PXELINUX's documentation says that in this case, it should decide that the path prefix is "/pxelinux.cfg/". This means that it will try to load tftp://10.*.*.1/pxelinux.cfg/pxelinux.cfg/default, which won't work.

The Wireshark capture at http://www.paperlined.org/apps/slax/PXE_booting/gpxe_with_v6.1.2.pcap shows this problem happening.

If this is a PXELINUX standard feature, then why wasn't this problem found in previous testing? Answer: Some PXE clients seem to pass the "/pxelinux.cfg/pxelinux.0" path to PXELINUX, while others seem to prevent PXELINUX from knowing what its path is, thereby obscuring this bug. Clients that always fail with v6.1.2 include: gPXE. Clients that always succeed with v6.1.2 include: VirtualBox's BIOS.

TODO: test this theory out on a larger number of computers in the lab, especially physical computers

Workaround

When using v6.1.2, a quick fix is to create /etc/dnsmasq.conf with these two lines:

dhcp-option-force=208,f1:00:74:7e    # pxelinux.magic   (without this, the next setting will be ignored)
dhcp-option-force=210,/              # pxelinux.pathprefix

And then run /boot/pxelinux.cfg/start to restart dnsmasq.

Long-term fix

For the official release, it's probably better to make those changes to dnsmasq's command line, inside the /boot/pxelinux.cfg/start script.