[syslinux] Module Versioning... and other things

Pete Batard pete at akeo.ie
Tue Mar 8 04:23:41 PST 2016


With apologies to Ady, I think there are important points to be made 
from this conversation, one which being the merging of ldlinux.sys and 
isolinux.bin, which I would very much like to rally people on this list 
into seeing as beneficial. So I will reply to this e-mail.

On 2016.03.08 03:10, BALATON Zoltan via Syslinux wrote:
> The difference is that the
> headache in this case is for those tech savvy people creating the hybrid
> iso who should be able to figure it out so the non-tech savvy end users
> should not have a problem with it as long as used as intended.

You're trying to reframe the context in a direction that was never 
there. My context was always the one of tech savvy developer trying to 
create a bootable USB from an ISO (be it in a process that automates 
this creation or something else, with the goal of making the result easy 
to use for non teach-savvy users). So I don't think you can go around 
saying "Ah, but ISOHybrid is for this context and the ldlinux.sys 
replacement is for that context", when, in essence, those contexts are 
the same.

> If you're already rebuilding the boot loader on the iso you could also
> replace all of syslinux with a known working version that you have all
> the matching modules for and only keep the config.

I already talked about this.

> But can break with patched syslinux
> versions or if they have custom modules.

Indeed.

> (But then trying to use a
> substitute part from a release for this customised version would likely
> break too.)

How so? I would argue that, on the contrary, it's very unlikely that 
people will modify the Syslinux core files, as opposed to tweaking a 
module that does something close to what they, but not quite. My 
experience so far has been that replacing 'ldlinux.sys' by the closest 
official Syslinux version always works and I haven't seen a single case, 
so far, where it didn't.

> I was also thinking about storing hashes of files that you have modules
> for and try to idenfify the version by comparing the hashes instead of
> trying to extract a version number from the binary, but this may be
> problematic as well because building with different compilers will
> result in different hashes and you don't know what was used by those
> created the iso.

I thought about that too, and came to the same conclusion.

> I don't see a way to solve this problem in a way that is fool-proof and
> cannot break

I very much do.
And I explained exactly what that was in the PS: at the end of my long 
e-mail.

So, once again, IMO, the Syslinux project should merge 'isolinux.bin' 
and 'ldlinux.sys' into a single executable, that behaves differently 
(through parameter, or name check, or something else) whether launched 
from MBR or El-Torito. Then all an ISO->USB conversion process has to do 
is install in 'ldlinux.sys' mode and it will work, because you are 
guaranteed that it will be compatible with the modules on that ISO. My 
current understanding is that 'isolinux.bin' and 'ldlinux.sys' are being 
assembled from the same set of object files, so it should be doable.

Merging 'isolinux.bin' and 'ldlinux.sys' into a dual executable is 
something that I would have liked to see happen as soon as it became 
apparent that a lot of people where using ISO images as means of 
creating UFDs. Of course I kind of understand why this wasn't 
considered, but I hope that bringing forward the inherent ISO -> USB 
conversion problems I highlighted, which may not be have been that 
obvious before, can help convince people on this list that this would be 
a worthwhile effort.

Besides, it does look to me like people on this list like dealing with 
"dual" solutions like ISOHybrid, so I sure wouldn't mind if other "dual" 
solutions were also looked into...

> Also I'm surprised that isos converted this way still work and the
> software on them is not confused by having its files on a different
> filesystem loosing case sensitivity, access rights, links, etc. For
> simple live CDs running entirely from an initrd this could work but for
> anything more complex than that I wonder how it does not break.

Some distro developers (IMO rightfully) do not see ISOHybrid as the 
panacea of ISO -> USB conversion, and, being aware that their ISOs are 
going to be used on a FAT32 filesystem (especially in the context of 
UEFI conversion, which can become effortless in this fashion), are 
careful enough to weed out stuff like Rock Ridge symbolic links, access 
rights, or anything that is not so portable. Besides, live CDs are meant 
to be read-only in the first place, and there isn't much in there that 
really warrants access rights (especially when persistence is meant to 
be handled separately). So the only major potential issues we have are 
symbolic links and the media label (when initrd boot scripts are seeking 
the media using a mixed case or > 11 chars label, which FAT doesn't 
allow), but in most circumstances, the label will be specified in the 
config file boot options, which Rufus can and does modify accordingly.

With regards to symlinks, I've been waiting for user reports to see if 
it was something I needed to address in Rufus (by trying to duplicate 
content - of course with the caveats related to doing this), but so far, 
there doesn't seem to be a live distro out there that critically relies 
on them. Most of the usage I have seen for symlinks so far are to have a 
/docs link on root that points to a lower level user documentation, or 
something similar.

In other words, as surprising as it may seem, it is my understanding 
that most Linux distro maintainers are very conscious that what they put 
on an ISO may end up on a FAT filesystem, and will therefore try to 
ensure that it will work there. At least I know the Debian people are 
(and will fix issues related to copying to FAT32 when they arise [1])

Regards,

/Pete

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789600


More information about the Syslinux mailing list