Upgrade to QEMU 6 breaks executing the dynamic loader in Xenial and lower

[amyspark]

Hi,

I just ran into an issue when trying to pack some Appimages inside this image. linuxdeployqt uses ldd to inspect the ELFs and get the list of linked libraries, e.g.

ldd /bin/bash

This should return:

❯ docker run --rm -ti multiarch/ubuntu-core:arm64-bionic ldd /bin/bash
Unable to find image 'multiarch/ubuntu-core:arm64-bionic' locally
arm64-bionic: Pulling from multiarch/ubuntu-core
bf3d6f8337bd: Pull complete 
2bedc0667d94: Pull complete 
81ad7ed65334: Pull complete 
f7b361ed3c70: Pull complete 
Digest: sha256:6c7a892f35db6feaea3ac3928d3b7a511b16dc298fc5e7ea49462c3d873b5f01
Status: Downloaded newer image for multiarch/ubuntu-core:arm64-bionic
	libtinfo.so.5 => /lib/aarch64-linux-gnu/libtinfo.so.5 (0x000000550194c000)
	libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000005501986000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x000000550199b000)
	/lib/ld-linux-aarch64.so.1 (0x0000005500000000)

but instead, in Trusty and Xenial images updated in the past fortnight I get:

~ 
❯ docker run --rm -ti multiarch/ubuntu-core:arm64-xenial ldd /bin/bash
ldd: exited with unknown exit code (139)

~ 
❯ docker run --rm -ti multiarch/ubuntu-core:arm64-trusty ldd /bin/bash
ldd: exited with unknown exit code (139)

I boiled it down to the line in ldd which attempts to verify the type of object it's dealing with:

❯ docker run --rm -ti multiarch/ubuntu-core:arm64-xenial
root@3512d4b5088a:/# /lib/ld-linux-aarch64.so.1 --verify /bin/bash
Segmentation fault (core dumped)

❯ docker run --rm -ti multiarch/ubuntu-core:arm64-bionic
root@c30dc78d252f:/# /lib/ld-linux-aarch64.so.1 --verify /bin/bash
root@c30dc78d252f:/# echo $?
0

The only workaround I've found is to copy ldd and an old copy of v5 qemu-aarch64-static to a folder I control, and make the former explicitly execute the copied qemu-aarch64-static when calling the dynamic loader.

As this bug renders a critical glibc tool inoperative in CI, reverting the upgrade would be the best alternative.

Please note that this bug only affects aarch64-- the same workflow works correctly from armhf.