fix: use the podman image's native overlay storage #13

Merged

mlvtito merged 1 commit from fix/use-native-overlay into main

2026-11-15 22:03:17 +00:00

hermes_forgeron commented

2026-11-15 21:59:43 +00:00

Collaborator

Fifth iteration on #7 — and this one answers your question: why vfs at all?

Short answer: we shouldn't. vfs was my initial "safe in nested containers" choice, but the four runs disprove the precaution:

podman login worked from the very first run → the image's storage is already functional;
the overlay database is native and pre-configured in quay.io/podman/stable (built for podman-in-podman, with its VOLUME);
every way of forcing vfs — CLI flag, /etc/containers/storage.conf, redirected graphroot — hit the same mismatch, because podman 5 refuses driver switches against that native database, and driver in storage.conf only applies at database creation time.

So the fix is a removal: drop the storage step entirely and the --storage-driver=vfs flag — podman uses its native, self-consistent overlay setup. Fewer lines, no overrides, matches how the image is designed to be used.

Fallback if the kernel ever refuses overlay-on-overlay (unlikely under --privileged): podman will say so explicitly (overlay is not available), and the next step would be an explicit fuse-overlayfs configuration — but that is speculative; the evidence says the native storage works here.

Wiki updates on merge

Nothing to update in the Wiki.

Fifth iteration on #7 — and this one answers your question: **why vfs at all?** Short answer: we shouldn't. vfs was my initial "safe in nested containers" choice, but the four runs disprove the precaution: - `podman login` worked from the very first run → the image's storage is already functional; - the overlay database is **native and pre-configured** in `quay.io/podman/stable` (built for podman-in-podman, with its VOLUME); - every way of forcing vfs — CLI flag, `/etc/containers/storage.conf`, redirected graphroot — hit the same mismatch, because podman 5 refuses driver switches against that native database, and `driver` in storage.conf only applies at database creation time. So the fix is a removal: **drop the storage step entirely and the `--storage-driver=vfs` flag** — podman uses its native, self-consistent overlay setup. Fewer lines, no overrides, matches how the image is designed to be used. Fallback if the kernel ever refuses overlay-on-overlay (unlikely under `--privileged`): podman will say so explicitly (`overlay is not available`), and the next step would be an explicit `fuse-overlayfs` configuration — but that is speculative; the evidence says the native storage works here. ## Wiki updates on merge Nothing to update in the Wiki.

hermes_forgeron added 1 commit

2026-11-15 21:59:43 +00:00

fix: use the podman image's native overlay storage f5ff3026ea

Four runs proved the overlay database of quay.io/podman/stable is
native and pre-configured (login always worked); forcing vfs — via
flag or storage.conf, at any graph root — always hit the same
configuration mismatch. Drop the veto: no storage overrides at all.