[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Also affects: binutils (Ubuntu) Importance: Undecided Status: New ** Changed in: binutils (Ubuntu) Status: New => In Progress ** Changed in: binutils (Ubuntu) Assignee: (unassigned) => Balint Reczey (rbalint) ** Changed in: gzip (Ubuntu) Status: Invalid => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
While this is a bug in WSL's ELF loader I located to problem in binutil's strip and after the fix passed my testing I'll send it upstream and also SRU it to Eoan to let us rebuild affected packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Bug watch added: Sourceware.org Bugzilla #25237 https://sourceware.org/bugzilla/show_bug.cgi?id=25237 ** Also affects: binutils via https://sourceware.org/bugzilla/show_bug.cgi?id=25237 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Unknown Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Launchpad has imported 1 comments from the remote bug at https://sourceware.org/bugzilla/show_bug.cgi?id=25237. If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. On 2019-11-30T23:38:36+00:00 Balint Reczey wrote: Created attachment 12095 Patch adjusting offset to stay in the file This itself was tolerated for long time, but WSL's ELF loader crashes due to the offset and it seems to be easy to fix. Reply at: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/comments/7 ** Changed in: binutils Status: Unknown => New ** Changed in: binutils Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: New Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Changed in: binutils Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Won't Fix Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Changed in: binutils Status: Won't Fix => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
The offset pointing past EOF is observed only in gzip and in several debug files: $ grep -v dbg wrong-offsets gzip_1.10-0ubuntu3_amd64.deb: /bin/gzip libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: /usr/lib/libhugetlbfs/tests/obj64/xB.linkhuge libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: /usr/lib/libhugetlbfs/tests/obj64/xB.linkhuge_nofd libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: /usr/lib/libhugetlbfs/tests/obj64/xB.linkshare libhugetlbfs-tests_2.21-0ubuntu1_amd64.deb: /usr/lib/libhugetlbfs/tests/obj64/zero_filesize_segment After binutils is backported only gzip needs to be rebuilt. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
I've forwarded the binutils patch to the mailing list, too: https://sourceware.org/ml/binutils/2019-12/msg00104.html . -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Description changed: + [Impact] + + * Running gzip on WSL1 results in the following error: +$ gzip +-bash: /bin/gzip: cannot execute binary file: Exec format error + * The error occurs frequently in package updates and makes gzip inoperable on WSL1 + * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. + + [Test Case] + + * Check the gzip binary for wrong offset: + $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' + + [ Regression Potential ] + + * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. + * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. + + [Originial Bug Text] + Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: - Installed: 1.10-0ubuntu3 - Candidate: 1.10-0ubuntu3 - Version table: - *** 1.10-0ubuntu3 500 - 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages - 100 /var/lib/dpkg/status + Installed: 1.10-0ubuntu3 + Candidate: 1.10-0ubuntu3 + Version table: + *** 1.10-0ubuntu3 500 + 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages + 100 /var/lib/dpkg/status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Hello Hayden, or anyone else affected, Accepted binutils into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/binutils/2.33-2ubuntu1.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: binutils (Ubuntu Eoan) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: In Progress Status in gzip package in Ubuntu: In Progress Status in binutils source package in Eoan: Fix Committed Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.n
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
This bug was fixed in the package binutils - 2.33.1-6ubuntu1 --- binutils (2.33.1-6ubuntu1) focal; urgency=medium * Merge with Debian; remaining changes: - Build from upstream sources. - Don't generate control file entries for any native mips* packages. * Cherry-pick from binutils master branch: PR25237, set no file contents PT_LOAD p_offset to first page (LP: #1843479) binutils (2.33.1-6) unstable; urgency=medium * Update from the binutils 2.33 branch: - [gas] Implement .cfi_negate_ra_state directive (AArch64). -- Balint Reczey Fri, 13 Dec 2019 16:24:27 +0100 ** Changed in: binutils (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: In Progress Status in binutils source package in Eoan: Fix Committed Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Hello Hayden, or anyone else affected, Accepted gzip into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gzip/1.10-0ubuntu3.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: gzip (Ubuntu Eoan) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: In Progress Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Committed Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
This bug was fixed in the package gzip - 1.10-0ubuntu4 --- gzip (1.10-0ubuntu4) focal; urgency=high * Rebuild with binutils 2.33.1-6ubuntu1 (LP: #1843479) - Build-depend on binutils (>= 2.33.1-6ubuntu1) * Pass -fstack-protector to mingw build to fix FTBFS -- Balint Reczey Fri, 13 Dec 2019 16:41:46 +0100 ** Changed in: gzip (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Committed Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Verified gzip 1.10-0ubuntu3.1 rebuilt with binutils (2.33-2ubuntu1.1): root@ee-motd-verify:~# dpkg -l gzip Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--= ii gzip 1.10-0ubuntu3.1 amd64GNU compression utilities root@ee-motd-verify:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' && echo ok ok root@ee-motd-verify:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE Elf file type is DYN (Shared object file) Entry point 0x4190 There are 14 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x40 0x0040 0x0040 0x000310 0x000310 R 0x8 INTERP 0x000350 0x0350 0x0350 0x1c 0x1c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x00 0x 0x 0x0027a0 0x0027a0 R 0x1000 LOAD 0x003000 0x3000 0x3000 0x00ea05 0x00ea05 R E 0x1000 LOAD 0x012000 0x00012000 0x00012000 0x003e80 0x003e80 R 0x1000 LOAD 0x016690 0x00017690 0x00017690 0x000d70 0x000d70 RW 0x1000 LOAD 0x00 0x0001a000 0x0001a000 0x00 0x0ca048 RW 0x1000 DYNAMIC0x016b80 0x00017b80 0x00017b80 0x0001f0 0x0001f0 RW 0x8 NOTE 0x000370 0x0370 0x0370 0x20 0x20 R 0x8 NOTE 0x000390 0x0390 0x0390 0x44 0x44 R 0x4 GNU_PROPERTY 0x000370 0x0370 0x0370 0x20 0x20 R 0x8 GNU_EH_FRAME 0x01433c 0x0001433c 0x0001433c 0x000404 0x000404 R 0x4 GNU_STACK 0x00 0x 0x 0x00 0x00 RW 0x10 GNU_RELRO 0x016690 0x00017690 0x00017690 0x000970 0x000970 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 03 .init .plt .plt.got .plt.sec .text .fini 04 .rodata .eh_frame_hdr .eh_frame 05 .init_array .fini_array .data.rel.ro .dynamic .got .data 06 .bss 07 .dynamic 08 .note.gnu.property 09 .note.gnu.build-id .note.ABI-tag 10 .note.gnu.property 11 .eh_frame_hdr 12 13 .init_array .fini_array .data.rel.ro .dynamic .got root@ee-motd-verify:~# stat -c %s /usr/bin/gzip 97496 Note that the last PT_LOAD segment is set to 0. ** Tags removed: verification-needed verification-needed-eoan ** Tags added: verification-done verification-done-eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Committed Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -ba
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Description changed: + IMPORTANT: Binutils was accidentally built in -proposed instead of in a + PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- + service/+archive/ubuntu/3876 for the -security pocket. + [Impact] - * Running gzip on WSL1 results in the following error: -$ gzip --bash: /bin/gzip: cannot execute binary file: Exec format error - * The error occurs frequently in package updates and makes gzip inoperable on WSL1 - * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. + * Running gzip on WSL1 results in the following error: + $ gzip + -bash: /bin/gzip: cannot execute binary file: Exec format error + * The error occurs frequently in package updates and makes gzip inoperable on WSL1 + * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] - * Check the gzip binary for wrong offset: - $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' + * Check the gzip binary for wrong offset: + $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] - * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. - * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. + * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. + * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: IMPORTANT: Binutil
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
So the binutils upload will need to be re-built against security and pushed to the -security pocket additionally to the -updates pocket, otherwise all the future potential gzip security updates would revert this fix here. Balint is preparing the rebuild, but I think ubuntu- security should be notified. In the meantime, I have released gzip as is as it does not have any runtime dependency on the new binutils. It did not age fully but I am conditionally accepting it earlier. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: IMPORTANT: Binutils was accidentally built in -proposed instead of in a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/3876 for the -security pocket. [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
This bug was fixed in the package gzip - 1.10-0ubuntu3.1 --- gzip (1.10-0ubuntu3.1) eoan; urgency=high * Rebuild with binutils 2.33-2ubuntu1.1 (LP: #1843479) - Build-depend on binutils (>= 2.33-2ubuntu1.1) -- Balint Reczey Fri, 13 Dec 2019 16:41:46 +0100 ** Changed in: gzip (Ubuntu Eoan) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: IMPORTANT: Binutils was accidentally built in -proposed instead of in a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/3876 for the -security pocket. [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
(actually, I don't think security needs to be notified, so scratch that) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: IMPORTANT: Binutils was accidentally built in -proposed instead of in a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/3876 for the -security pocket. [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Description changed: IMPORTANT: Binutils was accidentally built in -proposed instead of in a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- - service/+archive/ubuntu/3876 for the -security pocket. + service/+archive/ubuntu/3877 for the -security pocket. [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: IMPORTANT: Binutils was accidentally built in -proposed instead of in a PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/3877 for the -security pocket. [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isol
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Hello Hayden, or anyone else affected, Accepted binutils into eoan-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/binutils/2.33-2ubuntu1.2 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-eoan to verification-done-eoan. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-eoan. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Tags removed: verification-done verification-done-eoan ** Tags added: verification-needed verification-needed-eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Other Info] * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci- train-ppa-service/+archive/ubuntu/3878 for the -security pocket as 2.33-2ubuntu1.2. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip:
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Verified binutils 2.33-2ubuntu1.2 by rebuilding gzip in the Bileto PPA with new binutils and checking the rebuilt gzip binary: root@ee-dwz:~# wget https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb --2019-12-20 17:50:02-- https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3878/+build/18334107/+files/gzip_1.10-0ubuntu3.1_amd64.deb Resolving launchpad.net (launchpad.net)... 91.189.89.222, 91.189.89.223, 2001:67c:1560:8003::8003, ... Connecting to launchpad.net (launchpad.net)|91.189.89.222|:443... connected. HTTP request sent, awaiting response... 303 See Other Location: https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb [following] --2019-12-20 17:50:03-- https://launchpadlibrarian.net/456546671/gzip_1.10-0ubuntu3.1_amd64.deb Resolving launchpadlibrarian.net (launchpadlibrarian.net)... 91.189.89.228, 91.189.89.229, 2001:67c:1560:8003::8007, ... Connecting to launchpadlibrarian.net (launchpadlibrarian.net)|91.189.89.228|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 95292 (93K) [application/x-debian-package] Saving to: ‘gzip_1.10-0ubuntu3.1_amd64.deb’ gzip_1.10-0ubuntu3.1_amd64.deb 100%[=>] 93.06K --.-KB/sin 0.1s 2019-12-20 17:50:03 (715 KB/s) - ‘gzip_1.10-0ubuntu3.1_amd64.deb’ saved [95292/95292] root@ee-dwz:~# apt install ./gzip_1.10-0ubuntu3.1_amd64.deb Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'gzip' instead of './gzip_1.10-0ubuntu3.1_amd64.deb' gzip is already the newest version (1.10-0ubuntu3.1). The following package was automatically installed and is no longer required: libdumbnet1 Use 'apt autoremove' to remove it. 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded. root@ee-dwz:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' root@ee-dwz:~# echo $? 0 root@ee-dwz:~# FILE=/usr/bin/gzip; readelf -W --program-headers $FILE Elf file type is DYN (Shared object file) Entry point 0x4190 There are 14 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x40 0x0040 0x0040 0x000310 0x000310 R 0x8 INTERP 0x000350 0x0350 0x0350 0x1c 0x1c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x00 0x 0x 0x0027a0 0x0027a0 R 0x1000 LOAD 0x003000 0x3000 0x3000 0x00ea05 0x00ea05 R E 0x1000 LOAD 0x012000 0x00012000 0x00012000 0x003e80 0x003e80 R 0x1000 LOAD 0x016690 0x00017690 0x00017690 0x000d70 0x000d70 RW 0x1000 LOAD 0x00 0x0001a000 0x0001a000 0x00 0x0ca048 RW 0x1000 DYNAMIC0x016b80 0x00017b80 0x00017b80 0x0001f0 0x0001f0 RW 0x8 NOTE 0x000370 0x0370 0x0370 0x20 0x20 R 0x8 NOTE 0x000390 0x0390 0x0390 0x44 0x44 R 0x4 GNU_PROPERTY 0x000370 0x0370 0x0370 0x20 0x20 R 0x8 GNU_EH_FRAME 0x01433c 0x0001433c 0x0001433c 0x000404 0x000404 R 0x4 GNU_STACK 0x00 0x 0x 0x00 0x00 RW 0x10 GNU_RELRO 0x016690 0x00017690 0x00017690 0x000970 0x000970 R 0x1 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.gnu.property .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt 03 .init .plt .plt.got .plt.sec .text .fini 04 .rodata .eh_frame_hdr .eh_frame 05 .init_array .fini_array .data.rel.ro .dynamic .got .data 06 .bss 07 .dynamic 08 .note.gnu.property 09 .note.gnu.build-id .note.ABI-tag 10 .note.gnu.property 11 .eh_frame_hdr 12 13 .init_array .fini_array .data.rel.ro .dynamic .got root@ee-dwz:~# ** Description changed: - IMPORTANT: Binutils was accidentally built in -proposed instead of in a - PPA. I'm rebuilding it in https://launchpad.net/~ci-train-ppa- - service/+archive/ubuntu/3877 for the -security pocket. - [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of fi
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Changed in: binutils (Ubuntu) Importance: Undecided => Medium ** Changed in: binutils (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: gzip (Ubuntu Eoan) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Committed Status in gzip source package in Eoan: Fix Released Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Other Info] * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci- train-ppa-service/+archive/ubuntu/3878 for the -security pocket as 2.33-2ubuntu1.2. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
This bug was fixed in the package binutils - 2.33-2ubuntu1.2 --- binutils (2.33-2ubuntu1.2) eoan; urgency=medium * Rebuild for the -security pocket binutils (2.33-2ubuntu1.1) eoan; urgency=medium * Cherry-pick from binutils master branch: PR25237, set no file contents PT_LOAD p_offset to first page (LP: #1843479) -- Balint Reczey Thu, 19 Dec 2019 12:46:41 +0100 ** Changed in: binutils (Ubuntu Eoan) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Confirmed Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Released Status in gzip source package in Eoan: Fix Released Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Other Info] * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci- train-ppa-service/+archive/ubuntu/3878 for the -security pocket as 2.33-2ubuntu1.2. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Changed in: binutils Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in binutils: Fix Released Status in binutils package in Ubuntu: Fix Released Status in gzip package in Ubuntu: Fix Released Status in binutils source package in Eoan: Fix Released Status in gzip source package in Eoan: Fix Released Bug description: [Impact] * Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error * The error occurs frequently in package updates and makes gzip inoperable on WSL1 * The problem is caused by PT_LOAD offset pointing past the end of file and the fix is fixing strip to not generate such ELF files and recompiling gzip with the fixed strip. [Test Case] * Check the gzip binary for wrong offset: $ FILE=/usr/bin/gzip; readelf -W --program-headers $FILE | awk -v size=$(stat -c %s $FILE) '/^ LOAD/ {if (strtonum($2) > size) {print "wrong offset ("$2" ("strtonum($2)") points past EOF:" size; exit 1;}}' [ Regression Potential ] * The binutils fix could cause binutils to generate invalid ELF files. The fix is very small and isolated and has been tested and accepted by upstream, which makes such problems unlikely. * Bugs in the toolchain in general can make the rebuilt gzip show new errors, but this generally applies to many SRUs and security updates. The testing period in proposed should mitigate this risk. [Other Info] * Binutils 2.33.1-6ubuntu1.1 was accidentally built in -proposed instead of in a PPA. I've rebuilt it in https://launchpad.net/~ci- train-ppa-service/+archive/ubuntu/3878 for the -security pocket as 2.33-2ubuntu1.2. [Originial Bug Text] Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Tags added: wsl -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: gzip (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
** Changed in: gzip (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
I tried comparing the binaries with diffoscope, and one difference which jumped out at me is the .plt.sec section which is present in the Eoan binary. This presumably comes from CET (gcc -fcf-protection). There are other differences, less significant IMO; .plt.sec is a likely candidate for something WSL1 might not support. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
>From the WSL issues page: > Now, thing is, all of the new binaries (f.e. /bin/ls) have that .plt.sec section also, and they work just fine. Also compiling a hello.c with -fcf-protection works. Because of course it does. The only other new section in there (Disco gzip has 27 sections, Eoan has 29) is .note.gnu.property. No joy after stripping that either. Meh. It's not .note.ABI-tag; I stripped that as a WAG right after this issue was posted. Which is all a long description of things that don't work. Next thing to try would be to grab the apt-source, try to build a broken binary, and then try to guess what makes gzip so special (contrast say /bin/ls). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
This was determined to be a bug in the WSL1 ELF loader and fix is inbound from the WSL side. https://github.com/microsoft/WSL/issues/4461#issuecomment-536023805 Please close on Ubuntu. ** Bug watch added: github.com/microsoft/WSL/issues #4461 https://github.com/microsoft/WSL/issues/4461 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Confirmed Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843479] Re: gzip in Ubuntu Eoan results in Exec format error on WSL1
Thanks Hayden, closing ** Changed in: gzip (Ubuntu) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1843479 Title: gzip in Ubuntu Eoan results in Exec format error on WSL1 Status in gzip package in Ubuntu: Invalid Bug description: Summary: Running gzip on WSL1 results in the following error: $ gzip -bash: /bin/gzip: cannot execute binary file: Exec format error What I expect to happen: gzip executes correctly on WSL1. What happens instead: gzip fails with an Exec format error. Notes: I suspect a change in how gzip is being built for Eoan is causing issues with ELF parsing on the WSL1 translation layer. For example: On Disco with gzip 1.9-3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=efa859c26eaf8e035efe9a139361e2a60cd17b3e, stripped On Eoan with gzip 1.10-0ubuntu3: $ file /bin/gzip /bin/gzip: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bc0f5994544c2a469d04c914bf4bf44b4ded6040, for GNU/Linux 3.2.0, stripped Eoan ships with gzip 1.10, while Disco ships with gzip 1.9, but I do not believe this is an issue in 1.10 because this error does not occur when building gzip from GNU project source on Ubuntu Eoan. Justifications: WSL1 will need to be patched in future Windows builds for this change in ELF. However that patch will likely not be backported to older builds of Windows, including Windows Enterprise/Server 2019. To ensure Eoan can run on current and older builds of Windows Ubuntu should consider looking at how it's building gzip and see if it can be made to 'play nice' until WSL1 can be updated. This was originally reported here: https://github.com/microsoft/WSL/issues/4461 Details: Description:Ubuntu Eoan Ermine (development branch) Release:19.10 gzip: Installed: 1.10-0ubuntu3 Candidate: 1.10-0ubuntu3 Version table: *** 1.10-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1843479/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp