Bug#1016195: podman: fails to run any container
Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: vincent.olivert.ri...@gmail.com
Dear Maintainer,
I'm strictly running Debian stable with no packages from testing or
unstable.
When trying to run any container with podman I see the following error:
$ podman run --rm -it debian:bullseye-slim bash
Error: OCI runtime error: container_linux.go:367: starting container process
caused: process_linux.go:340: applying cgroup configuration for process caused:
error while starting unit
"libpod-410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3.scope"
with properties [{Name:Description Value:"libcontainer container
410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3"} {Name:Slice
Value:"user.slice"} {Name:PIDs Value:@au [69240]} {Name:Delegate Value:true}
{Name:MemoryAccounting Value:true} {Name:CPUAccounting Value:true}
{Name:IOAccounting Value:true} {Name:DefaultDependencies Value:false}
{Name:DevicePolicy Value:"strict"} {Name:DeviceAllow Value:@a(ss) []}
{Name:DeviceAllow Value:["INVALID", "INVALID", "INVALID", "INVALID", "INVALID",
"INVALID", "INVALID", "INVALID", "INVALID", "INVALID", "INVALID"]}
{Name:TasksAccounting Value:true} {Name:TasksMax Value:@t 2048}]: error
creating systemd unit
`libpod-410aba7b65566d9ddf2f0d2f188a22ed53577b90eea67e773c8294fa8bd252f3.scope`:
got `failed`
I tried replacing runc with crun, but the same problem persist, although
the error message is shorter:
$ podman run --rm -it debian:bullseye-slim bash
Error: OCI runtime error: error creating systemd unit
`libpod-df9c347e24f4ea213f8c81d6211f60e015e48b2f4b9118558f9fa95f8c7610fd.scope`:
got `failed`
Just in case it matters, my system is up to date and the version of
systemd I have installed is 247.3-7.
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
ii containernetworking-plugins 0.9.0-1+b6
ii golang-github-containers-common 0.33.4+ds1-1+deb11u1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc62.31-13+deb11u3
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
ii runc 1.0.0~rc93+ds1-5+deb11u2
Versions of packages podman recommends:
ii buildah 1.19.6+dfsg1-1+b6
ii fuse-overlayfs1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
ii tini 0.19.0-1
ii uidmap1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage
pn docker-compose
-- no debconf information
Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot
Package: src:linux Followup-For: Bug #1012210 X-Debbugs-Cc: vincent.olivert.ri...@gmail.com I'm running Debian stable on a VM from an Apple MacBook Pro M1 14" 2021. The software I'm using is UTM, which uses QEMU under the hood. Yesterday I did a system upgrade: aptitude -y update && aptitude -y full-upgrade && apt -y autoremove I noticed the kernel was upgraded to 5.10.0-14 so I rebooted the VM. After that Debian was unable to boot. Choosing the previous kernel image available from Grub (5.10.0-13) allowed Debian to boot normally. Regards, Vincent
Bug#1012030: (no subject)
Dear Reinhard Tartler, I have tried what you suggested, and indeed, it does work. See: $ # CHECK BOTH CRUN AND RUNC ARE INSTALLED $ dpkg -s runc | grep -E '^Status' Status: install ok installed $dpkg -s crun | grep -E '^Status' Status: install ok installed $ # RUN COMMAND WITHOUT THE SUGGESTED WORKAROUND $ podman run --runtime runc --rm -it debian date Error: container_linux.go:367: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied $ # RUN COMMAND WITH THE SUGGESTED WORKAROUND $ podman run --runtime runc --security-opt=seccomp=unconfined --rm -it debian date Mon May 30 23:33:32 UTC 2022 Thanks, Vincent On 31/05/2022 04:28, Reinhard Tartler wrote: I wonder whether this may be related to upstream report at https://github.com/containers/common/issues/631 <https://github.com/containers/common/issues/631> It seems that in debian/bullseye, podman is only able to work in crun, since the version of runc we have in stable seems to have issues with seccomp. Can you please try the following for me with both crun and runc installed: root@pve:~# podman run --runtime runc --security-opt=seccomp=unconfined --rm -it debian date Mon May 30 19:18:05 UTC 2022 That does appear to work at least on my system. This might indicate that this is actually a change that needs to go into golang-github-containers-common then... On Mon, May 30, 2022 at 9:15 AM Vicente Olivert Riera <mailto:vincent.olivert.ri...@gmail.com>> wrote: I've found the problem appears to be between podman and runc. I have runc installed in my system because I also use docker.io <http://docker.io>, and that package depends on it. runc is also a dependency of podman, so podman uses it. However, podman can also use crun. But, since runc was already installed, and podman can depend on either of them, crun was not installed as a dependecy. Now, if I manually install crun, podman works again and the error is gone. I think if podman finds that crun is installed, it will use it. Otherwise it will use runc as a fallback. Since both runc and crun packages can coexist in the system, I think a quick fix could be removing the runc dependency on podman, so it will always pull in crun as a dependency. At least until the root cause of this problem is found and fixed. -- regards, Reinhard OpenPGP_0x5DE0950419F6E531.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1012030: (no subject)
I've found the problem appears to be between podman and runc. I have runc installed in my system because I also use docker.io, and that package depends on it. runc is also a dependency of podman, so podman uses it. However, podman can also use crun. But, since runc was already installed, and podman can depend on either of them, crun was not installed as a dependecy. Now, if I manually install crun, podman works again and the error is gone. I think if podman finds that crun is installed, it will use it. Otherwise it will use runc as a fallback. Since both runc and crun packages can coexist in the system, I think a quick fix could be removing the runc dependency on podman, so it will always pull in crun as a dependency. At least until the root cause of this problem is found and fixed. OpenPGP_0x5DE0950419F6E531.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1012030: podman: Fails to run any container
Package: podman Version: 3.0.1+dfsg1-3+deb11u1 Severity: important X-Debbugs-Cc: vincent.olivert.ri...@gmail.com Dear Maintainer, Podman has stopped working (atleast for me) without having modified anything from its configuration. I simply try to run 'bash' from a Debian container, and it crashes like this: $ podman run --rm -it debian bash Resolved "debian" as an alias (/etc/containers/registries.conf.d/shortnames.conf) Trying to pull docker.io/library/debian:latest... Getting image source signatures Copying blob e756f3fdd6a3 done Copying config 4eacea3037 done Writing manifest to image destination Storing signatures Error: container_linux.go:367: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied $ -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-14-amd64 (SMP w/2 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii golang-github-containers-common 0.33.4+ds1-1+deb11u1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u3 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 ii runc 1.0.0~rc93+ds1-5+b2 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose
Bug#756764: (no subject)
Fixed upstream: http://anonscm.debian.org/cgit/collab-maint/ltrace.git/commit/?id=a8ff0ff2b6e6c229f8a9242828fb47f1a5a78967 This bug can be closed. Regards, -Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756764: (no subject)
ping -- Vicente Olivert Riera Graduate Software Engineer, MIPS Processor IP Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756764: (no subject)
The problem is caused by an old version of libelf provided by libelf package. Using the version provided by elfutils package works fine. This is finally not a ltrace problem itself, but a problem of libelf being incompatible with ltrace. -- Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756764: (no subject)
I'm sorry, ignore my last message please. -- Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756764: ltrace fails to compile for MIPS
Package: ltrace Version: 0896ce554f80afdcba81d9754f6104f863dea803 I have found that ltrace fails to compile for MIPS architecture because in the file 'sysdeps/linux-gnu/mips/plt.c' line #241 it tries to access to a struct member which doesn't exists: lte-relplt_count = lte-dynsym_count - lte-arch.mips_gotsym; The member 'relplt_count' doesn't exists in the 'lte' struct, which has a 'struct ltelf' type defined in the 'ltrace-elf.h' file. I have reviewed the 'plt.c' file for the other architectures and MIPS is the only one who tries to access to 'lte-relplt_count', so maybe the code of the struct (in ltrace-elf.h) changed and the 'plt.c' file for the MIPS architecture hasn't been updated. Here is the build failure: libtool: compile: /home/test/autobuild/instance-1/output/host/usr/bin/mips-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../.. -DSYSCONFDIR=\/etc\ -DPKGDATADIR=\/usr/share/ltrace\ -I../../../sysdeps/linux-gnu/mips -I../../../sysdeps/linux-gnu -I../../../sysdeps -I../../.. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wsign-compare -Wfloat-equal -Wformat-security -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -MT trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -fPIC -DPIC -o .libs/trace.o plt.c: In function 'arch_elf_init': plt.c:241:5: error: 'struct ltelf' has no member named 'relplt_count' -- Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
