[syslinux] Module Versioning

[Ady]

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.