| 2019-09-10 18:45:00 |
Hayden Barnes |
bug |
|
|
added bug |
| 2019-09-10 18:45:11 |
Hayden Barnes |
summary |
gzip in Ubuntu Eoan results in Exec format error |
gzip in Ubuntu Eoan results in Exec format error on WSL1 |
|
| 2019-09-11 07:30:56 |
Sebastien Bacher |
tags |
|
wsl |
|
| 2019-09-11 07:33:16 |
Eliah Kagan |
bug |
|
|
added subscriber Eliah Kagan |
| 2019-09-11 07:33:24 |
Launchpad Janitor |
gzip (Ubuntu): status |
New |
Confirmed |
|
| 2019-09-11 07:42:58 |
Sebastien Bacher |
gzip (Ubuntu): importance |
Undecided |
High |
|
| 2019-09-11 07:43:09 |
Sebastien Bacher |
bug |
|
|
added subscriber Sebastien Bacher |
| 2019-09-30 18:29:43 |
Hayden Barnes |
bug watch added |
|
https://github.com/microsoft/WSL/issues/4461 |
|
| 2019-10-01 08:26:32 |
Sebastien Bacher |
gzip (Ubuntu): status |
Confirmed |
Invalid |
|
| 2019-11-30 15:48:01 |
Balint Reczey |
bug task added |
|
binutils (Ubuntu) |
|
| 2019-11-30 15:48:12 |
Balint Reczey |
binutils (Ubuntu): status |
New |
In Progress |
|
| 2019-11-30 15:48:18 |
Balint Reczey |
binutils (Ubuntu): assignee |
|
Balint Reczey (rbalint) |
|
| 2019-11-30 15:51:26 |
Balint Reczey |
gzip (Ubuntu): status |
Invalid |
In Progress |
|
| 2019-11-30 23:39:00 |
Balint Reczey |
bug watch added |
|
https://sourceware.org/bugzilla/show_bug.cgi?id=25237 |
|
| 2019-11-30 23:39:00 |
Balint Reczey |
bug task added |
|
binutils |
|
| 2019-12-01 01:22:47 |
Bug Watch Updater |
binutils: status |
Unknown |
New |
|
| 2019-12-01 01:22:47 |
Bug Watch Updater |
binutils: importance |
Unknown |
Medium |
|
| 2019-12-01 21:59:55 |
Tom |
bug |
|
|
added subscriber Tom |
| 2019-12-02 01:49:00 |
Bug Watch Updater |
binutils: status |
New |
Won't Fix |
|
| 2019-12-03 02:03:53 |
Bug Watch Updater |
binutils: status |
Won't Fix |
Confirmed |
|
| 2019-12-13 21:07:51 |
Balint Reczey |
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 |
[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 |
|
| 2019-12-14 01:29:01 |
Steve Langasek |
binutils (Ubuntu Eoan): status |
New |
Fix Committed |
|
| 2019-12-14 01:29:02 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-12-14 01:29:04 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2019-12-14 01:29:10 |
Steve Langasek |
tags |
wsl |
verification-needed verification-needed-eoan wsl |
|
| 2019-12-14 07:21:55 |
Launchpad Janitor |
binutils (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-12-16 11:19:26 |
Łukasz Zemczak |
gzip (Ubuntu Eoan): status |
New |
Fix Committed |
|
| 2019-12-17 01:09:53 |
Launchpad Janitor |
gzip (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-12-17 12:25:23 |
Balint Reczey |
tags |
verification-needed verification-needed-eoan wsl |
verification-done verification-done-eoan wsl |
|
| 2019-12-19 11:58:06 |
Balint Reczey |
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 |
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 |
|
| 2019-12-19 12:01:52 |
Launchpad Janitor |
gzip (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2019-12-19 12:01:56 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-12-19 20:23:16 |
Balint Reczey |
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 |
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 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 |
|
| 2019-12-20 17:41:36 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-12-20 17:41:45 |
Steve Langasek |
tags |
verification-done verification-done-eoan wsl |
verification-needed verification-needed-eoan wsl |
|
| 2019-12-20 17:47:40 |
Balint Reczey |
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 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 |
[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 |
|
| 2019-12-20 17:51:45 |
Balint Reczey |
tags |
verification-needed verification-needed-eoan wsl |
verification-done verification-done-eoan wsl |
|
| 2019-12-21 07:32:27 |
Mathew Hodson |
binutils (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-12-21 07:32:29 |
Mathew Hodson |
binutils (Ubuntu Eoan): importance |
Undecided |
Medium |
|
| 2019-12-21 07:32:31 |
Mathew Hodson |
gzip (Ubuntu Eoan): importance |
Undecided |
High |
|
| 2019-12-21 09:31:17 |
Tom |
removed subscriber Tom |
|
|
|
| 2020-01-13 07:24:58 |
Launchpad Janitor |
binutils (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2020-02-24 05:26:26 |
Bug Watch Updater |
binutils: status |
Confirmed |
Fix Released |
|
