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
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.
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
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
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
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
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
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.
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
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
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
> 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
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
** 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
** 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:
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
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
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,
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
23 matches
Mail list logo
