In my case the issue with using Ubuntu 20.04 as a container host appears
to have come down to the use of the F, or "fix binary", flag by
binfmnt_misc:
# cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/bin/qemu-aarch64-static
flags: OCF
offset 0
magic 7f454c4602010100
Could you try the attached patch?
** Patch added: "SO_PEERGROUPS.patch"
https://bugs.launchpad.net/qemu/+bug/1823790/+attachment/5405549/+files/SO_PEERGROUPS.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
SO_PEERGROUPS is not implemented and processed as an "int" (this
explains the ERANGE)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into
I can confirm that I see the same issue when trying to run Ubuntu 20.04
aarch64 in a container, strace shows a tight loop on:
getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1
ERANGE
Re-building qemu-user-static with the patch has fixed Debian 10 armhf
for me, but the same re-bu
Hmm, I'm using qemu-5.1.0 and I'm still seeing this (host is bionic,
container image is focal)
[..]
getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE
(Numerical result out of range)
getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE
(Numerical res
Sorry, posted this on the wrong bug :-/
I beg your pardon for the noise.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Bisect worked and once you find it it seems obvious that this is exactly
our case:
commit 65b261a63a48fbb3b11193361d4ea0c38a3c3dfd
Author: Laurent Vivier
Date: Thu Jul 9 09:23:32 2020 +0200
linux-user: add netlink RTM_SETLINK command
This command is needed to be able to boot syste
Fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6d485a55d0cd
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title
This seems to be the error reported in
https://bugs.launchpad.net/qemu/+bug/1857811
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Laurent's patch worked for me as well.
I grabbed the source for the Debian 10 qemu-user-static package,
qemu_3.1+dfsg-8+deb10u3, applied the patch and re-built the qemu-arm-
static binary. Copying the new binary into a Docker image based on
arm32v7/debian:10-slim allowed /sbin/init to bring up the
Well, it's kind of irrelevant but I am trying that on archlinux and this
does not work for me.
Using systemd-244.2-1 and qemu-user-static-4.2 that I built with
Laurent's patch. May be I have done something wrong ?
I still get that error that leads me here:
Failed to enqueue loopback interface st
I carried out the following test:
* fetched the QEMU coming with 18.04,
* added this patch,
* built an LXD container with arch arm64 and the patched qemu-aarch64-static
inside,
* launched it on amd64
Previously various systemd services would not come up properly, now they
are running like a char
> Could you test the attached patch?
>
Works great!
This is my test setup:
Host machine: Ubuntu 18.04, amd64
LXD container: Debian Buster, arm64, systemd 241
QEMU: qemu-aarch64(-static), compiled from source (4.2.0), patched with
your patch.
Many thanks!
Matthias
--
You received this bug noti
Thanks, Laurent! I'll get back to you, asap.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Confirmed
Could you test the attached patch?
** Patch added: "Implement SO_PEERSEC"
https://bugs.launchpad.net/qemu/+bug/1823790/+attachment/5324494/+files/0001-linux-user-implement-TARGET_SO_PEERSEC.patch
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subsc
** Changed in: qemu
Assignee: (unassigned) => Laurent Vivier (laurent-vivier)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into ti
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Status in QEMU:
Con
I'm a bit surprised that this bug doesn't get more attention, as it
makes it very hard to run qemu-emulated containers of Bionic hosted on
Bionic. Running such containers is a common way to cross-compile
packages for foreign architectures in the absence of sufficiently
powerful target HW.
The docu
I patched linux-user/syscall.c (see below, branch stable-2.11) which works
around my problem.
So far so good, but the qemu-arm that i compiled is terribly slow compared to
the one that came with Ubuntu 18.04. Any hints?
I configured as this:
./configure --static --enable-kvm --target-list=arm-lin
I filed the duplicate #1840252 of this bug.
I think that the options SO_PEERCRED and SO_PEERSEC belong into the
context of SELINUX. So maybe the format of the paylod can be found in
the sources of libselinux?
I'd like to compile qemu with a local hack to work around my current
problem. Something
I have just studied a bit the systemd code and this brought me to the
following idea/temporary workaround: What about returning -1 (error) and
setting errno when getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) gets
called? This would then let systemd know that SO_PEERSEC is not (yet)
implemented.
--
This is probably the tight loop that gets triggered:
https://github.com/systemd/systemd/commit/217d89678269334f461e9abeeffed57077b21454
It looks like the previous implementation was just a bit more
"tolerant".
--
You received this bug notification because you are a member of qemu-
devel-ml, whic
As described on the systemd issue, the syscall we're getting wrong here
is getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...). Our linux-
user/syscall.c:do_getsockopt() doesn't have any special case code for
the payload on this function, so we treat it as if it were just an
integer payload, which is not c
23 matches
Mail list logo
