1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I'm looking at this problem where someone is trying to set up QEMU in user mode on their ARM-based system (like a Pogo Plug) using Arch Linux. They've installed an i386 chroot environment and compiled QEMU-i386 statically. The goal seems to be running x86 binaries on their ARM device through QEMU.
First, they set up the chroot with mkarchroot and transferred it over. Then, they compiled QEMU with specific configure options: --static, --disable-blobs, --disable-system, and targeting i386-linux-user. They also built a Linux kernel with binfmt_misc support enabled.
Next, they added some lines to rc.local to load the binfmt_misc module and register the QEMU interpreter for x86 binaries. They copied ld-2.13.so (which is linked as ld-linux.so.3) into the chroot's lib directory.
When they try to chroot into /i386, running commands like pacman results in "bash: fork: Invalid argument". That error usually means that the kernel doesn't have enough resources or permissions to create a new process via fork(). But since this is within a chroot, maybe it's related to the environment setup.
They also ran a test from the QEMU user-mode tests, which failed with an assertion error in the dynamic linker. The test runs 'ls -l dummyfile' and fails because of a problem in dl.so. This suggests that the dynamic linker isn't working correctly within the chroot.
Now, the question is whether this bug report falls under 'user-mode' or 'system-mode'. User-mode issues typically involve running applications without full system emulation, relying on the host's kernel. System-mode would involve emulating a whole OS with hardware peripherals, etc.
Looking at their setup: they're using QEMU-i386 in user mode (since --disable-system was used), which means it should be executing x86 binaries directly under the host kernel. The error occurs when trying to run commands inside the chroot, suggesting that the environment isn't set up correctly for user-mode emulation.
The 'fork: Invalid argument' might be due to missing support in the host kernel or incorrect binfmt_misc setup. Alternatively, perhaps the QEMU binary is not properly registered, causing issues with process creation.
Since they're trying to run applications within a chroot using QEMU-i386 as an interpreter, this falls under user-mode because it's about executing binaries without full system emulation. The problem seems related to how the userland environment (chroot) interacts with QEMU and the host kernel, not about emulating hardware or a full OS.
</think>
user
|