Syslinux - Jun 2014 - Acceptable version mismatch between syslinux 6.0N's MBR/ldlinux.sys and *.c32?

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
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

> 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.

On Wed, Jun 11, 2014 at 2:58 PM, intrigeri <intrigeri at boum.org>
wrote:
> 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?
Sure there's a chance but no guarantees. Everything should come from
one build.  I'd suggest against an older core.  Please review the
commit log.
> 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
I'd suggest an alternative: extract the newer version from the ISO
then run it.  The installer binary is more likely to be compatible due
to how glibc works.  The MBR won't matter (it could be from MSDOS-6
from 1993 really if EDD isn't needed) but the VBR (the first sector of
the file system) will.
> 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
See above suggestion.  :D
> 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?
No (but I'd define unbootable as unable to get to a boot prompt then
load a kernel/initrd not allow functionality of COM32 modules) but it
may make it unpleasant.
> [1] https://tails.boum.org/

-- 
-Gene

Hi,

first, thanks a lot, Ady and Gene, for your prompt and very
useful replies!

Ady wrote (11 Jun 2014 20:18:43 GMT) :
> 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*.
Ah, that was just the hint I needed. I didn't know that all what we
needed, in our situation, was the syslinux binary. Now, I see that
Clonezilla simply ships a syslinux binary (in utils/linux/syslinux),
and Tuxboot uses this path. We'll do the same, and will use the same
paths for standardization's sake.

(Before sending my initial email, I had looked into running syslinux
from the SquashFS filesystem that's inside our ISO, but that required
a bit of mount -o loop and chroot dance, which requires root
privileges and brings security concerns to the table. I'm glad you
suggested something way simpler to me.)
> 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.
Sure, we're eagerly waiting for a newer version to be uploaded to
Debian. Not sure we have time to integrate it in time for Tails 1.1,
in case there are packaging changes or files moving around.
> 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, 
I'll look into it, thanks!

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc