Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#75855 - [qemu-user-static] "chrooting" into arm container fails with bash not found error
Attached to Project:
Arch Linux
Opened by solsTiCe (zebul666) - Thursday, 08 September 2022, 23:27 GMT
Last edited by David Runge (dvzrv) - Saturday, 01 October 2022, 11:34 GMT
Opened by solsTiCe (zebul666) - Thursday, 08 September 2022, 23:27 GMT
Last edited by David Runge (dvzrv) - Saturday, 01 October 2022, 11:34 GMT
|
DetailsWhatever the method (arch-chroot, systemd-nspawn), trying to launch an arm container, ends up with an error about /bin/bash not found error:
# systemd-nspawn -M eupheme --bind-ro /etc/resolv.conf -D raspios-bullseye-armhf-lite-eupheme/ Spawning container eupheme on /var/lib/machines/raspios-bullseye-armhf-lite-eupheme. Press ^] three times within 1s to kill container. execv(/bin/bash, /bin/bash, /bin/sh) failed: No such file or directory Container eupheme failed with error code 1. It used to work fine before the new qemu-user-static package in [extra] Nothing as changed (that seems to me relevant) apart the binfmt-qemu-static package that I deleted and the new qemu-user-static |
This task depends upon
Closed by David Runge (dvzrv)
Saturday, 01 October 2022, 11:34 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with qemu 7.1.0-6 (only one provider of qemu-user-binfmt-provider may be installed at a time).
Saturday, 01 October 2022, 11:34 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed with qemu 7.1.0-6 (only one provider of qemu-user-binfmt-provider may be installed at a time).
Using the linux-zen kernel, if that matters
My archboot arm containers work fine with qemu-user-static.
Do you see any significant difference between your previous (AUR based) binfmt.d setup and the current one?
Maybe there is something we can improve?
So I looked at the difference, and the last flag field seems different (like C instead of CF). So I changed them and restarted systemd-bindfmt.service. But it changed nothing. May be, I need to reinstall the binfmt or reboot ?
But if it works for tpowa...
I don't have time to look more into that right now
Ah and for completeness my setup uses aarch64 static.
Using the C (credentials) flag looks rather dangerous tbh.
The /usr/lib/binfmt.d/qemu-*-static.conf files currently only use the F flag (fix binary).
@zebul666: Can you please try whether using FP as flags works for you (you will have to reboot after changing the file(s))?
[1] https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
Both qemu-user and qemu-user-static now provide binfmt configuration on their own.
While that's a good thing in itself, it doesn't make sense to have the config files in parallel as only one set can be picked up by the kernel.
The only way i could enforce using the qemu-user-static binaries via binfmt_misc was uninstalling qemu-user (and the qemu-emulator-full and qemu-full packages with it).
Would it make sense to have the packages being alternatives to each other?
If I forcefully remove qemu-user (with pacman -R -dd qemu-user), and only use qemu-user-static (from [extra]) and restart systemd-binfmt.service, this works!
I don't know why this used to work with the package from the AUR (qemu-user-static+binfmt-qemu-static) and qemu-user, while, now, you only can get it to work with only qemu-user-static (from [extra]) installed but not with qemu-user installed too.
Both will provide and conflict qemu-user-binfmt-provider, so that only one of them can be installed.