pxelinux.0 - Failed to load ldlinux.c32

[dreamcat4]

Hi there,

This is an independantly confirmed upstream bug, which occurs in version 6.0.3 of syslinux / plxelinux upsteram sources. The fix has already been committed to upstream, and can be found here:

http://www.syslinux.org/archives/2015-September/024305.html

If you read back the above thread, it explains pretty much everything about the bug in question. I myself encountered this bug today, whilst using the current official ubuntu syslinux pkg. Which is to say this one:

https://launchpad.net/ubuntu/+source/syslinux/3:6.03+dfsg-8ubuntu2

While being on ubuntu 15.10 wily.

Now xenial says:

https://launchpad.net/ubuntu/+source/syslinux/3:6.03+dfsg-11ubuntu1

Which is like minor patch revisions but still based on same 6.03 release upstream srcs? And hence the bug probably still exists in xenial. So you will probably need to either increment the upstream release version in your pkg to include the fix commit. Or else local manual patch onto buggy 6.0.3 release.

Many thanks.

====
To reproduce Error condition (it is the same as in the mailinglist thread):

* Install pxelinux pkg from official ubuntu.
* Copy pxelinux.0 + ldlinux.c32 --> pxe / tftp http web root
* Make a Net Boot entry for pxelinux.0 in ipxe.

As described here: http://jpmens.net/2011/07/18/network-booting-machines-over-http/

#!ipxe
imgfree
set 210:string http://10.0.12.249/pxe/
set 209:string http://10.0.12.249/pxelinux.php?MAC=${net0/mac}&ip=${ip}
set filename ${210:string}pxelinux.0
chain ${filename} ||
echo Netboot failed
shell

* pxe boot (network boot) in a virtualbox vm on same local lan (using bridged network adapter) --> ipxe
* have ipxe load with the above #!ipxe config file to in turn boot --> into pxelinux.0 (from ubuntu 6.0.3 syslinux pkg)
* pxelinux fails to use http etc. Due to a mis-commit (developer testing hack not put back) in their 6.0.3 code base.

Error msg:

Failed to load ldlinux.c32
(execution stops)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Danny Sauer (ubuntu-dannysauer)]

Apparently a workaround is to copy /usr/lib/syslinux/modules/bios/ldlinux.c32 (from the syslinux-common package) to your file root alongside pexlinux.0. That (annoyingly) works for me.

[Wouter Hanegraaff (wouter-openoffice)]

The workaround of copying ldlinux.c32 does not work. The problem as documented upstream in http://www.syslinux.org/archives/2015-September/024305.html still exists; see below my configuration*.

What happens after copying ldlinux.c32 to /tftpboot:
- the system attempts to execute the default boot option from the pxelinux.cfg/default menu, no matter what I type at the boot prompt
- if I make booting a kernel over http the default option, boot fails with the message:
"Loading http:////nl.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux... failed: No such file or directory" (no matter what I type at the boot prompt)

What happens after removing /tftpboot/ldlinux.c32 and copying gpxeboot.0 from an ubuntu 14.04 machine:
- system boots as expected.

*) I'm using the following config:
Ubuntu release:
Description: Ubuntu 16.04.2 LTS
Release: 16.04
pxelinux:
  Installed: 3:6.03+dfsg-11ubuntu1

- dnsmasq:
dhcp-boot=gpxelinux.0
enable-tftp
tftp-root=/tftpboot
log-dhcp

dhcp-range=10.38.18.10,10.38.18.100
- /tftpboot/gpxelinux.0 copied from /usr/lib/PXELINUX/gpxelinux.0
- /tftpboot/pxelinux.cfg/default:
DEFAULT l

LABEL l
        localboot 0

prompt 1
timeout 1200

LABEL xenial64
 kernel http://nl.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux
 append initrd=http://nl.archive.ubuntu.com/ubuntu/dists/xenial/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz ramdisk_size=16432 root=/dev/rd/0 rw console-setup/ask_detect=false console-setup/layoutcode=us debian-installer/locale=en_US.UTF-8 debconf/priority=critical --

[Kai Mast (kai-mast)]

Yikes. This needs to be fixed before 18.04.1.

The workaround doesn't seem to work for me either. ldlinux.c32 is nowehere to be found on my filesystem.

[Kai Mast (kai-mast)]

Woops. The workaround does seem to work for me after all..

[Paulo (ptsneves)]

I also confirm that the workaround is working