Today I built myself a USB stick with grml on it (see #943838 for the
problems I had with that).  When booting an old 32-bit laptop with this
stick syslinux threw some error messages before its prompt:

,----
| Undef symbol FAIL: x86_init_fpu
| Failed to load libcom32.c32
| Failed to load COM32 file vesamenu.c32
| boot:
`----

There was supposed to be a nice boot menu, but since vesamenu.c32 failed
to load it was not displayed.  TAB completion at the boot prompt and
actually booting worked, though.

This may be related to #918915, although that bug is already archived.

Hi Sven,

thanks for your report!

I'm unable to reproduce this at the moment using the syslinux version
3:6.04~git20190206.bf6db5b4+dfsg1-1 .

I'm suspecting that there is somehow a mismatch between the version of
syslinux/extlinux used while installing (i.e. running `extlinux -i`)
and the c32 files installed on the medium.

Can you check whether the c32 files installed on the medium
(probably in /boot/syslinux or /boot/extlinux) match the one
from /usr/lib/syslinux/modules/bios on the host system? If they do
match, can you re-run the syslinux installation from the host system
and then try again? Is the image bootable when using `qemu-system-i386`?

If all of the above does not help narrow down the problem, can you
provide me with the necessary commands to build a similarly broken image
myself?

Thanks for your help
Lukas

Indeed, this was the case.  While the version of syslinux installed in
the boot sector was the one from Debian, the support files in the
boot/syslinux directory came from the grml iso.  After replacing them
with the files from /usr/lib/syslinux/modules/bios/ everything was fine.
onto the boot medium with syslinux commands?  The naive command
"syslinux -d boot/syslinux /dev/sdc1" (or whatever device instead of
/dev/sdc1) does not do that, yet grml2usb apparently relies on it.

Cheers,
       Sven

On Wed, 30 Oct 2019 22:41:48 +0100 Sven Joachim <svenjoac@gmx.de> wrote:

Unfortunately syslinux does not offer any "installer" to do that (nor
does the Debian package).  The admittedly poorly documented installation
procedure is more or less to run the installer and copy any modules you
need yourself to the correct folder.

`syslinux -d boot/syslinux /dev/sdc1` does not install any c32 modules.
This means any c32 modules present on your medium were copied by
grml2usb.  I don't know the details of how grml2usb installs syslinux,
but they need to make sure whatever is installed to the volume boot
record (`syslinux` or `extlinux` command) is consistent with the c32
modules.  Either both must come from the host system or both from the
installed medium.

Regards
Lukas

Control: tags -1 - moreinfo
Control: clone -1 -2
Control: reassign -1 grml2usb 0.14.14
Control: retitle -1 grml2usb: Uses wrong path to syslinux modules
Control: severity -2 wishlist
Control: retitle -2 syslinux: should provide an API to query/install modules

In fact grml2usb intends to install both from the host, and originally
this probably actually worked.  However, in version 6.00 syslinux
changed the path to the .c32 files and then it broke.  I could not find
this mentioned in the upstream NEWS file or in the Debian changelog, so
it would not have been easy for the grml developers to discover it.

I am reassigning the current bug to grml2usb, but I think there ought to
be an API in syslinux to query the path to its modules and to install
them onto the boot medium, so a clone of this bug is left for you.

Thanks for the fast response.

Cheers,
       Sven