Closed samuelvl closed 2 years ago
@nalind PTAL
Could be caused by fuse-overlayfs. Can you show the output of podman info
? In that case, can you try with native overlay?
Could be caused by fuse-overlayfs. Can you show the output of
podman info
? In that case, can you try with native overlay?
You are right, if I force the build with overlay
or vfs
it works:
$ buildah build --storage-driver=overlay -f Dockerfile
OK!
$ buildah build --storage-driver=vfs -f Dockerfile
OK!
How can I force buildah to use native overlay in the storage.conf
file instead of using the --storage-driver
flag?
Output of podman info
:
host:
arch: amd64
buildahVersion: 1.23.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.30-2.fc34.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.30, commit: '
cpus: 8
distribution:
distribution: fedora
variant: workstation
version: "34"
eventLogger: journald
hostname: redhat
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 5.15.12-100.fc34.x86_64
linkmode: dynamic
logDriver: k8s-file
memFree: 21381730304
memTotal: 33425088512
ociRuntime:
name: crun
package: crun-1.4-1.fc34.x86_64
path: /usr/bin/crun
version: |-
crun version 1.4
commit: 3daded072ef008ef0840e8eccb0b52a7efbd165d
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
path: /run/user/1000/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.12-2.fc34.x86_64
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.4.0
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.3
swapFree: 17179860992
swapTotal: 17179860992
uptime: 24m 4.46s
plugins:
log:
- k8s-file
- none
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
- quay.io
store:
configFile: /home/samu/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-1.7.1-2.fc34.x86_64
Version: |-
fusermount3 version: 3.10.4
fuse-overlayfs: version 1.7.1
FUSE library version 3.10.4
using FUSE kernel interface version 7.31
graphRoot: /var/lib/containers
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageStore:
number: 3
runRoot: /run/user/1000/containers
volumePath: /var/lib/containers/volumes
version:
APIVersion: 3.4.2
Built: 1636849008
BuiltTime: Sun Nov 14 01:16:48 2021
GitCommit: ""
GoVersion: go1.16.8
OsArch: linux/amd64
Version: 3.4.2
that should happen by default if you start with a fresh storage and the kernel supports it.
Otherwise, you can just force the mount_program=""
to have an empty value
and I think this is not even a fuse-overlayfs issue. It is pip to not handle EXDEV
Check or remove the storage.conf from your homedir. ls ~/.config/containers/storage.conf
Thanks! Removing the local storage.conf
or setting mount_program=""
fixes the issue so I think this can be closed.
As @giuseppe mentioned, I believe the root cause is in pip, similar to this issue https://github.com/pypa/pip/issues/103
thanks for confirming it!
Description When running buildah or podman in rootless mode on a Dockerfile that uses
pip
to install packages I get the following error for some packages (e.g. pip itself):The error appears when using
registry.access.redhat.com/ubi8/python-38:latest
anddocker.io/python:3.9.9-slim
as base image, so an image-related error can be discarded.If I build the image using the root user the error disappears.
Steps to reproduce the issue:
buildah
it in rootless mode:Describe the results you received: I get the following error:
Describe the results you expected: No error.
Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:Output of
podman version
if reporting apodman build
issue:*Output of `cat /etc/release`:**
Output of
uname -a
:Output of
cat /etc/containers/storage.conf
:Output of
df -h /var/lib/containers
:Output of
grep /var/lib/containers /proc/mounts
: