There are probably very few ISO images containing a ldlinux.sys file
that also matches the version of its isolinux.bin.
Actually, I know of only one such ISO, in which I was the one person
advocating for such inclusion, even after it was suggested (by others)
that the file was not needed.
To depend on what ISO builders add to their ISOs is a path for
uncertainty. And this uncertainty is very easily extended and expanded
if we are going to depend on package maintainers and developers
downstream.
Some people would think that "any developer" building an isohybrid
image would know its limitations, but such assumption would be wrong.
For instance, not using the UEFI parameter in the isohybrid command
while claiming it works for UEFI in the same way (aka "just dd"). It
might work OK, but not because of isohybrid. Another one: using the
isohybrid command with the default 64x32 (C)HS, instead of changing the
geometry so to support their more-than-1GiB ISO image that they build
by themselves.
Regarding the use of some "merged" isolinux.bin with
ldlinux.[sys,bin,c32], it would have to be an alternative to the
current isolinux.bin (not a replacement). And inertia will prove to be
relevant, when ISO builders won't change their methods / scripts
"just"
to use some alternative bootloader that would claim to support more
scenarios / devices. They already have one set of "working solutions"
(according to themselves), so they have no effective incentive. If
anything, they would tend to discard Syslinux (ISOLINUX) and use grub2
for everything/anything.
The amount of BS (and I do not mean "boot sector") that I have read
from package maintainers and distro developers regarding
Syslinux-related matters is astonishing to me. You would assume (or, at
least I did) that, when in doubt, package maintainers would contact
upstream projects; that has been proven to be almost-always false for
some very popular (and sometimes "trusted", "stable")
distros. In some
cases, Syslinux's packages are not actively maintained, nor updated
properly (or, at all).
The purpose of the above rant (and I could go on) is: _version
mismatch_ should be the main thing to solve in this context, and other
methods are closer to a wishful thinking. I'm not saying other methods
are worthless - they are not - but they won't really solve the issues
in question in a better way than having some standard methodical
versioning identification for all binaries.
Typical "dialog" follows.
Q: "I have followed some tutorial about PXELINUX, and it failed. Now I
have updated to the latest version of PXELINUX, because I hoped it
would solve the problem. Now I see a different behavior, but it still
fails".
A: "Which version?"
Q: "I am now using 6.03."
A: "Have you updated all your Syslinux-related files?"
Q: "Which files? The tutorial mentioned version 3.86 of pxelinux.0. I
replaced that file from version 6.03."
And another typical dialog:
Q: "I updated pxelinux.0 from 6.01 to 6.03 and now nothing works."
A: "Do you have (updated) ldlinux.c32?"
Q: "I do. I have (updated) all the necessary files."
A: "Hmm, perhaps there is a mismatch version. Have you copied / updated
_all_ the files?"
Q: "I _know_ I did. I have been using this script like forever lol".
(After 45 minutes of troubleshooting, or a day and a half...)
Q: "Wait, I think that some files are not present / correctly updated.
How would I know which version of *.c32 I am using? Maybe my script is
botched. Oh, the size of ldlinux.c32 does not match the size in the
PXELINUX package. The same for some of the lib*.c32 files. Let me
check."
(After some time...)
Q: "I copied over the files again, manually this time. All seems to be
working now. I wish there would be a way to check the version of these
files. It would have saved me a lot of troubleshooting."
And finally, another typical dialog.
Q: "I am using mboot.c32. I updated to the latest version, and my VM
now fails. What could be wrong."
A: "Just a hunch... where the prior mboot.c32 came from?"
(After several minutes of troubleshooting, and explanations, and links,
and the user insisting that he knows a lot and has enough experience,
that what has been suggested to him cannot be correct...)
Q: "Oh, so the prior mboot.c32 is a custom build from 'company X'!?
Can't the official mboot.c32 do the same?"
A: "No. The source code is not available outside 'company X', and
no
other version of the Syslinux family of bootloaders can be used with
it. It will fail."
Conclusion: People have to copy the Syslinux-related files from the
same (exact) build, whether it is an official upstream release,
pre-release, patched package, built from some specific git commit...
Sometimes this task is not performed adequately, whether for lack of
knowledge, misinformation, a mistake, incorrect assumptions, or any
number of reasons.
Upstream official Syslinux binaries should rather have some kind of
additional (string) identifier (in addition to some complete version
value) that would not be normally (automatically) included in
downstream builds.
We should be able to easily differentiate bootloader files that are
built with debugging capabilities. Users should be able to relatively
easily answer to
such a question.
Please, please, improve the version identification and handling of all
Syslinux-related binaries, in a consistent coherent expandable
documented clear
manner.
Regards,
Ady.