[syslinux] Acceptable version mismatch between syslinux 6.0N's MBR/ldlinux.sys and *.c32?

[Ady]

> Hi there,
> 
> first, thanks a lot for syslinux!
> 
> I'm aware that one can't mix syslinux 4's MBR + ldlinux.sys with
> syslinux 6's COM32R modules. Fair enough. Now, I need to know how
> strong this "versions *must* match" requirement is when dealing with
> different versions of syslinux 6.x. E.g.
> 
>   * MBR and ldlinux.sys installed by syslinux 6.03-pre1
>   * all *.c32 modules installed by 6.03-pre14
> 
> Has this a chance to work?
> 
> Of course, feel free to ask me to just try myself. Still, assuming
> this currently works fine, it would be good to know to what extent
> such incompatibilities are likely to happen in the future, when mixing
> bits of different versions of the 6.x branch.
> 
> Can anyone make a rough guess?
> 
> Context: Tails [1] has an "Upgrade from ISO" feature, that allows
> upgrading USB stick B, while running from USB stick A, using
> a user-provided ISO image. Generally, this is used to upgrade stick
> B from Tails version N to N+1, while stick A is still running version
> N. (If stick A was running version N+1, the user could simply use our
> "Clone and Upgrade" feature instead). During this process, the MBR and
> ldlinux.sys are upgraded, using the version of syslinux shipped in
> stick A. Generally speaking, when Tails version N+1 ships a newer
> version of syslinux than the one shipped in Tails N, we're then going
> to mix an older syslinux MBR + ldlinux.sys, with newer COM32R modules.
> This can't possibly work for the syslinux 4 -> 6 upgrade, but we'll
> work around that problem somehow, UX will be degraded during this
> upgrade, but oh well. My question is about future upgrades between
> point-releases of syslinux 6. So, my question really is: once all
> Tails users have a stick in version N that ships, say, syslinux
> 6.03-pre1, and the next upgrade to version N ships with 6.03-pre14's
> COM32R modules, will running syslinux 6.03-pre1 on the upgraded stick
> (that has 6.03-pre14 COM32R modules) make it unbootable?
> 
> [1] https://tails.boum.org/
> 
> Cheers,
> -- 
>   intrigeri
 
I don't have a definitive answer (and I am not a Syslinux developer), 

but generally speaking I would say that mixing Syslinux versions 
should be completely avoided, specially since Syslinux 5.xx 
considering the additional lib*.c32 library modules dependencies. I 
would even say that there is a slight chance that mixing files from 
two different builds (e.g. w/o debug, gcc versions...) of the same 
version might bring unexpected results.

In some particular case, mixed files might work OK, but IMHO it 
shouldn't be part of a planned method of upgrading a distro.

Although I haven't tested it lately, the Tuxboot tool should be able 
to use the version of Syslinux included in your ISO images so to 
transfer it to a (USB) drive. Since it works for other Debian-based 
distros, it might answer to your needs. GParted/Clonezilla Live also 
include scripts for the same purpose, and they are already using 
Syslinux 6.03-pre*.

Regarding the MBR code, it rarely changes, but there have been such 
occasions.

Regarding the particular versions you mentioned, IMHO using 6.03-pre1 

would be a waste of time, as there are already (too) many 
improvements over it in the current 6.03-pre14.

Regards,
Ady.


PS: [off-topic] 
Reading the reports from users testing TAILS in UEFI systems, you 
might want to consider adding the 'MENU RESOLUTION 1024 768' 
directive to your EFI/tails.cfg as temporary workaround (for example, 

for those that can't see the Syslinux command line when pressing TAB 
in the EFI vesamenu; the BIOS boot menu doesn't need this 
workaround). I can't guarantee it will match all your (users') needs, 

but there is a chance it might work for some. YMMV.