|arch-test(1)||General Commands Manual||arch-test(1)|
NAME¶arch-test - detect architectures your kernel can run binaries of
- arch-test [-n]
- enumerates the architectures
- arch-test [-n] [-c <chroot>] <arch>
- tests a single arch
DESCRIPTION¶When called without an argument, arch-test outputs the list of architectures executable by your running kernel, one per line, using Debian arch names. Libc or other libraries are neither needed nor checked — an arch is listed if its machine code can be executed and the appropriate syscall ABI is supported by the kernel. This means, you can run these architectures in a chroot or a container, execute them using multiarch, run static binaries, etc. The ability to run additional architectures can be gained via binfmts on Linux, Linux emulation on BSD, etc.
An architecture is considered runnable only if your kernel can run unmodified binaries, without extra steps such as recompiling (Raspbian armhf) or using brandelf on binaries you'd want to run (FreeBSD emulation of Linux). Also, as Debian requires 686 on i386 as of the stretch release, 686 support is checked for.
If -n is specified, arch-test will try to disable known emulators (currently qemu and wine). Note that a whole-machine emulator appears to be native as far as the kernel is concerned.
With -c <chroot>, the test is done inside a given chroot (note that binfmt requires an interpreter to live inside the chroot); this is not needed with -n. Root privileges are required here.
When called with an arch name as an argument, arch-test tests the specified architecture. A human-friendly message will be printed, and the exit code can be:
- congratulations, the arch can be run on your kernel
- cannot check — arch-test lacks a helper for this arch
- (Shell hint: with set -e you write: ret=0; arch-test $ARCH || ret=$?)
Helper programs¶The detection is done by small programs located in /usr/lib/arch-test/. These programs check whether the running kernel can execute binaries of a given architecture. When run, if successful, each such program prints "ok" on stdout and returns exit code 0.
When the check fails, these helper programs may die horribly — always with a non-zero exit code. Usually the kernel will notice the incompatibility and nicely abort the attempt, but in some near-miss cases the failure is more messy, such as SIGILL or SIGSEGV. If you want to run the helpers directly, you'd want to redirect stderr to /dev/null and to disable core dumps (ulimit -c 0).