Buildah

Download

buildah@lists.buildah.io

September 2026

2 participants
2 discussions

Podman, Buildah, and Podman Desktop Mailing List Upgrade and Downtime (try two, with the right list addresses for Buildah and Podman Desktop)
by Tom Sweeney 30 Sep '26

30 Sep '26

-------- Forwarded Message -------- Subject: Podman, Buildah, and Podman Desktop Mailing List Upgrade and Downtime Date: Wed, 30 Sep 2026 11:36:06 -0400 From: Tom Sweeney <tom.sweeney(a)redhat.com> To: podman(a)lists.podman.io, buildah(a)list.podman.io, Podman-desktop(a)list.podman.io Hi Folks, On Sunday October 4, 2026 at 9:30 pm EDT (UTC-4), the Podman related mailing lists will be going down for a few hours in order to do an upgrade. During that time, emails will likely be returned to the sender, or possibly drop somewhere into the ether in CyberSpace. The upgrade should take under 4 hours, and we plan to have the system back around 1:30 am EDT on Monday October 5, 2026. After the upgrade, you should not notice any difference in the list when interacting with it via your favorite email interface. If you use the web interface for the list at: https://lists.podman.io/, you will see some changes there, and there should be some nice improvements for administration tasks on the site. NOTE: If you use Fedora Authorization to log into the web interface, you will not be able to log in via that. You'll need to use the lost password mechanism to set up a new password. From what we can see, only 5 people have used Fedora to authenticate to that list in the past year, so we hope this will be a minimal disruption. Regards, t

1 0

Skip tarball generation for layers when building a container image
by Dick Marinus 27 Sep '26

27 Sep '26

Hi! Last month I started the following topic at github discussions but I didn't receive any replies. https://github.com/podman-container-tools/buildah/discussions/7060 So I'm trying again here, I hope someone responds. I'm using buildah to build large (20GB) images, I'm not interested in pushing the image to a registry because I'm using it to build a squashfs image from the contents. I like the intermediate layers when building an image which allow me to restart at a failing step (skipping all steps that completed successfully). But as the image increases in size during build, the layers grow as well and a tarball is generated for every layer in $TMPDIR which requires a lot of disk space, wasted time and wear on my SSD. Currently I'm working around this by using a shell script instead of a Containerfile which uses the following shell script: ```bash #!/bin/bash set -eux SRC=$1 DST=$2 buildah from --name=$DST scratch buildah unshare << @EOF set -eu SRC_MOUNT=\$(buildah mount $SRC) DST_MOUNT=\$(buildah mount $DST) shopt -s dotglob cp --reflink=always -rp \${SRC_MOUNT}/* \${DST_MOUNT}/ @EOF ``` To create a reflinked clone of a buildah container. But this only works on btrfs (and zfs?). This leads me to two questions: 1. Would it be possible to disable this tarball generation when using a Containerfile, with the side note that the generated image cannot be pushed? 1. Would it be a good idea to add a `buildah clone` command for this? There's already `podman clone` but that creates a new container from the source image discarding all changes from the source container.

1 0