Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1027781: qemu-user-static on arm64 host lacks registering arm (hf) support with binfmt_misc
705 views
Skip to first unread message
pe...@flying-snail.de
Jan 3, 2023, 3:40:04 AM1/3/23
to
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
I would expect that the provided qemu-arm is registered in the same way
as any other supported processor type in the package.
-- System Information:
Debian Release: 11.6
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 5.10.0-20-arm64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.2.1-1+deb11u1
ii systemd 247.3-7+deb11u1
qemu-user-static suggests no packages.
-- no debconf information
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
I would expect that the provided qemu-arm is registered in the same way
as any other supported processor type in the package.
-- System Information:
Debian Release: 11.6
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'testing')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf
Kernel: Linux 5.10.0-20-arm64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
qemu-user-static depends on no packages.
Versions of packages qemu-user-static recommends:
ii binfmt-support 2.2.1-1+deb11u1
ii systemd 247.3-7+deb11u1
qemu-user-static suggests no packages.
-- no debconf information
Christian Ehrhardt
Jan 3, 2023, 4:00:04 AM1/3/23
to
Hi,
I just wanted to mention that arm32 support is possible, but optional in arm64.
So far only a few chips had neglected arm32. So on most aarch64
systems you can "just run" armhf code and it would work.
Now the M1 chip AFAIK has no arm32 and that causes the issue you face,
but at the same time explains to some extent why it wasn't much of a
problem before.
I thought I should mention that as it will affect the solution (do
only some arm64 platforms want that, would others regress potentially
going from HW to TCG emulation) and testing (as it will behave
differently based on which HW you use for aarch64).
And while the code to change to do what you ask for in
debian/binfmt-install is simple.
Past issues like [1] have hit just such issues as I'm afraid we might
re-face here.
Maybe this needs to become more advanced than just checking
$DEB_HOST_ARCH, but that is up for discussion.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604712
I just wanted to mention that arm32 support is possible, but optional in arm64.
So far only a few chips had neglected arm32. So on most aarch64
systems you can "just run" armhf code and it would work.
Now the M1 chip AFAIK has no arm32 and that causes the issue you face,
but at the same time explains to some extent why it wasn't much of a
problem before.
I thought I should mention that as it will affect the solution (do
only some arm64 platforms want that, would others regress potentially
going from HW to TCG emulation) and testing (as it will behave
differently based on which HW you use for aarch64).
And while the code to change to do what you ask for in
debian/binfmt-install is simple.
Past issues like [1] have hit just such issues as I'm afraid we might
re-face here.
Maybe this needs to become more advanced than just checking
$DEB_HOST_ARCH, but that is up for discussion.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604712
Michael Tokarev
Jan 3, 2023, 6:40:03 AM1/3/23
to
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
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
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
Michael Tokarev
Jan 3, 2023, 6:40:03 AM1/3/23
to
03.01.2023 14:34, Michael Tokarev wrote:
..
turned off in the current kernel and needs just an extra boot arg to work?
/mjt
..
> 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.
Another example: should we enable x32 support (if we had one) if it is just
> should install binfmt or not. But this becomes quite a bit.. too much.
turned off in the current kernel and needs just an extra boot arg to work?
/mjt
pe...@flying-snail.de
Jan 6, 2023, 7:00:04 AM1/6/23
to
Am 03.01.23 um 12:34 schrieb Michael Tokarev:
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.
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.
Emanuele Rocca
Mar 2, 2023, 4:40:04 PM3/2/23
to
On Fri, Jan 06, 2023 at 12:07:26PM +0100, pe...@flying-snail.de wrote:
> 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.
Agreed. It's also pretty easy to find out whether a given arm64 CPU can run
> 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.
arm32 code natively or not. On arm64 machines capable of both modes, lscpu
shows the following:
$ lscpu | grep op-mode
CPU op-mode(s): 32-bit, 64-bit
On processors that cannot run 32 bit code, such as the Apple M1, the output is
simply:
$ lscpu | grep op-mode
CPU op-mode(s): 64-bit
0 new messages