error with overlayfs inside a pod

[vbatts]

Description
carrying over the finding from knative/build-templates#7 (comment)

Steps to reproduce the issue:

1. running buildah inside a container as root, with a volume as /var/lib/containers

Describe the results you received:

time="2018-08-06T17:20:11Z" level=error msg="'overlay' is not supported over xfs at \"/var/lib/containers/storage/overlay\""
time="2018-08-06T17:20:11Z" level=error msg="'overlay' is not supported over xfs at \"/var/lib/containers/storage/overlay\""
kernel does not support overlay fs: 'overlay' is not supported over xfs at "/var/lib/containers/storage/overlay": backing file system is unsupported for this graph driver
kernel does not support overlay fs: 'overlay' is not supported over xfs at "/var/lib/containers/storage/overlay": backing file system is unsupported for this graph driver

Describe the results you expected:
overlayfs + xfs supported

Output of buildah version:

[root@2bc0838df8b2 /]# buildah version
Version:         1.4-dev
Go Version:      go1.9.4
Image Spec:      1.0.0
Runtime Spec:    1.0.0
CNI Spec:        0.3.1
libcni Version:  v0.6.0
Git Commit:      0a7389c
Built:           Wed Aug 15 18:18:00 2018
OS/Arch:         linux/amd64

Output of cat /etc/*release:

[root@2bc0838df8b2 /]# cat /etc/*release
CentOS Linux release 7.5.1804 (Core) 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.5.1804 (Core) 
CentOS Linux release 7.5.1804 (Core) 

Output of uname -a:

Linux 2bc0838df8b2 4.17.3-200.fc28.x86_64 #1 SMP Tue Jun 26 14:17:07 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Output of cat /etc/containers/storage.conf:

# storage.conf is the configuration file for all tools
# that share the containers/storage libraries
# See man 5 containers-storage.conf for more information
# The "container storage" table contains all of the server options.
[storage]

# Default Storage Driver
driver = "overlay"

# Temporary storage location
runroot = "/var/run/containers/storage"

# Primary Read/Write location of container storage
graphroot = "/var/lib/containers/storage"

[storage.options]
# Storage options to be passed to underlying storage drivers

# AdditionalImageStores is used to pass paths to additional Read/Only image stores
# Must be comma separated list.
additionalimagestores = [
]

# Size is used to set a maximum size of the container image.  Only supported by
# certain container storage drivers.
size = ""

# OverrideKernelCheck tells the driver to ignore kernel checks based on kernel version
override_kernel_check = "true"

# Remap-UIDs/GIDs is the mapping from UIDs/GIDs as they should appear inside of
# a container, to UIDs/GIDs as they should appear outside of the container, and
# the length of the range of UIDs/GIDs.  Additional mapped sets can be listed
# and will be heeded by libraries, but there are limits to the number of
# mappings which the kernel will allow when you later attempt to run a
# container.
#
# remap-uids = 0:1668442479:65536
# remap-gids = 0:1668442479:65536

# Remap-User/Group is a name which can be used to look up one or more UID/GID
# ranges in the /etc/subuid or /etc/subgid file.  Mappings are set up starting
# with an in-container ID of 0 and the a host-level ID taken from the lowest
# range that matches the specified name, and using the length of that range.
# Additional ranges are then assigned, using the ranges which specify the
# lowest host-level IDs first, to the lowest not-yet-mapped container-level ID,
# until all of the entries have been used for maps.
#
# remap-user = "storage"
# remap-group = "storage"

[storage.options.thinpool]
# Storage Options for thinpool

# autoextend_percent determines the amount by which pool needs to be
# grown. This is specified in terms of % of pool size. So a value of 20 means
# that when threshold is hit, pool will be grown by 20% of existing
# pool size.
# autoextend_percent = "20"

# autoextend_threshold determines the pool extension threshold in terms
# of percentage of pool size. For example, if threshold is 60, that means when
# pool is 60% full, threshold has been hit.
# autoextend_threshold = "80"

# basesize specifies the size to use when creating the base device, which
# limits the size of images and containers.
# basesize = "10G"

# blocksize specifies a custom blocksize to use for the thin pool.
# blocksize="64k"

# directlvm_device specifies a custom block storage device to use for the
# thin pool. Required if you setup devicemapper
# directlvm_device = ""

# directlvm_device_force wipes device even if device already has a filesystem
# directlvm_device_force = "True"

# fs specifies the filesystem type to use for the base device.
# fs="xfs"

# log_level sets the log level of devicemapper.
# 0: LogLevelSuppress 0 (Default)
# 2: LogLevelFatal
# 3: LogLevelErr
# 4: LogLevelWarn
# 5: LogLevelNotice
# 6: LogLevelInfo
# 7: LogLevelDebug
# log_level = "7"

# min_free_space specifies the min free space percent in a thin pool require for
# new device creation to succeed. Valid values are from 0% - 99%.
# Value 0% disables
# min_free_space = "10%"

# mkfsarg specifies extra mkfs arguments to be used when creating the base
# device.
# mkfsarg = ""

# mountopt specifies extra mount options used when mounting the thin devices.
# mountopt = ""

# use_deferred_removal Marking device for deferred removal
# use_deferred_removal = "True"

# use_deferred_deletion Marking device for deferred deletion
# use_deferred_deletion = "True"

# xfs_nospace_max_retries specifies the maximum number of retries XFS should
# attempt to complete IO when ENOSPC (no space) error is returned by
# underlying storage device.
# xfs_nospace_max_retries = "0"

Running findmnt /var/lib/containers/ inside this container

/var/lib/containers /dev/sda2[/var/lib/kubelet/pods/f58f320f-999c-11e8-a436-1c1b0d0ece5a/volumes/kubernetes.io~empty-dir/varlibcontainers] xfs    rw,relatime,attr2,inode64,noquota

contents of /proc/filesystems

#> cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   ramfs
nodev   bdev
nodev   proc
nodev   cpuset
nodev   cgroup
nodev   cgroup2
nodev   tmpfs
nodev   devtmpfs
nodev   configfs
nodev   debugfs
nodev   tracefs
nodev   securityfs
nodev   sockfs
nodev   dax
nodev   bpf
nodev   pipefs
nodev   hugetlbfs
nodev   devpts
        ext3
        ext2
        ext4
nodev   autofs
nodev   pstore
nodev   efivarfs
nodev   mqueue
nodev   resctrl
        xfs
        btrfs
        vfat
nodev   rpc_pipefs
nodev   overlay
        fuseblk
nodev   fuse
nodev   fusectl
nodev   binfmt_misc

[vbatts]

cc @AkihiroSuda if you have thoughts here

[rhatdan]

vbatts how old is the Centos box you are doing this on? I think there were some issues with older versions of xfs on overlay.

@rhvgoyal @nalind PTAL.

[vbatts]

Again, it's on a f28 host, inside the latest centos image container

…

On Wed, Aug 15, 2018, 15:48 Daniel J Walsh ***@***.***> wrote: vbatts how old is the Centos box you are doing this on? I think there were some issues with older versions of xfs on overlay. @rhvgoyal <https://github.com/rhvgoyal> @nalind <https://github.com/nalind> PTAL. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#933 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEF6QxKBXGlkhdndOzWTRDNF5sLQ9j_ks5uRHsUgaJpZM4V-m6_> .

[bogdando]

I have the same error message when doing podman ps from a container
(UPDATE: please disregard, that was the versions conflict for podman installed on host vs in the container perhaps)

[dharmit]

I'm also trying to use buildah bud from inside a container on CentOS 7.5 and OKD 3.9. I have a Jenkinsfile with follow definition for podTemplate:

podTemplate(
    cloud: 'openshift',
    name: 'ccp-pipeline-master',
    label: 'ccp-pipeline-master',
    namespace: '${NAMESPACE}',
    serviceAccount: 'jenkins',
    containers: [
      containerTemplate(
        name: 'jnlp',
        image: '${CCP_OPENSHIFT_SLAVE_IMAGE}',
        ttyEnabled: true,
        alwaysPullImage: true,
        workingDir: '/tmp',
        privileged: true,
        args: '${computer.jnlpmac} ${computer.name}',
        resourceRequestCpu: '${MASTER_JOB_CPU}',
        resourceRequestMemory: '${MASTER_JOB_MEMORY}'
      )
    ],
    volumes: [
      hostPathVolume(
        hostPath: '/var/run/docker.sock',
        mountPath: '/var/run/docker.sock'
      )
    ]
)

And the build command being used it:

$buildah bud --no-cache -t ${image_name}_buildah -f ${TARGET_FILE} ${BUILD_CONTEXT}"

I face the error:

$ buildah bud --no-cache -t dharmit/beanstalkd:latest_buildah -f Dockerfile ./
time="2018-11-15T09:38:27Z" level=error msg="'overlay' is not supported over overlayfs"
time="2018-11-15T09:38:27Z" level=error msg="'overlay' is not supported over overlayfs"
'overlay' is not supported over overlayfs: backing file system is unsupported for this graph driver
'overlay' is not supported over overlayfs: backing file system is unsupported for this graph driver

buildah version on CentOS is:

$ buildah -v
buildah version 1.2 (image-spec 1.0.0, runtime-spec 1.0.0)

[rhatdan]

You need a much newer version of buildah and you need to run with buildah --isolation chroot, if you want to do this locked down.

In order to use overlay you will need to give the container more privileges.

@TomSweeneyRedHat we had talked about a blog explaining different ways to run buildah within a container. Did we ever publish this?

[TomSweeneyRedHat]

@ipbabble put together a blog about the buildah image that you can use, and I know he and I've talked about running Buildah in a container, but I'm not sure it's been done yet. Is this at all on your radar @ipbabble?

[rhatdan]

Use Fuse-overlay fixes this now.