Don't use sudo podman aka rootless builds#46
Conversation
| || exit 1 | ||
| else | ||
| sudo podman pull $IMAGE || exit 1 | ||
| podman pull $IMAGE || exit 1 |
There was a problem hiding this comment.
Code Review
This pull request removes sudo from several podman commands to run them in rootless mode, adds the --in-vm flag to the podman run command, and removes the image digest pin from the base image in the Containerfile. The feedback highlights critical issues introduced by running rootless: the hardcoded volume mount for container storage will fail because rootless storage resides in the user's home directory, and the --cap-add LINUX_IMMUTABLE flag may not function correctly without root privileges. Additionally, it is recommended to restore the image digest pin to ensure build reproducibility and security.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| if [ "$BUILD_BOOTC" == true ]; then | ||
| mkdir -p output | ||
| sudo podman run \ | ||
| podman run \ |
There was a problem hiding this comment.
When running podman in rootless mode (by removing sudo), the container storage is typically located in the user's home directory (e.g., ~/.local/share/containers/storage) rather than the global /var/lib/containers/storage.
Because line 41 hardcodes the volume mount -v /var/lib/containers/storage:/var/lib/containers/storage, the rootless podman run command will fail to find the locally built/pulled $IMAGE or fail due to permission issues on /var/lib/containers/storage.
To support both rootful and rootless builds dynamically, you can query the active storage path using podman info and mount that directory instead:
storage_dir=$(podman info --format '{{ .Store.GraphRoot }}')
podman run \
...
-v "$storage_dir":/var/lib/containers/storage \
...| # This Containerfile is based on an ansible playbook for provisioning Copr builders | ||
| # https://pagure.io/fedora-infra/ansible/blob/main/f/roles/copr/backend/files/provision/provision_builder_tasks.yml | ||
| FROM quay.io/fedora/fedora-bootc:44@sha256:db4ce967bfd6fd136ce78d898a45fcb6af9e6d00a44cf316037cbb7176b6a9d5 | ||
| FROM quay.io/fedora/fedora-bootc:44 |
There was a problem hiding this comment.
Removing the image digest (@sha256:...) reduces build reproducibility and security, as the base image tag quay.io/fedora/fedora-bootc:44 can be updated or overwritten in the registry. It is recommended to keep the base image pinned to a specific digest to ensure consistent and predictable builds.
FROM quay.io/fedora/fedora-bootc:44@sha256:db4ce967bfd6fd136ce78d898a45fcb6af9e6d00a44cf316037cbb7176b6a9d5
| # The LINUX_IMMUTABLE is needed for doing chattr when building the image. | ||
| # We use it for Internal Copr builders | ||
| sudo podman build \ | ||
| podman build \ |
There was a problem hiding this comment.
In rootless mode, --cap-add LINUX_IMMUTABLE may not grant the actual capability to set or modify immutable file attributes (such as chattr +i) because the rootless user lacks these privileges on the host. If the build process relies on this capability (as indicated by the comment on line 19), the build might fail or behave unexpectedly when run without sudo.
There is an experimental support for rootless builds https://osbuild.org/docs/bootc/#rootless
|
The feature is experimental and the build currently fails with Upstream issue reported here: osbuild/image-builder#2425 |
|
@joelcapitao is currently building VM images in Konflux, so we definitely want to re-use as much of their work as possible. I am copy-pasting the full quote here because I only half-understand what they are doing:
|
There is an experimental support for rootless builds
https://osbuild.org/docs/bootc/#rootless