Summary: An amd64 and an armv6 installation running HEAD have been updated from r343663 to r346961; now, the armv6 installation cannot be executed any more using qemu-arm-static. This used to work before.

Scenario:
- VirtualBox client running head (13.0-CURRENT FreeBSD 13.0-CURRENT #0 r346961M amd64)
  (host running 12.0-RELEASE-p3 amd64)
- (everything below refers to what is happening in the client which, apart from being a VM, works like a normal host)
- Upgraded from r343663 to r346961 using make buildworld/buildkernel, make installkernel/installworld, mergemaster
- Rebuilt all ports, amongst them qemu-user-static
- In a separate subtree (/d/rpi-b) there exists a complete FreeBSD armv6 installation for a RPI-B target (this can be used for netbooting a physical Raspberry Pi B+, but that is of no concern here)
- Upgraded this RPI-B installation just like the native amd64 install from r343663 to r346961 using make buildworld/buildkernel, make installkernel/installworld, mergemaster using the appropriate cross-compilation flags
- /usr/local/etc/rc.d/qemu_user_static is enabled, resulting in the correct binmiscctl
- /usr/local/bin/qemu-arm-static has been copied to /d/rpi-b/usr/local/bin/qemu-arm-static
- Trying to execute
  chroot /d/rpi-b /bin/zsh -l

Result:
- The chroot returns with exit status 127 and no further output
- HOWEVER, a very few times the zsh executed, but then any further commands executed inside it immediately returned with exit status 127 and no further output

Expected result:
- The chroot starts the armv6 zsh binary and it is possible to continue in the chrooted environment
- Note that this worked in r343663 (i.e., before upgrading the systems and recompiling all ports)

Scenario (continued):
- The armv6 ports are not yet recompiled (including zsh)
- Therefore instead try to execute
  chroot /d/rpi-b /bin/sh

Result (continued):
- Same as above, the chroot returns immediately with exit status 127 and no further output

Notes:
- kern.elf{32,64}.aslr.enable are 0

-- Martin