While using a chrooted crossbuilt Gentoo environment via QEMU I noticed the failure of all internal commands run inside a sh shell. What works however is when the commands are run with their full path: # busybox sh / # dmesg qemu: no user program specified / # grep qemu: no user program specified / # / # /bin/dmesg | /bin/grep SSE [ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' / # sed -e qemu: unknown option 'e' / # /bin/sed -e /bin/sed: option requires an argument -- 'e' BusyBox v1.33.0 (2021-04-11 12:57:27 EDT) multi-call binary. External sh commands however are run as expected: / # file /usr/bin/file /usr/bin/file: ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0, stripped This is unfortunate because all autotools configure scripts have the shebang #!/bin/sh thus I am unable to emerge stuff inside my chroot :( Steps to reproduce (Gentoo Linux on x86_64) : 1. Read the steps on https://wiki.gentoo.org/wiki/Cross_build_environment 2. Build the environment of your choice (in my case => crossdev s390x-ibm-linux-gnu giving a "busyboxed" environment in /usr/s390x-ibm-linux-gnu) 3. Add the QEMU user emulation into it as instructed by above link 4. Register the QEMU user emulator for the S390x binaries (echo ':s390x:M::\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x16:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-s390x:CF' > /proc/sys/fs/binfmt_misc/register) 5. Mount everything required (proc, sys, dev ...) prior chrooting 6. chroot /usr/s390x-ibm-linux-gnu /bin/bash 7. run /bin/sh and try some commands (grep, dmesg and so on), you will see what I put above.
Sounds like /proc/self/exe points to qemu (and not busybox). Maybe use /bin/busybox for your .config's BUSYBOX_EXEC_PATH if this really is the case.. If you enable FEATURE_PREFER_APPLETS then you should make sure that /proc/self/exe really is busybox. Not a busybox bug i'd say.