In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned |
Bug Description
On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via
/usr/sbin/
from
qemu-linux-
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:/
[10:05] clever arch/arm/
[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
Changed in qemu: | |
status: | New → Incomplete |
arm32 syscall 384 is indeed getrandom, but QEMU implemented this in commit f894efd19917321 as of Feb 2016, which should be in 2.6 or later. I've just checked and the LTP test cases for getrandom all pass with qemu-arm-user and do invoke the getrandom syscall and don't provoke the warning from QEMU.
Can you check that the qemu-arm-static binary inside the chroot is really 2.9 and not an older version?