Am 03.01.23 um 12:34 schrieb Michael Tokarev:
Control: severity -1 minor
03.01.2023 11:31, pe...@flying-snail.de wrote:
Package: qemu-user-static
Version: 1:7.2+dfsg-1+b1
Severity: normal
Dear Maintainer,
after installing qemu-user-static on an aarch64 machine (itself a UTM
virtual machine in
Apple M1), a working qemu-arm-static is installed. I.e.: Explicit calls
qemu-arm-static some-armhf-executable
are working fine.
However, qemu-arm is missing from /proc/sys/fs/binfmt_misc/ and the
pattern
configuration files for arm are lacking in the package.
In result, it is not possible to run scripts in armhf chroot
environments, as required
in the tutorial
https://www.debian.org/releases/bullseye/armhf/apds03.de.html
This is the same issue as installing binfmt-amd64 on a i386 system (so
that pure
32bit x86 can run amd64 binaries) and a bunch of other similar
situations.
There's a bugreport about this, #1016810, marked as "wontfix" for now.
This is because we really need to check the current system
capabilities at runtime
when booting or when installing the binfmts, - it is not just about
dropping stuff
to /usr/lib/binfmt.d/ and be don with it. We should determine if the
current system
already can run these binaries natively, and only install binfmt
support if it is
not.
Maybe we can ship some test binaries for that and run these to
determine if we
should install binfmt or not. But this becomes quite a bit.. too much.
I think I can install _all_ qemu-supported binfmts into
/usr/lib/binfmt.d/ , disable
some in /etc/binfmt.d/ (the one which I currently omit), and let the
user to configure
this stuff locally.
/mjt
Sorry if I'm misinformed, but I believe it is not the exact same
situation as with x86.
From what I've read, support for arm32 is optional for arm64 CPU, moreover
virtualization of arm32 is not possible at least on an Apple host.
So yes, the option to configure arm32 support at binfmt installation
would appear
very useful indeed.
Andreas.
