Updated Short Answer:

This should be fixed (see the Launchpad report below) in the latest Jammy updates.

sudo apt update && sudo apt upgrade -y

... and try again.

If not, please let me know (and more importantly, the Ubuntu team via a Launchpad report), but here's the old workaround ...

Old Short answer:

printf '#!/bin/sh

exec /lib64/ld-linux-x86-64.so.2 /usr/bin/gzip "$@"' | sudo tee /usr/local/bin/gzip

sudo chmod +x /usr/local/bin/gzip

Explanation:

This is currently a known issue with WSL1 and Ubuntu 22.04 (Jammy), as well as some other recent distributions:

• Launchpad report


• WSL GitHub report

This renders Jammy fairly unusable under WSL1 since so many packages (including apt) utilize gzip.

Note (for others who search for this using different terms) that the error message when creating a tar is slightly different:

/bin/sh: 1: gzip: Exec format error

A similar (but not the same) occurred with gzip in Ubuntu Eoan a few years back. Reference:

• Launchpad report


• WSL GitHub report

It's not clear to me from reading the comments on any of these issues whether the problem resides in WSL1 or in the toolchain used to create the gzip binary. In the Eoan case, the issue was ultimately "resolved" in binutils, but it's not clear to me if that was just a workaround for what was really a WSL1 issue at the core.

In any case, there are three possible solutions:

• If you can, run Jammy under WSL2. The Linux kernel in WSL2 handles the changes to gzip without issue. It's just a problem in the WSL1 ELF loader.

  
  



• Use the workaround above to replace gzip with a version earlier on the path that calls the "real" (but broken) version through /lib64/ld-linux-x86-64.so.2.

  
  



• From a comment in the WSL GitHub issue, it's possible to patch the gzip binary to resolve the issue. I'm not a personal fan of this approach, but if you would like to try it:

  
  

echo -en 'x10' | sudo dd of=/usr/bin/gzip count=1 bs=1 conv=notrunc seek=$((0x189))

Since something in the toolchain is likely the culprit, this issue also seems to be showing up in:

• Other distributions (reportedly Arch and almost certainly others)


• Other binaries (reportedly Node.js)

There is reportedly a patch for the Node issue as well in that GitHub thread.

Patching distribution binaries, however, is not without risk. Hopefully someone will either identify the toolchain issue that is causing this or the WSL team will change the ELF loader code to compensate.