Re: syslinux: updating in stretch?

[Steve McIntyre]

On Wed, Oct 18, 2017 at 06:47:28PM +0200, Lukas Schwaighofer wrote:
>
>I'll wait with the pu request until I've also gotten feedback from the
>CD team as you suggested.

As confirmed in IRC last night - I think this all looks good
too. Thanks for your work Lukas!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Re: syslinux: updating in stretch?

[Lukas Schwaighofer]

Hi,

thanks a lot for your feedback and for explaining the whole process.

On Wed, 18 Oct 2017 01:44:25 +0200
Cyril Brulebois  wrote:

> > I didn't think to open a separate bug against syslinux, which
> > would have been the right thing to do… the bug against debian-cd,
> > which is affected by this problem, holds relevant information:
> > https://bugs.debian.org/857597  
> 
> It might be a good idea to have a bug report against syslinux as well,
> which can be used for version tracking purposes, which is most
> appreciated by people handling stable-proposed-updates requests (we
> usually consider this mandatory, even if we sometimes let a few
> exceptions go through).

Makes sense, I've cloned the above bug against debian-cd for that
purpose since it contains a lot of useful information on the issue:
https://bugs.debian.org/879004

> > (...)  I'm able to locally reproduce each of the two problems and
> > also confirm that the respective patches fix the problems.  
> 
> On top of the stretch package? It's always reassuring for stable
> release managers to have people actually test packages for stable.

Makes sense.  I have built the package as I currently think it should
be uploaded to stretch (in a stretch chroot) and tested all the cases
again. Everything still went fine in my tests :) .  I've pushed it into
the debian/stretch branch of the git repository in case someone else
wants to already start testing it as well:
https://anonscm.debian.org/git/debian-cd/syslinux.git

> > (...) the built isohdpfx.bin file (with the fix applied) is
> > identical to a known-good and tested version.  
> 
> That seems reassuring enough as far as I'm concerned.

I've also checked that it's same file in the package built for stretch
as well (with patches applied).


I'll wait with the pu request until I've also gotten feedback from the
CD team as you suggested.

Thanks again
Lukas


pgpZypVZ2Hl6H.pgp
Description: OpenPGP digital signature

Re: syslinux: updating in stretch?

[Cyril Brulebois]

Hi Lukas,

And thanks for your mail. I'm adding debian-boot@ for their information.

Lukas Schwaighofer  (2017-10-17):
> as it turns out, syslinux in stretch is in a quite sorry state.  To
> summarize:
> 
> 1. Booting from ext4 partitions created with Debian stretch does not
>work, because ext4's 64bit feature is enabled by default (since
>Debian stretch) and not supported by syslinux [1].
> 2. Booting from btrfs does not work [2].
> 3. A bug in the isolinux isohybrid MBR causing boot failures with some
>old BIOS [3].
> 4. Booting from xfs does not work (which was already the case in
>jessie, so not a regression in stretch) [4].
> 
> You will notice that this does not really leave any modern Unix
> filesystem for syslinux/extlinux to boot from… from the above problems,
> 1-3 are a regression compared to Debian jessie.
> 
> [1] https://bugs.debian.org/833057
> [2] https://bugs.debian.org/865462
> [3] I didn't think to open a separate bug against syslinux, which would
> have been the right thing to do… the bug against debian-cd, which
> is affected by this problem, holds relevant information:
> https://bugs.debian.org/857597

It might be a good idea to have a bug report against syslinux as well,
which can be used for version tracking purposes, which is most
appreciated by people handling stable-proposed-updates requests (we
usually consider this mandatory, even if we sometimes let a few
exceptions go through).

> [4] https://bugs.debian.org/803938
> 
> 
> Problems 1 and 2 have an upstream fix each [5, 6] which is pretty small
> in size.  I'm able to locally reproduce each of the two problems and
> also confirm that the respective patches fix the problems.

On top of the stretch package? It's always reassuring for stable release
managers to have people actually test packages for stable.

> Problem 3 also has a small and self-contained upstream fix.  And
> although I have no way to test this myself, the built isohdpfx.bin file
> (with the fix applied) is identical to a known-good and tested version.

That seems reassuring enough as far as I'm concerned.

> Problem 4 is fixed upstream as well (which I have not tested yet), but
> the number of changes for that is pretty high.  Since this is both a
> large patch and a not a regression from jessie, I don't intend to fix
> this in Debian stretch.

That seems like an appropriate course of action indeed.

> [5] 
> http://git.zytor.com/syslinux/syslinux.git/commit/?id=af7e95c32cea40c1e443ae301e64b27f068b4915
> [6] 
> http://git.zytor.com/syslinux/syslinux.git/commit/?id=548386049cd41e887079cdb904d3954365eb28f3
> 
> 
> The current version in unstable contains the patches for 2 and 3
> already and I've just requested sponsorship for another update which
> also fixes 1.  Provided we do not find any regressions related to the
> fixes for problems 1-3, I would like to push those patches [7, 8, 9]
> to the version in Debian stretch in the next point release.
> 
> I know the next point release is still ~6 weeks off, but bootloader
> changes are obviously critical.  So I wanted to raise this issue well
> before the deadline to get an idea how (or if) I should proceed:
> 
> * Is this a reasonable request, or are these changes too dangerous
>   for a point release anyways?

Your proposed changes fit the stable-proposed-updates criteria exactly,
with fixes in unstable, backports/cherry-picks to stretch already tested
and confirmed good, and reasonably-sized diffs. Really nice!

> * What kind of testing is required / expected so these changes can be
>   considered?

I think debian-cd@ is most qualified on this topic, I'm not sure d-i
uses syslinux for many things except for booting from an ISO anyway.
Consequently, what follows is just generic advice:

If you get a green light from debian-cd@, I think you only need to:
 - open a bug report for bug #3 (see my first paragraph);
 - open a pu request with a source debdiff against the package in
   stretch with an appropriate version number (probably
   3:6.03+dfsg-14.1+deb9u1); including as many details as in this
   mail would probably do the trick.


KiBi.


signature.asc
Description: PGP signature

syslinux: updating in stretch?

[Lukas Schwaighofer]

Hi,

as it turns out, syslinux in stretch is in a quite sorry state.  To
summarize:

1. Booting from ext4 partitions created with Debian stretch does not
   work, because ext4's 64bit feature is enabled by default (since
   Debian stretch) and not supported by syslinux [1].
2. Booting from btrfs does not work [2].
3. A bug in the isolinux isohybrid MBR causing boot failures with some
   old BIOS [3].
4. Booting from xfs does not work (which was already the case in
   jessie, so not a regression in stretch) [4].

You will notice that this does not really leave any modern Unix
filesystem for syslinux/extlinux to boot from… from the above problems,
1-3 are a regression compared to Debian jessie.

[1] https://bugs.debian.org/833057
[2] https://bugs.debian.org/865462
[3] I didn't think to open a separate bug against syslinux, which would
have been the right thing to do… the bug against debian-cd, which
is affected by this problem, holds relevant information:
https://bugs.debian.org/857597
[4] https://bugs.debian.org/803938


Problems 1 and 2 have an upstream fix each [5, 6] which is pretty small
in size.  I'm able to locally reproduce each of the two problems and
also confirm that the respective patches fix the problems.

Problem 3 also has a small and self-contained upstream fix.  And
although I have no way to test this myself, the built isohdpfx.bin file
(with the fix applied) is identical to a known-good and tested version.

Problem 4 is fixed upstream as well (which I have not tested yet), but
the number of changes for that is pretty high.  Since this is both a
large patch and a not a regression from jessie, I don't intend to fix
this in Debian stretch.

[5] 
http://git.zytor.com/syslinux/syslinux.git/commit/?id=af7e95c32cea40c1e443ae301e64b27f068b4915
[6] 
http://git.zytor.com/syslinux/syslinux.git/commit/?id=548386049cd41e887079cdb904d3954365eb28f3


The current version in unstable contains the patches for 2 and 3
already and I've just requested sponsorship for another update which
also fixes 1.  Provided we do not find any regressions related to the
fixes for problems 1-3, I would like to push those patches [7, 8, 9] to
the version in Debian stretch in the next point release.

I know the next point release is still ~6 weeks off, but bootloader
changes are obviously critical.  So I wanted to raise this issue well
before the deadline to get an idea how (or if) I should proceed:

* Is this a reasonable request, or are these changes too dangerous
  for a point release anyways?
* What kind of testing is required / expected so these changes can be
  considered?

Thanks
Lukas

[7] 
https://anonscm.debian.org/git/debian-cd/syslinux.git/tree/debian/patches/0016-btrfs-fix.patch?id=c61f3d0ef77ca726a0ff242c6ca6f1db90a8b9c6
[8] 
https://anonscm.debian.org/git/debian-cd/syslinux.git/tree/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch?id=c61f3d0ef77ca726a0ff242c6ca6f1db90a8b9c6
[9] 
https://anonscm.debian.org/git/debian-cd/syslinux.git/tree/debian/patches/0018-ext4-Fix-64bit-feature.patch?id=c61f3d0ef77ca726a0ff242c6ca6f1db90a8b9c6