Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13

[Lukas Schwaighofer]

Hi Philipp,

thanks for the pointers, I'll try to test the alternative patch you've
suggested within the week.


On Sun, 16 Oct 2022 09:20:37 +
Philipp Kern  wrote:

> Apparently I cannot test this within qemu OVMF (per [3] and it also
> didn't boot for me).

Interesting – this is how I tested syslinux efi builds in the past.
When filing this bug I was able to successfully boot with OVMF using
the builds currently installed in the archives, but not with the
freshly built versions.

Regards
Lukas

Bug#1004250: contents of syslinux binary package don't match syslinux-common

[Lukas Schwaighofer]

Hi Vangelis,

thanks for your report!

On Sun, 23 Jan 2022 17:32:34 +0200
Vangelis Koukis  wrote:

> After installing syslinux on a FAT32 fs:
> (...)
> I see the md5sum of ldlinux.c32 doesn't match the md5sum of
> /usr/lib/syslinux/modules/bios/ldlinux.c32:
> (...)
> 
> I don't know where syslinux/ldlinux.c32 comes from, I assume it's
> embedded in /usr/bin/syslinux, but
> /usr/lib/syslinux/modules/bios/syslinux.c32 comes from the
> syslinux-common binary package.

Your assumption is correct: ldlinux.c32 is embedded into the syslinux
installer binary and the embedded copy is copied into the target folder
during the installation.

syslinux.c32 does not get copied automatically by the installer. It
must have been copied either manually or by some other script from
/usr/lib/syslinux/modules/bios/syslinux.c32 (and thus the files are the
same).

> I understand there was a recent binary-only upload, which means the
> contents of the syslinux package no longer match the contents of
> the syslinux-common package.
> (...)
> The problem is that syslinux-common *also* contains binaries [the
> syslinux modules], and they no longer match.

I looked into this and found two more things that will cause the
ldlinux.c32 embedded into the installer to be different from the copy
shipped in the syslinux-common package even without the binary-only
non-maintainer upload (binNMU) you mentioned:

* Currently the debug symbols are stripped from the .c32 files after
  the build (dh_strip).  However the ldlinux.c32 copy that's
  embedded into the installer binaries gets included before the
  stripping and still includes the debug symbols.  This is arguably a
  bug.

* The syslinux-common package is an Architecture: all package. That
  means on both amd64 and i386 the same syslinux-common package is
  installed.  I don't believe the toolchains on both systems yield
  exactly the same .c32 files, and currently the Architecture: all
  packages seem to always get built on amd64.

> I think it makes sense to upload all syslinux binary packages from the
> same build to the repository, so everything aligns.

I hope to be able to make a new upload fairly soon (recently picked up
working on https://bugs.debian.org/994274 again), but for the reasons
above there will still be a mismatch between the files.

My understanding so far is that this is a cosmetic issue:  Both the
files built into the installer as well as the c32 module in
syslinux-common work.  Is there something more to this problem that I'm
missing?

Thanks and kind regards
Lukas


pgpE6wv1qcpTO.pgp
Description: OpenPGP digital signature

Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13

[Lukas Schwaighofer]

Source: syslinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: serious
Tags: ftbfs


With the new version of gnu-efi that was recently uploaded [1] to
unstable, syslinux fails to build from source.

So far I tried applying a simple fix from the upstream mailing list [2]
which result in a successful build, but the efi binaries from that
build are unbootable.


[1] 
https://tracker.debian.org/news/1257850/accepted-gnu-efi-3013git20210716269ef9d-2-source-into-unstable/
[2] https://www.syslinux.org/archives/2020-March/026621.html


pgpV2c5wQ0oG7.pgp
Description: OpenPGP digital signature

Updating gnu-efi to newest upstream version?

[Lukas Schwaighofer]

Hi Julian,

are you planning on updating GNU efi this release cycle?  The new
version will break compatibility (and definitely break syslinux
builds).  The compatibility breaking changes are all good by themselves
as far as I'm concerned (e.g. jmp_buf is compatible with the C standard
in newer versions [1]) and will allow me to drop some of the
not-so-nice patches to the syslinux Debian package.  (Some changes
to the newer gnu-efi were contributed by the main syslinux author.)

My personal preference would be to update to the newest version, and to
do so soon (if possible in experimental first).  I'd like to avoid this
update happening close to the freeze.

Thanks
Lukas

[1] https://sourceforge.net/p/gnu-efi/bugs/17/

Bug#957858: syslinux GCC-10 patch

[Lukas Schwaighofer]

I was kindly pointed to
  https://bugzilla.suse.com/show_bug.cgi?id=1166605#c5
privately (thanks!), which explains that __builtin_strlen is not
actually a "builtin" and relying on that without providing a strlen
implementation is not correct (and in fact broken with GCC-10).

I'm updating the patch's description accordingly and will upload this
to unstable.


pgp6T4f0gx07Q.pgp
Description: OpenPGP digital signature

Bug#944679: extlinux: Visual bugs while editing a long kernel command line

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Mikhail,

apologies for the long delay, there was a lot going on the before winter
holidays.

On Wed, 13 Nov 2019 17:59:13 +0100
Mikhail Morfikov  wrote:

> My current kernel command line is about 400-character long. When it
> was shorter, I didn't have any issues when I wanted to edit this line
> in the bootloader screen by selecting some entry and pressing "E".
> 
> I recently added some other kernel parameters to the cmd line, and I
> noticed many visual bugs in the bootloader screen. Basically with
> each cursor movement (back and forth), I get an extra text line in
> the screen output (copy of the current line scrolled up). Also
> characters in the cmd line disappear or change when I move the cursor
> back. The visual bugs make it almost impossible to edit the kernel
> cmd line. Also When I press the backspace key (or the back arrow key)
> for a longer period of time (let's assume I want to delete some
> parameters entirely from the line), I hear the hardware beeper which
> is really annoying.
> 
> I found out that the problem appears when I have more than 4 lines of
> text on the screen when editing the cmd line. So fifth (and next
> ones) will trigger the visual bugs, while 4 (and less) won't.

I'll look into this and try to reproduce this within the next few days.
To speed things up, can you provide me with your configuration?

If you're able to perform some test, can you check whether the
behavior is consistent when using a different UI modules (menu.c32 or
vesamenu.c32).

Thanks
Lukas

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

On Wed, 30 Oct 2019 22:41:48 +0100
Sven Joachim  wrote:

> On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:
> > I'm suspecting that there is somehow a mismatch between the version
> > of syslinux/extlinux used while installing (i.e. running `extlinux
> > -i`) and the c32 files installed on the medium.  
> 
> Indeed, this was the case.  While the version of syslinux installed in
> the boot sector was the one from Debian, the support files in the
> boot/syslinux directory came from the grml iso.  After replacing them
> with the files from /usr/lib/syslinux/modules/bios/ everything was
> fine.
> 
> > Can you check whether the c32 files installed on the medium
> > (probably in /boot/syslinux or /boot/extlinux) match the one
> > from /usr/lib/syslinux/modules/bios on the host system? If they do
> > match, can you re-run the syslinux installation from the host system
> > and then try again?  
> 
> They do not match, but I have a question: how would I get those files
> onto the boot medium with syslinux commands?  The naive command
> "syslinux -d boot/syslinux /dev/sdc1" (or whatever device instead of
> /dev/sdc1) does not do that, yet grml2usb apparently relies on it.

Unfortunately syslinux does not offer any "installer" to do that (nor
does the Debian package).  The admittedly poorly documented installation
procedure is more or less to run the installer and copy any modules you
need yourself to the correct folder.

`syslinux -d boot/syslinux /dev/sdc1` does not install any c32 modules.
This means any c32 modules present on your medium were copied by
grml2usb.  I don't know the details of how grml2usb installs syslinux,
but they need to make sure whatever is installed to the volume boot
record (`syslinux` or `extlinux` command) is consistent with the c32
modules.  Either both must come from the host system or both from the
installed medium.

Regards
Lukas

Bug#943845: syslinux-common: error messages with grml boot stick

[Lukas Schwaighofer]

Control: tags -1 + moreinfo

Hi Sven,

thanks for your report!

On Wed, 30 Oct 2019 18:58:12 +0100
Sven Joachim  wrote:

> Today I built myself a USB stick with grml on it (see #943838 for the
> problems I had with that).  When booting an old 32-bit laptop with
> this stick syslinux threw some error messages before its prompt:
> 
> ,
> | Undef symbol FAIL: x86_init_fpu
> | Failed to load libcom32.c32
> | Failed to load COM32 file vesamenu.c32
> | boot:
> `

I'm unable to reproduce this at the moment using the syslinux version
3:6.04~git20190206.bf6db5b4+dfsg1-1 .

I'm suspecting that there is somehow a mismatch between the version of
syslinux/extlinux used while installing (i.e. running `extlinux -i`)
and the c32 files installed on the medium.

Can you check whether the c32 files installed on the medium
(probably in /boot/syslinux or /boot/extlinux) match the one
from /usr/lib/syslinux/modules/bios on the host system? If they do
match, can you re-run the syslinux installation from the host system
and then try again? Is the image bootable when using `qemu-system-i386`?

If all of the above does not help narrow down the problem, can you
provide me with the necessary commands to build a similarly broken image
myself?

Thanks for your help
Lukas

Bug#938617: syslinux: Python2 removal in sid/bullseye

[Lukas Schwaighofer]

Thanks for the report.

I expect this to be an easy fix: "menugen.py" is the only python file
as far as I can tell.  It's only used during build time and is python3
compatible since syslinux version 4.07 according to the changelog.

Unless something goes wrong I should be able to close this with the
next upload.

Regards
Lukas

Bug#933299: isohybrid.pl should not be architecture dependent

[Lukas Schwaighofer]

Hi Timothy,

thanks for reporting.  The whole file organization of syslinux (both
which file is in which package, as well as the location of files) needs
improvement.  This is something I intend to work on during the bullseye
cycle.

As part of that, I'll also look into whether we need both the perl
script and the binary of "isohybrid" and in which package they should
be placed.  It'll still be a while until I get to it though (most
likely towards the end of this year).


@Thomas: If I remember correctly, isohybrid.pl only needs perl-base
(which is an essential package and does not require a dependency).
I'll double check that too.

Regards
Lukas

Bug#928386: syslinux: possible regression bug 'Undef symbol FAIL: memset'

[Lukas Schwaighofer]

Control: tags -1 + confirmed patch

Hi Andreas,

On Fri, 3 May 2019 14:21:06 +0200
Andreas Steinel  wrote:

> In version 6.04~git20190206.bf6db5b4+dfsg1-1, the bug that was closed
> in 6.04~git20171011.af7e95c3+dfsg1-6 is back - at least in the 64-bit
> UEFI part, legacy works fine:
> 
> Full log is:
> 
> Undef symbol FAIL: memset
> Failed to load libcom32.c32
> Failed to load COM32 file vesamenu.c32

Thanks for your report.  I've looked at it and can confirm that this
error is back :( .  The good news is only the backports version is
affected and not the version in buster (CC-ing Holger who is the
backports maintainer).

The problem is that the syslinux.efi binary uses the memset and memcpy
implementation from gnu-efi which are incompatible and cause the error
above. It should use the implementation from syslinux instead.

Since the linker has two symbols to choose from, I had added the
`-zmuldefs` flag.  My guess is that the linker from stretch picks the
"wrong" symbol.  I expected the linker would always pick the first one
it encounters which would be the "right" symbol (and that's what
happens in buster).

I've attached a modification of the 0005-gnu-efi-version-compatibility
patch.  Instead of using `-zmuldefs` I'm stripping the memset and memcpy
symbols from gnu-efi so there are no longer any duplicate symbols.
Using that I was able to build a version without that bug for backports.


Holger: Can you take care of updating the backports version? I've run
my little hacky regression-testing script on the modified backports
build and it passed all my tests.

Regards
Lukas
Repack libefi.a to not contain the memset and memcpy symbols to make sure the
implementation from syslinux is used and no multiple symbol definitions are
present.
---
 efi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/efi/Makefile
+++ b/efi/Makefile
@@ -43,8 +43,10 @@
 	fs/pxe/pxe.o fs/pxe/tftp.o fs/pxe/urlparse.o fs/pxe/dhcp_option.o \
 	fs/pxe/ftp.o fs/pxe/ftp_readdir.o fs/pxe/http.o fs/pxe/http_readdir.o)
 
+LIBEFI_STRIPPED = $(objdir)/libefi_stripped.a
+
 LIB_OBJS = $(addprefix $(objdir)/com32/lib/,$(CORELIBOBJS)) \
-	$(LIBEFI)
+	$(LIBEFI_STRIPPED)
 
 CSRC = $(sort $(wildcard $(SRC)/*.c))
 OBJS = $(subst $(SRC)/,,$(filter-out %wrapper.o, $(patsubst %.c,%.o,$(CSRC
@@ -73,6 +75,13 @@
 syslinux.so: $(OBJS) $(CORE_OBJS) $(LIB_OBJS)
 	$(LD) $(LDFLAGS) --strip-debug -o $@ $^ -lgnuefi -lefi
 
+$(LIBEFI_STRIPPED): $(LIBEFI)
+	cp $(LIBEFI) $(LIBEFI_STRIPPED)
+	ar x $(LIBEFI_STRIPPED) init.o
+	strip -N memset -N memcpy init.o
+	ar r $(LIBEFI_STRIPPED) init.o
+	rm init.o
+
 # We need to rename the .hash section because the EFI firmware
 # linker really doesn't like it.
 # $(OBJCOPY) --rename-section .gnu.hash=.sdata,load,data,alloc $^ $@

Bug#918915: syslinux-common: Undef symbol FAIL: exp in libgpl.c32 when trying to load hdt.c32

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Wolfgang,

thanks for reporting!

On Thu, 10 Jan 2019 15:27:07 +0100
Wolfgang Scheicher  wrote:

> After switching from stretch to buster i realized that the
> Hardware Detection Tool (HDT) in the Advanced options Boot menu fails
> with this error:
> 
> Undef symbol FAIL: exp
> Failed to load libgpl.c32
> Failed to load COM32 file hdt.c32
> boot:

This problem seems to have been introduced by compiling syslinux with a
newer GCC version.  There was a mail about this to the syslinux
Mailinglist containing a patch in August [1] which I somehow missed
(despite being subscribed…).

I've just built libgpl.c32 with the patch applied and based on the
`readelf` output I believe the patch fixes the problem.  I'll do an
actual test soon and if everything checks out upload a fixed version.

Regards
Lukas

[1] https://www.syslinux.org/archives/2018-August/026159.html

Re: syslinux-efi 6.04 bug?

[Lukas Schwaighofer]

Hi Carl,

Sorry for the delay, I was away from my e-mail on the weekend.

On Thu, 13 Dec 2018 23:21:38 -0600
Carl Karsten  wrote:

> This MR depends on (or blocked by?) it - should I note that somewhere?
> 
> https://salsa.debian.org/installer-team/debian-installer/merge_requests/7/commits

You definitely don't need to now since syslinux version
3:6.04~git20171011.af7e95c3+dfsg1-6 has migrated to testing earlier
today.

Regards
Lukas

Re: syslinux-efi 6.04 bug?

[Lukas Schwaighofer]

Hi Carl,

On Thu, 13 Dec 2018 14:01:19 -0600
Carl Karsten  wrote:

> What does it take to get this into buster"?
> https://packages.debian.org/sid/syslinux-common

I usually use https://tracker.debian.org/pkg/syslinux to answer this
kind of question, which tells us:

Not touching package due to block-udeb request by freeze (please
contact the d-i release manager if an update is needed)

If I understand this correctly, there is a temporary block while the
installer team is preparing a new (pre-)release of the installer for
buster.  It will be unblocked again once the installer is released which
I expect to be soon according to a mail from kibi@ (who is the d-i
release manager) to debian-release [1].

Regards
Lukas

[1] https://lists.debian.org/debian-release/2018/12/msg00252.html

Re: syslinux-efi 6.04 bug?

[Lukas Schwaighofer]

Hi Carl,

thanks for reporting!

On Mon, 3 Dec 2018 00:15:21 -0600
Carl Karsten  wrote:

> Undef symbol FAIL: memset
> Failed to load libcom32.c32

This is indeed a problem with the most recent syslinux version from
Debian.  I introduced it by taking the gnu-efi 3.0.8 compatibility patch
from Ubuntu.  I've just now uploaded a new version that should fix the
problem (Carl already tested it in a private conversation, thanks!).


@Mathieu:
Since you were the author if the patch that I took, I put you in CC.  I
believe that all syslinux versions in Ubuntu that link against
gnu-efi >= 3.0.8 are affected as well.  You can check by trying to use
the vesamenu.c32 module with the efi version of syslinux.  I expect it
will fail with "Undef symbol FAIL: module memset".

I'm now no longer filtering out the memset and memcpy implementations
from syslinux.  Instead I pass -zmuldefs to the linker to avoid the
duplicate symbol linking error.  That causes the linker to use the first
definition for memset and memcpy encountered which is the one from
syslinux.  This fixes the problem.  See
https://salsa.debian.org/images-team/syslinux/commit/2d1ebd6ab76fa39adb260a522e8da788d59bb5ec
for details.

Regards
Lukas

Syslinux in stretch-backports (Re: syslinux_6.04~git20171011.af7e95c3+dfsg1-4~bpo9+1_amd64.changes is NEW)

[Lukas Schwaighofer]

Hi Holger,

thanks for uploading syslinux to backports.  Was there a specific reason
for that I should be aware of?  I believe I fixed all the important
bugs in a stable point release [1].  In any case, if you think there is
value in maintaining syslinux in stretch backports, I'm happy to
maintain it there as well.  Let me know if you want me to.

Heads up:  I plan to upload a new version of syslinux on the weekend.
With the just uploaded gnu-efi 3.0.8 [2], syslinux needs a patch as it
otherwise FTBFS.  So with the next version depending on gnu-efi >=
3.0.8, keeping syslinux up to date in backports might become tricky
very soon.

Thanks
Lukas


[1] 
https://tracker.debian.org/news/887651/accepted-syslinux-3603dfsg-141deb9u1-source-into-proposed-updates-stable-new-proposed-updates/
[2] 
https://tracker.debian.org/news/994607/accepted-gnu-efi-308-1-source-into-unstable/

Bug#907805: syslinux.efi uses the TFTP server IP for the HTTP domain

[Lukas Schwaighofer]

Hi Marco,

On Sun, 2 Sep 2018 14:08:09 +0200
Marco d'Itri  wrote:

> When providing to syslinux.efi an http URL in option 67:
> 
> dhcp-option=option:bootfile-name,http://pxe.example.net/EFI/SYSLINUX/syslinux.efi
> 
> then it will try to download the modules like ldlinux.e64, the 
> configuration file and the payload by sending an HTTP request to the 
> TFTP server address (with pxe.example.net as virtual host) instead of 
> resolving pxe.example.net and using that IP as expected.

I checked the source code and found that efi network support was added
here:
http://repo.or.cz/syslinux.git/commit/fe283b78c973268f2d1f0309826ceeb5c9e8978d
The commit mentions in the TODO part that DNS resolve code is still
missing.

This still seems to be the case, since the pxe_dns function in efi/pxe.c
in the current HEAD
(http://repo.or.cz/syslinux.git/blob/HEAD:/efi/pxe.c, lines 38-49) will
`return 0` in all cases.

The connection to your TFTP server address is the fallback behavior
that's implemented for DNS resolve failures in core/fs/pxe/pxe.c
(http://repo.or.cz/syslinux.git/blob/HEAD:/core/fs/pxe/pxe.c, lines
251-256).

I will do a bit of testing and then forward your report to upstream.

Regards
Lukas

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Hi,

On Fri, 17 Aug 2018 21:43:50 +0200
Lukas Schwaighofer  wrote:

> Matthias: As the binutils maintainer, can you provide any help? I
> don't really know how to proceed… and since this was broken by a
> Debian revision, it's probably not an upstream problem? Thanks!

I've made some progress: If I discard the .note.gnu.property section
(which was not added since before binutils 2.31.1-2) I'm able to build
the package again. I've attached a patch to the linker scripts for
reference.

Unfortunately my tests shows that with this new build the efi binary no
longer works (at least when testing tianocore).  I have not yet
determined if this is also related to binutils and I suspect this is
actually a different issue. I'll keep you posted.
Author: Lukas Schwaighofer 
Description: Strip the .note.gnu.property section for the mbr. This section is
 added since binutils Debian version 2.31.1-2 and causes mbr.bin to grow in
 size beyond what can fit into the master boot record.
---
 mbr/i386/mbr.ld   | 1 +
 mbr/x86_64/mbr.ld | 1 +
 2 files changed, 2 insertions(+)

diff --git a/mbr/i386/mbr.ld b/mbr/i386/mbr.ld
index d14ba80..5368346 100644
--- a/mbr/i386/mbr.ld
+++ b/mbr/i386/mbr.ld
@@ -70,4 +70,5 @@ SECTIONS
   .debug_typenames 0 : { *(.debug_typenames) }
   .debug_varnames  0 : { *(.debug_varnames) }
   /DISCARD/ : { *(.note.GNU-stack) }
+  /DISCARD/ : { *(.note.gnu.property) }
 }
diff --git a/mbr/x86_64/mbr.ld b/mbr/x86_64/mbr.ld
index ae27d49..b8c0d89 100644
--- a/mbr/x86_64/mbr.ld
+++ b/mbr/x86_64/mbr.ld
@@ -69,4 +69,5 @@ SECTIONS
   .debug_typenames 0 : { *(.debug_typenames) }
   .debug_varnames  0 : { *(.debug_varnames) }
   /DISCARD/ : { *(.note.GNU-stack) }
+  /DISCARD/ : { *(.note.gnu.property) }
 }

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

On Sat, 18 Aug 2018 12:42:45 +0200
Lukas Schwaighofer  wrote:

> Unfortunately my tests shows that with this new build the efi binary
> no longer works (at least when testing tianocore).  I have not yet
> determined if this is also related to binutils and I suspect this is
> actually a different issue. I'll keep you posted.

That one was also a problem that was caused by a different binutils
version, but I managed to solve it as well :) . Will upload a new
version shortly.

[still wondering why the BTS ate my last message…]

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Hi,

the problem started with the upgrade from binutils 2.31.1-1 to
2.31.1-2. If I download the following 4 packages and install them, I
can build syslinux just fine:
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils-x86-64-linux-gnu_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils-common_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/binutils_2.31.1-1_amd64.deb
https://snapshot.debian.org/archive/debian/20180726T092202Z/pool/main/b/binutils/libbinutils_2.31.1-1_amd64.deb


Matthias: As the binutils maintainer, can you provide any help? I don't
really know how to proceed… and since this was broken by a Debian
revision, it's probably not an upstream problem? Thanks!

Regards
Lukas

Bug#906414: syslinux: FTBFS in buster/sid (mbr.bin: too big (452 > 440))

[Lukas Schwaighofer]

Control: tags -1 + confirmed

Hi Santiago,

I can confirm the build failures. The same error also happens when
building syslinux on buster from upstream's git repository.

I'll try to find out which dependency change caused the size of mbr.bin
to grow and will then probably need to work with upstream to get this
fixed.

Thanks for your report
Lukas

Re: syslinux: link against gnu-efi >= 3.0.6, please review/sponsor

[Lukas Schwaighofer]

Hi Steve,

>Everything else looks ok, but I'm curious - why are we using
>Build-Depends-Indep for gnu-efi?

Because it's unavailable on x32 and only needed for the syslinux-efi package 
wich is arch independent.

Arch indep packages are built on amd64 on the buildds so the dependency can be 
resolved.

Regards
Lukas

syslinux: link against gnu-efi >= 3.0.6, please review/sponsor

[Lukas Schwaighofer]

Hi,

the maintainer of gnu-efi has updated the package to 3.0.6 in
experimental (I had actually asked for this in #880506 [1]).  The new
version of gnu-efi causes syslinux to FTBFS.

I have reviewed and added the patches from upstream's mailing list to
restore compatibility with the new gnu-efi version.  In my tests
everything went fine.

While I have no idea how this transition will be handled by the release
team (especially considering that none of the other reverse build
dependencies of gnu-efi has a "Built-Using" control field), I think
it's a good idea to upload this new version of syslinux to experimental.

I've pushed my changes the debian/experimental branch in the git
repository:
  https://anonscm.debian.org/git/debian-cd/syslinux.git
Please review my changes (and sponsor if you're satisfied).

Thanks
Lukas

[1] https://bugs.debian.org/880506


pgpb24hJTLX0Y.pgp
Description: OpenPGP digital signature

please sponsor syslinux jessie-pu (Re: Bug#880123: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1)

[Lukas Schwaighofer]

Hi,

the release team has approved the proposed syslinux jessie-pu [1].
Please sponsor the upload.  It can be found in the debian/jessie branch
of the git repository:
  https://anonscm.debian.org/git/debian-cd/syslinux.git

Thanks
Lukas

[1] https://bugs.debian.org/880123


pgpzzBUigrING.pgp
Description: OpenPGP digital signature

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

Hi again,

I just checked the contents of the
 /etc/kernel/post{inst,rm}.d/zz-extlinux
files which are identical:

#!/bin/sh

set -e

# Exit if extlinux was removed (!= purged)
if [ -x /usr/sbin/extlinux-update ]
then
# Update extlinux configuration
extlinux-update
fi

Since the file is harmless enough when /usr/sbin/extlinux-update does
not exist, I think removing the file in sid/testing will be good enough.

Sorry for the noise, should have checked that file earlier.

Regards
Lukas

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

On Tue, 7 Nov 2017 21:48:04 +0100
Lukas Schwaighofer <lu...@schwaighofer.name> wrote:

> 0. The syslinux installer is part of the syslinux binary package

That should have been:
0. The syslinux installer is part of the *extlinux* binary package

Bug#866343: extlinux: Files in /etc/kernel/ not removed during upgrade

[Lukas Schwaighofer]

Hi Laurent,

thanks for reporting this problem.  Leftover files in /etc/kernel/*.d
are bad…  I made a bit of research and found out the following, all of
which happened during the jessie release cycle:

0. The syslinux installer is part of the syslinux binary package
1. Version 3:6.03~pre1+dfsg-2: The installer was moved from the
   extlinux binary package to a newly introduced syslinux-stuff binary
   package
2. Version 3:6.03~pre19+dfsg-1: The syslinux-stuff binary package was
   dropped (completely removing the extlinux installer from Debian)

So, as far as I can tell, every system that has syslinux since
pre-jessie (and was never reinstalled since) will have those leftover
files.

Fixing this now in unstable feels somewhat in vain… I will ask for
advise on how to best deal with this issue.  For now I wanted to
document my findings.

Regards
Lukas

Bug#814459: pxelinux: doesn't use gPXE/iPXE anymore to load files

[Lukas Schwaighofer]

Hi Christian,

thanks for reporting this problem.  I've only recently taken over
maintenance of syslinux/pxelinux in the Debian CD Group.  Sorry you had
to wait more than a year for a response…

We recently uploaded a pre-release of syslinux 6.04 to Debian
experimental. Amongst other things the changelog mentions:

core: Re-add gPXE/iPXE support for HTTP on pxelinux.0 (Gene Cumm).

So I hope the problem has been resolved, but I didn't verify that yet.
In case you still have a suitable setup, would you mind testing the
version in experimental?

Thanks
Lukas

Re: syslinux version for experimental, please sponsor

[Lukas Schwaighofer]

Hi,

thanks for sponsoring!

It bothers me (probably more than it should) that syslinux still does
not build reproducibly on i386 [1].  Ironically, I cannot reproduce the
problem locally (i.e. if I create an i386 schroot and use that to build
the package, it still builds reproducibly on my machine).  So I don't
know of any way for testing this besides uploading updated versions.

Comparing the i386 build logs from reproducible-builds.org, I found two
instances of `ar` which were given object files in different orders.
I've fixed those.  Everything else in the build log looks identical to
me, so I hope this will finally allow syslinux to build reproducibly
on i386 as well.

Would you mind uploading once more?  I've updated the
debian/experimental branch accordingly…

Thanks again
Lukas

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/i386/syslinux.html

Re: syslinux version for experimental, please sponsor

[Lukas Schwaighofer]

Hi,

On Thu, 2 Nov 2017 13:36:55 +
Steve McIntyre  wrote:
> gbp:error: Error creating
> syslinux_6.04~git20171011.af7e95c3+dfsg1.orig.tar.xz: Pristine-tar
> couldn't checkout
> "syslinux_6.04~git20171011.af7e95c3+dfsg1.orig.tar.xz": fatal: Path
> 'syslinux_6.04~git20171011.af7e95c3+dfsg1.orig.tar.xz.delta' does not
> exist in 'refs/heads/pristine-tar'
> 
> Did you forget to push the pristine-tar branch maybe?

I just checked, it was already pushed… maybe you did not update your
local pristine-tar branch?  You can check the output of:

git diff pristine-tar origin/pristine-tar

Thanks
Lukas

syslinux version for experimental, please sponsor

[Lukas Schwaighofer]

Hi,

I've packaged a new version of syslinux based on the current syslinux
git state.  This allows dropping 12 of the patches of our patch queue,
leaving only few of which I have forwarded most to upstream :) .  While
I would prefer upstream releasing a new version or pre-release, I think
that having such a huge patch queue is worse than packaging syslinux
from its git repository directly.  I've experimented quite a bit with
this version and have not encountered any problems so far.

Apart from updating to a new version, the only notable change is that I
added upstream's diagnostic utilities and special purpose MBRs (which
are needed in a few special cases) to the package.  This should give us
more options when dealing with bug reports.  The files only have
negligible size so I decided against introducing a new binary package
for them.

I hope that this update also fixes the unreproducible builds on i386
reported by the reproducible builds project.  At least the instances
where "ar" is passed object files in a non-deterministic order that I
found in the build logs should now be deterministic.


I do not want to upload a new version of syslinux to unstable until the
next stretch point release:  I want to keep the codebase in testing
similar to the stretch-pu so we get more testing of that version.

I've chosen 6.04~git… as a version number, since upstream has already
increased the version number to 6.04.  The version number allows me to
update to 6.04~preN if upstream publishes another pre-release (without
having to change the epoch).

The version for experimental is available in the git repository from the
debian/experimental branch which I've just pushed:
https://anonscm.debian.org/git/debian-cd/syslinux.git

Thank you
Lukas

syslinux: please sponsor stretch-pu

[Lukas Schwaighofer]

Hi,

I need a sponsor for the stretch-pu I've prepared for syslinux (version
3:6.03+dfsg-14.1+deb9u1).  It's in the debian/stretch branch of the git
repository:
https://anonscm.debian.org/git/debian-cd/syslinux.git

The release team has already approved the request [1].

Thank you
Lukas

[1] https://bugs.debian.org/879773


pgpYSpvO3a2u6.pgp
Description: OpenPGP digital signature

Bug#880123: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1

[Lukas Schwaighofer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
X-Debbugs-CC: debian-cd@lists.debian.org, debian-b...@lists.debian.org, 
k...@debian.org

Dear release team,

I hereby ask for permission to update the syslinux package in jessie as
well.  The update fixes a bug in the isolinux isohybrid MBR causing boot
failures with some old BIOS [1].

The bug is already fixed in unstable/testing and the update for stretch,
which also includes this fix, has just been approved [2].

I tested the build in an sbuild jessie chroot and the updated package
builds the correct isohdpfx.bin file (identical to the one currently in
unstable/testing).  The debdiff is attached.

Thank you
Lukas

[1] https://bugs.debian.org/879004
[2] https://bugs.debian.org/879773
diff -Nru syslinux-6.03+dfsg/debian/changelog syslinux-6.03+dfsg/debian/changelog
--- syslinux-6.03+dfsg/debian/changelog	2015-08-18 17:23:09.0 +0200
+++ syslinux-6.03+dfsg/debian/changelog	2017-10-29 19:12:43.0 +0100
@@ -1,3 +1,11 @@
+syslinux (3:6.03+dfsg-5+deb8u2) jessie; urgency=medium
+
+  * Add patch from upstream to fix boot problem for old BIOS firmware from
+around 2005 by correcting the C/H/S order (thanks Thomas Schmitt,
+Closes: #879004).
+
+ -- Lukas Schwaighofer <lu...@schwaighofer.name>  Sun, 29 Oct 2017 19:12:43 +0100
+
 syslinux (3:6.03+dfsg-5+deb8u1) jessie; urgency=low
 
   * Cherry-pick upstream patches that fix booting on some Chromebooks
diff -Nru syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch
--- syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch	1970-01-01 01:00:00.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/0017-isohdpfx.S-correct-heads-sectors.patch	2017-10-29 19:12:43.0 +0100
@@ -0,0 +1,50 @@
+From: Martin Str|mberg <a...@ludd.ltu.se>
+Date: Sun, 26 Mar 2017 07:32:11 -0400
+Subject: mbr/isohdpfx.S: correct stack for heads/sectors
+
+Heads and sectors were pushed in reverse order per isolinux.asm
+(bb519a95 reversed the order of heads/sectors on the stack).
+
+If anything goes wrong, clear CX in case it contains garbage.
+
+Signed-off-by: Gene Cumm <gene.c...@gmail.com>
+
+Bug-Debian: https://bugs.debian.org/879004
+Origin: upstream, quashed two commits together:
+ http://git.zytor.com/syslinux/syslinux.git/commit/?id=32c09027423f61c305e2423e52f5f69ecad8e2c0
+ http://git.zytor.com/syslinux/syslinux.git/commit/?id=8739e2ff9ba3f92652c8df846924fd00e1ce2753
+---
+ mbr/isohdpfx.S | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S
+index 17e1efe..4b107e4 100644
+--- a/mbr/isohdpfx.S
 b/mbr/isohdpfx.S
+@@ -167,20 +167,22 @@ next:
+ 	   read_sector_cbios: movb $0x42, %ah ;  jmp read_common */
+ 	movl	$0xeb42b4+((read_common-read_sector_cbios-4) << 24), \
+ 		(read_sector_cbios)
+-	jmp	1f
++	jmp	2f
+ 1:
++	xor	%cx, %cx	/* Clear EBIOS flag. */
++2:
+ 	popw	%dx
+ 	pushw	%cx		/* EBIOS flag */
+ 
+ 	/* Get (C)HS geometry */
+ 	movb	$0x08, %ah
+ 	int	$0x13
+-	andw	$0x3f, %cx	/* Sector count */
+ 	popw	%bx		/* EBIOS flag */
+-	pushw	%cx		/* -16: Save sectors on the stack */
+ 	movzbw	%dh, %ax	/* dh = max head */
+ 	incw	%ax		/* From 0-based max to count */
+-	pushw	%ax		/* -18: Save heads on the stack */
++	pushw	%ax		/* -16: Save heads on the stack */
++	andw	$0x3f, %cx	/* Sector count */
++	pushw	%cx		/* -18: Save sectors on the stack */
+ 	mulw	%cx		/* Heads*sectors -> sectors per cylinder */
+ 
+ 	pushw	%bx		/* -20: EBIOS flag */
diff -Nru syslinux-6.03+dfsg/debian/patches/series syslinux-6.03+dfsg/debian/patches/series
--- syslinux-6.03+dfsg/debian/patches/series	2015-08-18 17:13:25.0 +0200
+++ syslinux-6.03+dfsg/debian/patches/series	2017-10-29 19:12:43.0 +0100
@@ -4,3 +4,4 @@
 0004-gnu-efi-git.patch
 0005-load-linux-correct-type.patch
 0006-load-linux-protected-mode.patch
+0017-isohdpfx.S-correct-heads-sectors.patch


pgpKrK67i0DLi.pgp
Description: OpenPGP digital signature

Bug#879773: stretch-pu: package syslinux/3:6.03+dfsg-14.1+deb9u1

[Lukas Schwaighofer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: stretch
Severity: normal
X-Debbugs-CC: debian-cd@lists.debian.org, debian-b...@lists.debian.org, 
k...@debian.org


Dear release team and other involved parties,

I hereby ask for permission to update the syslinux package in stretch.
There has been a short discussion about this on debian-cd already [1].
The request is about fixing the following three problems:

1. Booting from ext4 filesystems created with Debian stretch does not
   work, because ext4's 64bit feature is enabled by default (since
   Debian stretch) and not supported by syslinux [2].
2. Booting from btrfs does not work either for a similar reason [3].
3. A bug in the isolinux isohybrid MBR causing boot failures with some
   old BIOS [4].

[1] https://lists.debian.org/debian-cd/2017/10/msg00032.html
[2] https://bugs.debian.org/833057
[3] https://bugs.debian.org/865462
[4] https://bugs.debian.org/879004

Problems 1 and 2 are regressions from jessie (due to changes in default
options when creating ext4/btrfs filesystems), while problem 3 affects
jessie as well.  The fix for each of the three bugs has been
cherry-picked from upstream and has a reasonably sized diff.  Debian
testing and unstable already have the fixes.

I've tested the proposed version.  In those tests, the problems 1 and 2
were solved as expected.  As for problem 3, I've verified that the
isohdpfx.bin image built is identical to a known good and tested
version.  Additionally we got a report that the debian-cd images for
testing (which are built using the fixed isohdpfx.bin) boot correctly on
affected hardware [5].

A debdiff of the proposed update is attached.  Alternatively it's also
available from the debian/stretch branch of the git repository [6].

Thank you for your time and consideration
Lukas

PS: If this request gets ACKed, I also intend to fix the isohybrid MBR
in jessie (as advised by Steve McIntyre).

[5] https://bugs.debian.org/857597#117
[6] https://anonscm.debian.org/git/debian-cd/syslinux.git


syslinux_6.03+dfsg-14.1+deb9u1.debdiff
Description: Binary data


pgpfHiYtiUBQI.pgp
Description: OpenPGP digital signature

Bug#803938: extlinux: boot from xfs partition not working

[Lukas Schwaighofer]

Hi Marek,

I've recently taken over maintenance of syslinux/exlinux as part of
the Debian CD Group, so I it's time to have a look at my own bug report.
Thanks for providing the link to the upstream changelog :) .

I've just compiled the most recent version of syslinux from git.  It
turns out that even this version can only boot from XFS partitions if
an MBR partition scheme is used.  With a GPT partition scheme, booting
is still not possible (same error as above).  I only then noticed that,
according to the wiki [1], syslinux only supports booting from XFS in
MBR partition schemes:

As of Syslinux 6.03, an XFS partition in an "MBR" partition scheme
is supported.

I've cloned the bug to track the MBR [2] and GPT [3] problems
separately.  I should be able to close the XFS+MBR problem eventually.
Since XFS+GPT is not yet supported upstream and it doesn't look like
anyone is actively working on that at the moment, I doubt that can be
fixed anytime soon.

Regards
Lukas

[1] http://www.syslinux.org/wiki/index.php?title=Filesystem#XFS
[2] https://bugs.debian.org/803938
[3] https://bugs.debian.org/879543

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: sponsor request

[Lukas Schwaighofer]

Hi KiBi,

On Wed, 18 Oct 2017 01:57:45 +0200
Cyril Brulebois  wrote:

> I've just sponsored your upload, thanks!
> 
> Please push an appropriate tag for this commit:
>   ce704619daaa2f973e6d569c0e0ac713984529e6

Thanks, I've just pushed the tag!

> PS: I only read debian-cd@ infrequently when my attention is drawn to
> it, like the cc in the subsequent mail. Please cc me if you need
> me to see a specific reply/subthread.

Sure, will do.

Regards
Lukas


pgpkBBi0wfwnq.pgp
Description: OpenPGP digital 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

syslinux: sponsor request

[Lukas Schwaighofer]

Hi,

sorry to ask for yet another sponsoring so soon.  Two days ago upstream
merged the fix for allowing extlinux to boot from ext4 filesystems with
the 64bit feature enabled, which I'd like to get uploaded soon.

With the patch applied, I can no longer reproduce the ext4+64bit
problem, so I'm confident the fix works.  Booting from ext2/3 and btrfs
still works fine. I've updated syslinux in our git repository
accordingly:

https://anonscm.debian.org/git/debian-cd/syslinux.git


Apart from the ext4 fix, I've also dropped my own patch for linking
against the newer gnu-efi version in favor of the cleaner one that was
proposed upstream.

I've set urgency to medium this time, as I don't want to delay the
creation of testing images not suffering from Bug #857597 [1].

Thanks
Lukas

[1] https://bugs.debian.org/857597

Bug#833057: extlinux: cannot boot from ext4 filesystems with 64bit feature enabled

[Lukas Schwaighofer]

Control: retitle -1 extlinux: cannot boot from ext4 filesystems with 64bit 
feature enabled
Control: tags -1 - moreinfo + confirmed upstream

Hi,

thanks for reporting and working on this issue.  I'm certain the
experienced problem is due to the 64bit feature in ext4, which is set by
default when using `mkfs.ext4` since Debian stretch but not yet
supported by syslinux (as Peter has already pointed out).  I'm adjusting
the bug accordingly.

There is also good news:  Upstream pushed a fix for this problem
yesterday [1], I will test the fix and prepare a new Debian version
soon.

Regards
Lukas


[1] 
http://git.zytor.com/syslinux/syslinux.git/commit/?id=af7e95c32cea40c1e443ae301e64b27f068b4915

Bug#857597: debian-cd: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

[Lukas Schwaighofer]

Hi Thomas,

thanks for pushing this forward :) .

On Sat, 14 Oct 2017 19:53:46 +0200
"Thomas Schmitt"  wrote:

> now that a new set of SYSLINUX packages is announced by
> (...)
> what to do with this bug report ?
> Re-assign to package "syslinux" and then close it ?

Well, that bug is only solved once we have CD images that are no longer
affected by this bug.  The first weekly testing images will be
available earliest in two weeks time (since I've set the testing
migration to 10 days and assuming no new RC bugs are discovered during
that period).

After that we still need to decide whether we also want to fix this for
the next point release.  If I understand the CD build process
correctly, the images for the next point release will only get the fix
if we also update syslinux in stretch.

> Is there a way to obtain that package and extract the file with
> vanilla tools which are not debian-specific ?

Well, deb package can be downloaded from 

http://ftp.debian.org/debian/pool/main/s/syslinux/isolinux_6.03+dfsg1-1_all.deb
though the link will no longer work after a newer version of syslinux
is uploaded to unstable.

Since deb is an ar-archive (containing more archives), you can extract
the file as follows on any *nix systems which have ar and tar commands:

ar p isolinux_6.03+dfsg1-1_all.deb data.tar.xz | \
tar xJOf - ./usr/lib/ISOLINUX/isohdpfx.bin > isohdpfx.bin

Regards
Lukas

Re: syslinux: sponsor wanted (Re: syslinux progress & reviews)

[Lukas Schwaighofer]

On Sat, 7 Oct 2017 18:29:23 +0200
Lukas Schwaighofer <lu...@schwaighofer.name> wrote:

> I've not gotten around to test EFI booting yet.

I've now successfully tested the 64 bit efi variant using qemu and
TianoCore.  The 32 bit variant is yet untested, because Debian's edk2
source package does not produce the needed files.

I will try to build the required binaries for testing 32 bit efi
booting soon.  In case successful I will file a wishlist bug against
edk2 asking the maintainers to also compile and provide the 32 bit
firmware images.

Thanks & Regards
Lukas

syslinux: sponsor wanted (Re: syslinux progress & reviews)

[Lukas Schwaighofer]

On Wed, 4 Oct 2017 10:48:59 +0100
Steve McIntyre  wrote:

> >I'd be happy if someone took the time to review the changes I made so
> >far in git:
> >https://anonscm.debian.org/git/debian-cd/syslinux.git
> >(...)
> 
> All looks sane enough so far!

Thanks for taking the time to look through the changes.  I have tested
a few different cases for BIOS boot without running into problems.

I've also started to think how I could automate a few tests.  While I
don't have an idea on how to check for regressions with old/broken
BIOS/EFI implementations, bugs like failing to boot from a specific
filesystem (e.g. BTRFS #865462 [1]) should be testable using qemu/kvm.

I've not gotten around to test EFI booting yet.  But since the existing
package uses pre-compiled binary code, which is to my understanding a
policy violation, it needs updating anyways.  I will start testing boot
with EFI soon…


I think the version in git is ready for an upload to unstable.  If
you'd rather target experimental instead until I've tested EFI boot,
feel free to change it.  I'd appreciate if someone sponsored this
upload.

Thanks & have a good point release
Lukas

[1] https://bugs.debian.org/865462

Re: syslinux progress & reviews

[Lukas Schwaighofer]

Hi Thomas,

On Wed, 04 Oct 2017 10:20:13 +0200
"Thomas Schmitt"  wrote:
> I wonder whether the new binary isohdpfx.bin is byte-identical to the
> tested MBR with the fix:
>http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324

I just checked: it is.  So far so good :) .

> Another question is whether the repaired MBR should be offered for
> separate download and whether repairing of older ISOs should be
> advertised in
>   https://www.debian.org/CD/faq/
> as sketched in
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857597#90

I obviously can't decide that.  In any case this should wait a bit
until an updated package is uploaded and tested thoroughly.

Thanks for the warning regarding EFI boot from cdrom with syslinux.

Regards
Lukas

syslinux progress & reviews

[Lukas Schwaighofer]

Hi team,

I've worked a bit on syslinux now.  I've fixed one notable problem that
I've found:  The current syslinux package (statically) links against a
pre-compiled version of gnu-efi (supplied in the syslinux source
package).

I also made a few more improvements apart from cleanup:
* the package now builds reproducibly (still needs the same build path
  though)
* added patches from upstream to fix:
  - boot problems for pre-2005 BIOS computers, see #857597 [1]
  - boot failure from btrfs, see #865462 [2]

I think the two new patches are quite small and might be suitable to
be added to stretch in a point release, after we've tested them
thoroughly.

For now I've made sure that the same files are installed into the same
binary packages (using the same paths).  There's some room for
improvement here, e.g. #819973 [3], but I'd like to avoid any "breaks
my scripts" dragons for now.


I'd be happy if someone took the time to review the changes I made so
far in git:
https://anonscm.debian.org/git/debian-cd/syslinux.git
My plan now is to test a few boot scenarios with this package myself
and probably ask you to sponsor an upload to either unstable or
experimental soon (weekend).

I consider the updated 6.03 version an intermediate step which, amongst
other things, allows us to check if the cherry picking the two commits
above fixes the problems as expected (and doesn't cause regressions).  I
intend upgrade to the pre-release for 6.04 in unstable/testing later.

Thanks
Lukas

[1] https://bugs.debian.org/857597
[2] https://bugs.debian.org/865462
[3] https://bugs.debian.org/819973

Re: Adoption of syslinux

[Lukas Schwaighofer]

HI Thomas,

On Thu, 28 Sep 2017 22:47:16 +0200
"Thomas Schmitt"  wrote:

> good to know that the SYSLINUX/ISOLINUX packages are maintained again.

Well, I'm only starting with the adoption, I hope I can manage :) .

> Please consider to also adopt bug #857597 from package debian-cd:
> (...)

Thanks for bringing this to my attention, I'll have a closer look soon.
It surely won't make it for the upcoming 9.2 point release, but
possibly the one after that.

Regards
Lukas

Joining the team, working on syslinux

[Lukas Schwaighofer]

Hi CD Team,

I've decided to try my best to maintain syslinux.  I've just had a
short conversation with Steve and Cyril on irc and we have agreed
that I should join the Debian CD team and make syslinux a team
maintained package.

I've only worked on Debian packages for about half a year now, but I
feel comfortable with git-buildpackage, debhelper and friends by
now :) .  I've mostly been active in the pkg-security team so far and I
was looking for another interesting area I could start contributing to.

I like playing around with "low level" stuff (I'm very happy about my
X230 that uses coreboot and has the management engine removed).
While I don't use syslinux extensively, I have a few use cases (and
also problems [1]), and I'm also looking forward to expand my
knowledge with this new task.

I'm always happy to receive any helpful advice/critique, so let me
know when I'm doing something wrong or you have a better idea for $foo.
I'll need your help getting new versions of syslinux uploaded soon
enough, since I'm not a DD (but probably a DM soon [2]).

Cheers
Lukas

[1] https://bugs.debian.org/803938
[2] https://nm.debian.org/process/303

Re: Bug#805268: Adoption of syslinux

[Lukas Schwaighofer]

Control: owner -1 Debian CD Group 
Control: retitle -1 ITA: syslinux -- collection of bootloaders (DOS FAT and 
NTFS bootloader)

Hi,

I intend to work on syslinux as part of the Debian CD Group.  I'm open
to team maintenance and will probably need help every now and then
anyways, so if you read this and also want to step in just let me
know :) .

Regards
Lukas