1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, so I have this problem where when I try to run a Debian sid armhf system using Qemu usermode arm, it's throwing errors about unsupported syscalls 370 and 355. The user provided the log output showing that during boot with systemd-nspawn, there are these syscall issues. They mentioned that this happens when using the latest git as of today.
First, I need to classify this bug report into either 'user-mode' or 'system-mode'. System-mode reports usually involve higher privileges, peripherals, devices, and operating systems. User-mode is more about applications running on top of an OS without needing kernel-level access.
Looking at the error messages: "Unsupported syscall: 370" and "Unsupported syscall: 355". I know that syscalls are system calls made by userland programs to the kernel. If Qemu is running in usermode, it's supposed to emulate the ARM environment but still uses the host's kernel for syscalls.
Wait, no, actually, when using Qemu in usermode (like qemu-user), it translates machine code from one architecture to another but relies on the host's syscall implementation. So if the guest program tries to make a syscall that the host doesn't support, Qemu can't translate it and throws an error.
In this case, systemd is trying to use syscalls 370 and 355 which aren't supported by the host's kernel as seen by Qemu. This suggests that these are syscalls specific to certain architectures or newer versions of Linux that the host doesn't handle when emulating armhf.
Since the error occurs during the execution of systemd, which is a system service manager running in the guest environment, it's more about how the guest OS interacts with the host through Qemu. Systemd is trying to perform operations (like creating directories or managing time zones) that require syscalls not supported in the usermode emulation.
This seems related to the way Qemu handles system calls when translating from armhf to the host architecture, which might be x86_64 here. The missing syscalls prevent systemd from initializing properly, leading to a freeze.
Therefore, since it's about the interaction between the guest OS and the host through Qemu's usermode emulation, involving system-level services like systemd and their dependencies on specific syscalls, this falls under 'user-mode' because it's about how applications (like systemd) running in the emulated environment interact with the host via syscalls.
</think>
user
|