Description of problem: Fedora images hosted on registry.fedoraproject.org do not have a 'PATH' environment variable defined on them: podman image inspect --format "{{.Config.Env}}" registry.fedoraproject.org/fedora:38 [DISTTAG=f38container FGC=f38 container=oci] their docker.io equivalents do: podman image inspect --format "{{.Config.Env}}" docker.io/fedora:38 [PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DISTTAG=f38container FGC=f38 FBR=f38] This fact causes subtle discrepancies when alternating between those two. While I didn't have time to dig into OCI specs to see if there's any requirement on this, it seems that having a 'PATH' env variable defined is "what docker does, so we should copy it" [1]. So if you try to build a container like this with buildah: FROM fedora:38 RUN echo "${PATH}" There will be no difference between the docker.io version and registry.fp.org one. If you try to do the same with kaniko however, the results will differ: podman run -v .:/hello:Z --workdir /hello gcr.io/kaniko-project/executor:latest --dockerfile Containerfile.docker.io --no-push ... /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin podman run -v .:/hello:Z --workdir /hello gcr.io/kaniko-project/executor:latest --dockerfile Containerfile.registry.fedoraproject.org --no-push ... /usr/local/bin:/usr/bin Kaniko follows docker's logic, but only if the user didn't define any variables [2]. I've stumbled upon a case where it does matter - I was trying to do gcc compilation during container image build done with kaniko. As soon as I hit docker.io quotas and switched to registry.fedoraproject.org I got these errors: ... checking for c compiler... no cleaning temporally files... done ERROR: gcc cannot create executables Most probably gcc relies 'PATH' variable definition to look for helper programs (cc1 in this case). You can reproduce this by trying to build a container with kaniko and this containerfile: FROM registry.fedoraproject.org/fedora:38 RUN dnf install -y gcc RUN echo "int main() {}" > /tmp/hello.c RUN gcc -v /tmp/hello.c -o /tmp/hello I think kaniko itself should be patched to follow the standard 'PATH' value if the _'PATH' var itself_ wasn't defined. Nevertheless, following the "explicit is better than implicit" rule I would propose adding 'PATH' definition to Fedora's containerfile template. I've posted an MR for this [3]. Version-Release number of selected component (if applicable): All Fedora container images on registry.fedoraproject.org are affected. [1] https://github.com/containers/buildah/commit/72e0721b2b1a28e895c2a1b1b1dd55993e3182e4 [2] https://github.com/GoogleContainerTools/kaniko/blob/885ff5f57b1cc450ea46dd76c0d48eb3b047d441/pkg/executor/build_test.go#L506 [3] https://github.com/fedora-cloud/fedora-container-release/pull/1
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.