blob: ec814ab9626f7e6348ce6d581c5d747fc85c0d9b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I need to figure out whether this QEMU issue is a user-mode or system-mode bug. Let me start by understanding the problem.
The user is trying to run Raspbian inside QEMU and encountered an error where qemu-arm dies because of libarmmem being loaded via ld.so.preload. They had to comment out the line in /etc/ld.so.conf that points to /usr/lib/arm-linux-gnueabihf/libarmmem.so.
Hmm, I know that ld.so.preload is used to load specific libraries before others when a program starts. In this case, it's trying to load libarmmem.so, which might be causing issues with QEMU's execution.
QEMU can run in two main modes: user-mode and system-mode. User-mode emulation runs individual applications without the full OS, while system-mode emulates the entire hardware, including the kernel and devices.
So, if this issue is happening when running Raspbian (which includes the OS), it's likely using QEMU in system-mode because it's emulating the whole system. The fact that they had to modify /etc/ld.so.conf suggests that it's affecting how libraries are loaded for the entire environment, which makes sense in a full OS context.
If it were user-mode, maybe the problem would be isolated to specific applications rather than requiring changes at the OS level like modifying ld.so.conf. Also, system-mode often deals with lower-level issues involving the kernel and device emulation, which could interact differently with libraries loaded by the dynamic linker.
Therefore, this bug seems related to system-mode because it's about running a full OS within QEMU and involves changes to system-wide library configurations.
</think>
system
|