Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
Followup-For: Bug #994274 X-Debbugs-Cc: lu...@schwaighofer.name, pk...@debian.org, timo.lindf...@iki.fi Hi Lukas, Philipp, Timo, Does reverting the removal[1] of 'efisetjmp.h' from 'efi.h' in src:gnu-efi produce successful results? That occurred between gnu-efi versions 3.0.9 and 3.0.13 if I read the upstream history correctly. (revert patch attached for convenience, although I'm not yet going to add the corresponding tag to this bug until we confirm whether it's useful) And if that headerfile does seem relevant: this issue may affect src:shim too. Thanks, James [1] - https://sourceforge.net/u/lslrt/gnu-efi/ci/486ba3c3bdd147b7d98159b9e650be60bce0f027/ --- a/apps/setjmp.c +++ b/apps/setjmp.c @@ -1,7 +1,6 @@ #include #include -#include EFI_STATUS efi_main( --- a/inc/efi.h +++ b/inc/efi.h @@ -75,6 +75,7 @@ #include "efiudp.h" #include "efitcp.h" #include "efipoint.h" +#include "efisetjmp.h" #include "efishell.h" #endif
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
Hi, here are the bisect results: # debbisect --cache cache -v --depends e2fslibs-dev,nasm,python3,uuid-dev,gnu-efi,debhelper-compat,binutils,gcc-multilib,build-essential 2020-02-01 2022-12-31 ./script.sh good timestamp 2020-02-01 00:00:00+02:00 was remapped to snapshot.d.o timestamp 2020-01-31 21:17:03+00:00 bad timestamp 2022-12-31 00:00:00+02:00 was remapped to snapshot.d.o timestamp 2022-12-30 15:17:41+00:00 INFO:root:using cache directory: cache snapshot timestamp difference: 1063.750440 days approximately 14 steps left to test #1: using cached results from debbisect.20200131T211703Z.log.good computation time left: 0:00:00.001066 approximately 13 steps left to test #2: using cached results from debbisect.20221230T151741Z.log.bad snapshot timestamp difference: 1063.750440 days computation time left: 0:00:01.426242 approximately 12 steps left to test #3: using cached result (was good) from debbisect.20210716T091727Z.log.good snapshot timestamp difference: 532.250162 days computation time left: 0:00:01.436556 approximately 11 steps left to test #4: using cached result (was good) from debbisect.20220408T091859Z.log.good snapshot timestamp difference: 266.249097 days computation time left: 0:00:01.549000 approximately 10 steps left to test #5: using cached result (was bad) from debbisect.20220818T100320Z.log.bad snapshot timestamp difference: 132.030799 days computation time left: 0:00:01.393391 approximately 9 steps left to test #6: using cached result (was good) from debbisect.20220613T085403Z.log.good snapshot timestamp difference: 66.048113 days computation time left: 0:00:01.362789 approximately 8 steps left to test #7: using cached result (was good) from debbisect.20220716T092224Z.log.good snapshot timestamp difference: 33.028426 days computation time left: 0:00:01.257209 approximately 7 steps left to test #8: using cached result (was bad) from debbisect.20220801T205040Z.log.bad snapshot timestamp difference: 16.477963 days computation time left: 0:00:01.060509 approximately 6 steps left to test #9: using cached result (was bad) from debbisect.20220724T092241Z.log.bad snapshot timestamp difference: 8.000197 days computation time left: 0:00:00.870132 approximately 5 steps left to test #10: using cached result (was good) from debbisect.20220720T092049Z.log.good snapshot timestamp difference: 4.001296 days computation time left: 0:00:00.721089 approximately 4 steps left to test #11: using cached result (was good) from debbisect.20220722T085138Z.log.good snapshot timestamp difference: 2.021562 days computation time left: 0:00:00.533613 approximately 3 steps left to test #12: using cached result (was bad) from debbisect.20220723T030313Z.log.bad snapshot timestamp difference: 0.758044 days computation time left: 0:00:00.365619 approximately 2 steps left to test #13: using cached result (was bad) from debbisect.20220722T150935Z.log.bad bisection finished successfully last good timestamp: 2022-07-22 08:51:38+00:00 first bad timestamp: 2022-07-22 15:09:35+00:00 the following packages differ between the last good and first bad timestamp: cpp 4:11.2.0-2 -> 4:12.1.0-1 cpp-12 (n.a.) -> 12.1.0-7 g++ 4:11.2.0-2 -> 4:12.1.0-1 g++-12 (n.a.) -> 12.1.0-7 gcc 4:11.2.0-2 -> 4:12.1.0-1 gcc-12 (n.a.) -> 12.1.0-7 gcc-12-multilib (n.a.) -> 12.1.0-7 gcc-multilib 4:11.2.0-2 -> 4:12.1.0-1 lib32asan8 (n.a.) -> 12.1.0-7 lib32gcc-12-dev (n.a.) -> 12.1.0-7 libasan8:amd64 (n.a.) -> 12.1.0-7 libgcc-12-dev:amd64 (n.a.) -> 12.1.0-7 libstdc++-12-dev:amd64 (n.a.) -> 12.1.0-7 libtsan2:amd64 (n.a.) -> 12.1.0-7 libx32asan8 (n.a.) -> 12.1.0-7 libx32gcc-12-dev (n.a.) -> 12.1.0-7 test upgrading cpp 4:11.2.0-2 -> 4:12.1.0-1... using cached result (was bad) from debbisect.20220722T085138Z.cpp.log.bad upgrading cpp triggered the problem additional packages that got upgraded/installed at the same time: cpp-12 (n.a.) -> 12.1.0-7 g++ 4:11.2.0-2 -> 4:12.1.0-1 g++-12 (n.a.) -> 12.1.0-7 gcc 4:11.2.0-2 -> 4:12.1.0-1 gcc-12 (n.a.) -> 12.1.0-7 gcc-12-multilib (n.a.) -> 12.1.0-7 gcc-multilib 4:11.2.0-2 -> 4:12.1.0-1 lib32asan8 (n.a.) -> 12.1.0-7 lib32gcc-12-dev (n.a.) -> 12.1.0-7 libasan8:amd64 (n.a.) -> 12.1.0-7 libgcc-12-dev:amd64 (n.a.) -> 12.1.0-7 libstdc++-12-dev:amd64 (n.a.) -> 12.1.0-7 libtsan2:amd64 (n.a.) -> 12.1.0-7 libx32asan8 (n.a.) -> 12.1.0-7 libx32gcc-12-dev (n.a.) -> 12.1.0-7 test installing cpp-12 12.1.0-7... using cached result (was bad) from debbisect.20220722T085138Z.cpp-12.log.bad upgrading cpp-12 triggered the problem test upgrading g++ 4:11.2.0-2 -> 4:12.1.0-1... using cached result (was bad) from debbisect.20220722T085138Z.g++.log.bad upgrading g++ triggered the problem additional packages that got upgraded/installed at the same time: cpp 4:11.2.0-2 -> 4:12.1.0-1 cpp-12 (n.a.) -> 12.1.0-7 g++-12 (n.a.) -> 12.1.0-7 gcc 4:11.2.0-2 -> 4:12.1.0-1 gcc-12 (n.a.) -> 12.1.0-7 gcc-12-multilib (n.a.) ->
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
Hi, I was just bisecting this and noticed that EFI booting stops working if I simply rebuild both syslinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 and gnu-efi 3.0.9-2. If I rebuild only syslinux but use the gnu-efi package from the archive I can boot successfully. This seems to indicate the that the boot issue is not related to the new gnu-efi version but something different, possibly a change in the toolchain. -Timo
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
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#994274: syslinux: FTBFS with gnu-efi 3.0.13
On Wed, Sep 15, 2021 at 12:34:53AM +0200, Lukas Schwaighofer wrote: > 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. It looks like Ubuntu added a patch to fix this slightly differently (adding to efi/main.c instead of adding [1]). With that it compiles as well. I don't quite understand the reference to glibc in the changelog[2], though. This is reusing syslinux's internal setjmp logic copied from klibc while gnu-efi rolled its own. It's also possible that by including the "wrong" header you get the wrong linkage against the wrong implementation. Could you try this out? Apparently I cannot test this within qemu OVMF (per [3] and it also didn't boot for me). Kind regards Philipp Kern [1] http://launchpadlibrarian.net/553034379/syslinux_3%3A6.04~git20190206.bf6db5b4+dfsg1-3_3%3A6.04~git20190206.bf6db5b4+dfsg1-3ubuntu1.diff.gz [2] https://launchpad.net/ubuntu/+source/syslinux/3:6.04~git20190206.bf6db5b4+dfsg1-3ubuntu1 [3] https://wiki.archlinux.org/title/syslinux#Limitations_of_UEFI_Syslinux
Bug#994274: syslinux: FTBFS with gnu-efi 3.0.13
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 pgpoVtnQq972G.pgp Description: OpenPGP digital signature
