summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/kernel/1689367
blob: f65f8b1120b22017fe639b02369c355836c03708 (plain) (blame)
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
In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages.  sys_getrandom ?

On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via

	/usr/sbin/qemu-binfmt-conf.sh

from

	qemu-linux-user-2.9.0-374.1.x86_64

on the host, inside the chroot any compile activity is laced with repetitions of

	qemu: Unsupported syscall: 384

messages.

This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim.  These messages appear to be non-fatal, with no particular effect at all; at least not so far ...

From a chat in #IRC,

	[10:05] davidgiluk clever/pgnd: I see it as getrandom
	[10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html   sort it on the ARM table and you can easily see it
	[10:05] clever arch/arm/tools/syscall.tbl:384  common  getrandom               sys_getrandom
	[10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom
	[10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational?
	[10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point