blob: 5a2244c9cd1bcb74314cbd977011a800a508e8c1 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<think>
Alright, I'm looking at this issue where someone is running an ARMv7 qemu chroot on their x86_64 desktop. They're getting a lot of "qemu: Unsupported syscall: 384" messages whenever they do any compiling inside the chroot. From what I gather, it's been about six months since they last used this environment, and there have been package updates since then.
The user mentioned that these messages aren't causing any problems—they’re just annoying. They had a chat with someone in IRC who explained that syscall 384 is getrandom (sys_getrandom). The person in IRC suggested that it's probably falling back to using /dev/urandom, so it might not be a big deal but should ideally be fixed by implementing the sys_getrandom call.
So, categorizing this bug: the issue is about an unsupported syscall. It seems like the problem is that the ARMv7 qemu isn't handling the getrandom system call correctly, which is why it's throwing those messages. The user hasn't encountered any runtime issues beyond the messages, so it doesn't fall under 'runtime' errors. It’s more specific to a missing or unimplemented syscall.
Therefore, this should be classified under 'syscall'.
</think>
The issue involves an unsupported system call (getrandom) in the QEMU environment, leading to repeated error messages. This is related to a missing implementation of sys_getrandom rather than a runtime error or faulty instruction.
sys_getrandom
The bug report describes an error with a syscall being unsupported in qemu.
syscall
|