Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver
On Tue, 23 Jan 2024, at 16:19, Faidon Liambotis wrote: > I think that's big enough to make me at least a bit uncomfortable about > a cherry-pick to stable. Could you elaborate on your use case? It sounds > like this manifests only with a large number of layers, and I'm not sure > how common this is. Thanks for taking a look. I'm just running the home-assistant container ghcr.io/home-assistant/home-assistant. > The alternative to a stable update is a backport of the latest podman > version (currently 4.8.3), plus associated packages like > containers/storage, of course. It's a moderate amount of work; Reinhard > who's been doing the version updates in unstable could speak more to the > work he's been putting into package updates etc. It would help with > bringing in a lot of more fixes from what I'd consider a very active > upstream. We also have #1059496, as another recent, concrete example. > > I'm still unsure and debating targeted s-p-u fixes vs. a backport. My > concern is basically that we may start playing whack-a-mole. A quick > peek at the upstream changelog reveals tons of fixed bugs in every > release, and us trying to keep up by cherry-picking fixes to two years > of upstream development may prove futile... > > Thoughts? I think backporting makes sense to me. In fact I built my own podman from upstream in the meantime.. Actually, I initially submitted a backport request. But gibmat thought it would be better to have it fixed in stable so everyone benefits, although I agree it's not a common thing to run into. -- Hao Wei
Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver
Control: reassign -1 src:golang-github-containers-storage 1.43.0+ds1-8 Control: fixed -1 1.45.1+ds1-1 Control: affects -1 src:libpod On Sun, Jan 21, 2024 at 01:17:46AM +0800, Tee Hao Wei wrote: > Oh. I just noticed how Debian handles Go dependencies.. > > I guess this will actually need to be a cherry-pick to > golang-github-containers-storage-dev followed by a rebuild of podman. That's right, this is technically a golang-github-containers-storage-dev bug, so reassigning there. FWIW: $ git describe --contains 7c5964df95c892cfbdbce594cf5a8e2973c70fd7 v1.44.0~28^2 $ git describe --contains d232b36652d55b42a21f1713db7f7d455b837b3c v1.44.0~9^2 $ git checkout v1.43.0 HEAD is now at 04d8b90f9 Bump to v1.43.0 $ git cherry-pick 7c5964df95c892cfbdbce594cf5a8e2973c70fd7 d232b36652d55b42a21f1713db7f7d455b837b3c [...] $ $ git diff --stat v1.43.0.. drivers/overlay/mount.go | 97 - drivers/overlay/overlay.go | 50 tests/layers.bats | 40 +-- 3 files changed, 143 insertions(+), 44 deletions(-) I think that's big enough to make me at least a bit uncomfortable about a cherry-pick to stable. Could you elaborate on your use case? It sounds like this manifests only with a large number of layers, and I'm not sure how common this is. The alternative to a stable update is a backport of the latest podman version (currently 4.8.3), plus associated packages like containers/storage, of course. It's a moderate amount of work; Reinhard who's been doing the version updates in unstable could speak more to the work he's been putting into package updates etc. It would help with bringing in a lot of more fixes from what I'd consider a very active upstream. We also have #1059496, as another recent, concrete example. I'm still unsure and debating targeted s-p-u fixes vs. a backport. My concern is basically that we may start playing whack-a-mole. A quick peek at the upstream changelog reveals tons of fixed bugs in every release, and us trying to keep up by cherry-picking fixes to two years of upstream development may prove futile... Thoughts? Thanks, Faidon
Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver
Oh. I just noticed how Debian handles Go dependencies.. I guess this will actually need to be a cherry-pick to golang-github-containers-storage-dev followed by a rebuild of podman.
Bug#1061194: podman: cannot run rootful containers with many layers using overlay driver
Package: podman Version: 4.3.1+ds1-8+b1 Severity: normal Tags: patch upstream X-Debbugs-Cc: t...@in04.sg bookworm's podman has a bug that prevents it from running images that have many layers in rootful mode using the overlay storage driver. The bug was reported upstream here[1] and fixed in [2], which was picked up in podman v4.4. The patch in [2] depends on at least this[3] other commit. Could you please cherry-pick the fix? Thank you. As an aside: the root cause is that the overlay driver ends up passing the wrong (non-idmapped) lower dirs to overlayfs when the mount arguments exceed one page (4K), which is why this is only seen with images with many layers, and only when running as root (since idmapped mounts require root). [1] https://github.com/containers/storage/issues/1410 [2] https://github.com/containers/storage/pull/1411 [3] https://github.com/containers/storage/commit/7c5964df95c892cfbdbce594cf5a8e2973c70fd7 -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 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.1.6+ds1-1 ii crun 1.8.1-1+deb12u1 ii golang-github-containers-common 0.50.1+ds1-4 ii libc62.36-9+deb12u3 ii libdevmapper1.02.1 2:1.02.185-2 ii libgpgme11 1.18.0-3+b1 ii libseccomp2 2.5.4-1+b3 ii libsubid41:4.13+dfsg1-1+b1 Versions of packages podman recommends: ii buildah1.28.2+ds1-3+b1 ii catatonit 0.1.7-1+b1 ii dbus-user-session 1.14.10-1~deb12u1 ii fuse-overlayfs 1.10-1 ii slirp4netns1.2.0-1 ii uidmap 1:4.13+dfsg1-1+b1 Versions of packages podman suggests: pn containers-storage pn docker-compose ii iptables1.8.9-2 -- no debconf information
