1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
<think>
Okay, I'm trying to figure out what's causing the issue when using QEMU-i386 in user mode on my ARM-based Pogo Plug. So, let me go through each step and see where things might be going wrong.
First, I installed Arch Linux in a VirtualBox VM and created a chroot environment for it using mkarchroot. Then, I transferred this chroot to the Pogo Plug into the /i386 directory. That part seems okay because I can access the chroot.
Next, I compiled QEMU-i386 statically with some specific configuration options. The make command went through without errors, so the binary should be fine. I placed it in /i386/usr/bin/, which makes sense because that's where userland binaries go.
I also compiled a Linux kernel version 2.6.38 with binfmt_misc enabled. After installing it, the output from uname -a shows that the kernel is running correctly on the ARM system. So, the kernel part seems to be set up properly.
In /etc/rc.local, I added commands to load binfmt_misc and register the QEMU-i386 interpreter. The modprobe for binfmt_misc should load the module, and mounting it makes sure it's available. Then, the echo command registers the binary format so that when an x86 executable is run, the kernel knows to use QEMU-i386 as an interpreter.
I copied ld-linux.so.3 from /lib/ to /i386/lib/. Wait a minute, in Arch Linux, ld-linux.so.3 might be a symlink pointing to a newer version like ld-2.13.so. So I made sure to copy the actual file that the symlink points to into the chroot's lib directory. That should allow the dynamic linker to work inside the chroot.
When I try to run chroot into /i386 and then attempt to use pacman, I get "bash: fork: Invalid argument". Forking is a system call used by processes to create child processes, so this error suggests that the fork syscall is failing. This could be due to several reasons, like insufficient memory or issues with process management.
Additionally, when running the test from qemu-linux-user-test-0.3, I get an assertion failure in the dynamic linker. The error message mentions a problem in dl-version.c at line 210, which seems to involve checking map versions. This might indicate that the dynamic linker isn't properly handling something related to shared libraries or their versions.
Putting this together, it looks like there's a problem with how processes are being managed when running x86 binaries under QEMU in user mode on my ARM system. The fork error suggests an issue at the syscall level, which could be part of the runtime environment setup within QEMU. Maybe the way binfmt_misc is set up or how QEMU-i386 interacts with the kernel isn't quite right.
Another angle to consider is whether all necessary libraries are correctly placed in the chroot and accessible by QEMU. Missing dependencies or incorrect library versions could cause issues during process creation, leading to fork failures. Also, ensuring that the QEMU binary itself has the correct permissions and can access all required resources inside the chroot is important.
I might need to check if there's enough memory on the system when running these processes. The Pogo Plug has limited resources, so maybe it's struggling with the overhead of running a chroot environment and QEMU simultaneously. If that's the case, optimizing resource usage or increasing available memory (if possible) could help.
Looking at the error messages again, both the fork failure and the dynamic linker issue point towards runtime problems. The fork error is a system call that isn't being handled correctly, while the linker issue suggests something went wrong during process initialization within QEMU's environment. It might be a combination of these factors causing the overall problem.
I should also consider whether there are known issues with running user-mode QEMU on certain kernel versions or architectures. Maybe the specific version I'm using (2.6.38) has some bugs that affect how binfmt_misc works with QEMU-i386. Checking if newer kernels have fixes for similar issues might be worth exploring.
In summary, the main issue appears to be a runtime error when trying to fork processes within the chroot environment set up using QEMU-i386. This could stem from incorrect setup of binfmt_misc, insufficient system resources, or compatibility problems between the kernel and QEMU in this specific configuration.
</think>
The problem is classified under the category of `runtime`.
|