seccomp: config provided but seccomp not supported #467

etnbrd · 2018-02-10T20:09:52Z

Description

When running a command in a container, the process exits with the error :

container_linux.go:348: starting container process caused "seccomp: config provided but seccomp not supported"

I am not exactly sure it is a bug from buildah itself.
I guess I have to somehow enable seccomp, but I don't know how, and it seems to be already enabled :

$ zgrep SECCOMP /proc/config.gz
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y

So it might be an issue completely unrelated to seccomp altogether, but I lack the general knowledge to understand what is wrong, or where to look for clues.

Steps to reproduce the issue:

$ sudo buildah from fedora
Getting image source signatures
Copying blob sha256:a8ee583972c2295bb76704d4defe5116d5e4dd7ba3767aaa2cc8fcf71088ee06
 82.80 MiB / 82.80 MiB [===================================================] 26s
Copying config sha256:422dc563ca3260ad9ef5c47a1c246f5065d7f177ce51f4dd208efd82967ff182
 2.29 KiB / 2.29 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
fedora-working-container
$ sudo buildah images
IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
422dc563ca32         docker.io/library/fedora:latest                          Nov 14, 2017 21:07     251 MB
$ sudo buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
5062084a1ad7     *     422dc563ca32 docker.io/library/fedora:latest  fedora-working-container
$ sudo buildah run fedora-working-container sh
container_linux.go:348: starting container process caused "seccomp: config provided but seccomp not supported"

Output of rpm -q buildah or apt list buildah:

I'm running Arch, and used yaourt to install buildah from git using this PKGBUILD.
It builds buildah from the source of this repo, and as I installed it just now (to be sure it isn't an issue already fixed), the version referes to the very last commit (46c1a54) as of now.

$ pacman -Q | grep buildah
buildah-git r478.46c1a54-1

Output of buildah version:

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

Output of cat /etc/*release:

LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
ID_LIKE=archlinux
ANSI_COLOR="0;36"
HOME_URL="https://www.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"

Output of uname -a:

Linux etndev 4.14.14-1-ARCH #1 SMP PREEMPT Fri Jan 19 18:42:04 UTC 2018 x86_64 GNU/Linux

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

cat: /etc/containers/storage.conf: No such file or directory

The text was updated successfully, but these errors were encountered:

rhatdan · 2018-02-11T11:31:59Z

The storage.conf should come from skopeo-containers, but not sure if this has been packaged for "Arch Linux" yet.

rhatdan · 2018-02-11T11:34:05Z

buildah should be able to work even if seccomp is not enabled. I believe this error is coming from runc, which buildah is executing to run the containers. What version of runc are you using?

etnbrd · 2018-02-11T11:44:19Z

Is skopeo-contaiers the same thing as skopeo ?

I installed runc the same way than buildah : from the git repository.

$ skopeo -v
skopeo version 0.1.27
$ yaourt -Q skopeo
local/skopeo 0.1.27-1
$ runc -v
runc version spec: 1.0.0
$ yaourt -Q runc-git
local/runc-git v1.0.0.rc4.r217.ga618ab5a-1

rhatdan · 2018-02-11T11:49:32Z

skopeo-containers is a subpackage of skopeo, at least that is what we ship in Fedora and I believe in our version for Ubuntu.
@lsm5 PTAL

Your version of runc looks recent enough.

On Fedora

 rpm -q skopeo-containers -l
/etc/containers
/etc/containers/policy.json
/etc/containers/registries.d
/etc/containers/registries.d/default.yaml
/etc/containers/storage.conf
/usr/share/containers
/usr/share/containers/mounts.conf
/usr/share/man/man5/containers-storage.conf.5.gz
/usr/share/rhel/secrets
/usr/share/rhel/secrets/etc-pki-entitlement
/usr/share/rhel/secrets/rhel7.repo
/usr/share/rhel/secrets/rhsm
/var/lib/atomic/sigstore

etnbrd · 2018-02-11T11:53:00Z

I don't know if it is of any help, but I tried to manually mount the working container, and create a container from it with runc, and it seems to work.

$ buildah containers
CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
5062084a1ad7     *     422dc563ca32 docker.io/library/fedora:latest  fedora-working-container
$ buildah mount fedora-working-container
/var/lib/containers/storage/devicemapper/mnt/4f12111492f235d8c2d326e2820c85aaec80dc4cc4a688c30caf75451ce6b7dc/rootfs
$ cd /var/lib/containers/storage/devicemapper/mnt/4f12111492f235d8c2d326e2820c85aaec80dc4cc4a688c30caf75451ce6b7dc
$ runc spec
$ runc run fedora-running-container
sh-4.4# id
uid=0(root) gid=0(root) groups=0(root)

etnbrd · 2018-02-11T11:57:23Z

Apparently, the arch package lacks two files:
(except for man, and secrets files, that I believe are distribution specific)

/etc/containers/storage.conf
/usr/share/containers/mounts.conf

$ yaourt -Ql skopeo
skopeo /etc/
skopeo /etc/containers/
skopeo /etc/containers/policy.json
skopeo /etc/containers/registries.d/
skopeo /etc/containers/registries.d/default.yaml
skopeo /usr/
skopeo /usr/bin/
skopeo /usr/bin/skopeo
skopeo /usr/share/
skopeo /usr/share/bash-completion/
skopeo /usr/share/bash-completion/completions/
skopeo /usr/share/bash-completion/completions/skopeo
skopeo /usr/share/man/
skopeo /usr/share/man/man1/
skopeo /usr/share/man/man1/skopeo.1.gz
skopeo /var/
skopeo /var/lib/
skopeo /var/lib/atomic/
skopeo /var/lib/atomic/sigstore/

rhatdan · 2018-02-11T11:59:36Z

/usr/share/containers/mounts.conf
Is also about putting secrets into the containers, so I guess that would be distro specific.

 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]
# 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"

rhatdan · 2018-02-11T12:01:14Z

These are all defaulted, but helpful to the admin to understand options available to them.

mheon · 2018-02-12T14:20:53Z

@etnbrd I believe your system has a version of runc that was built without Seccomp support. The kernel itself supports it, but your runc was built without libseccomp and as such lacks the interfaces to use the kernel seccomp calls. Can you build a version of runc from source with seccomp enabled and see if the problem is solved?

mheon · 2018-02-12T14:21:54Z

The fact that you can start the container from the spec seems to undermine this, but I'm pretty familiar with the runc seccomp code, and that error should only be present in versions of runc built without seccomp.

etnbrd · 2018-02-12T15:10:55Z

I will try to compile runc tonight, and keep you posted :)

rhatdan · 2018-02-12T15:29:39Z

Ok I will close this, reopen if it turns out to be an issue with buildah. @etnbrd If you make your alpine versions available in public we will update the docs to point at them.

rhatdan · 2018-02-12T15:54:08Z

When compiling runc, you have to use a BUILDTAG with "seccomp".

etnbrd · 2018-02-12T20:39:57Z

It turns out the problem seems to come from the PKGBUILD (the distro-specific file used to build runc and install it into my system).
I compiled it manually, and it seems to work as expected:

$ sudo buildah run fedora-working-container sh
sh-4.4#

I will now investigate the problem in the PKGBUILD, and report it to its maintainer.

Thanks a lot for your help :)

etnbrd · 2018-02-12T22:56:31Z

@rhatdan, I believe that you meant the Arch package, when you said 'your alpine version' :)
The official runc package for Arch is currently stuck at version 0.1.1, which is the last stable version.
Though, I fixed the unofficial version (AUR) and took maintainership of it.
For the documentation, this unofficial package is available here: https://aur.archlinux.org/packages/runc-git

rhatdan · 2018-02-13T11:02:41Z

Yes, I confused another Issue which was looking at Alpine and wrote the message here. Bottom line we are thrilled to see people attempting to use some of these tools on different Linux versions, then we manage. We would love to see buildah, CRI-O, Skopeo, Podman available on lots of Linux Variants and would love to link to where users of these distros could get packaged versions of our tools.

Signed-off-by: Matthew Heon <matthew.heon@gmail.com> Closes: #467 Approved by: baude

frezbo · 2018-08-06T14:27:34Z

I get the same error on F28 with the latest updates installed, runc came packaged with podman:

img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile  -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile --runtime $GOPATH/bin/runc -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$

Tried using compiled runc with/without seccomp. I see the same issue using img compiled with seccomp. Is there any package I'm missing

mheon · 2018-08-06T14:33:45Z

You potentially have a kernel without seccomp support. I don't know if there's an easy way to test this, though.

mheon · 2018-08-06T14:35:16Z

If it's a standard Fedora kernel, it definitely would have support, though

frezbo · 2018-08-06T14:36:10Z

@mheon this issue has dreaded me for a while, I have to mostly compile these tools from source without seccomp support, any help would be appreciated.

mheon · 2018-08-06T14:37:53Z

@frezbo Can you get a rpm -qa | grep kernel

rhatdan · 2018-08-06T14:41:03Z

This could be a runc without seccomp support.

rhatdan · 2018-08-06T14:42:48Z

If runc does not have seccomp support it will reject the seccomp file handed to it by buildah.

frezbo · 2018-08-06T14:45:22Z

@mheon

~ (aws:rean-gov-sd)(kc)$  rpm -qa | grep kernel
kernel-core-4.17.7-200.fc28.x86_64
abrt-addon-kerneloops-2.10.10-1.fc28.x86_64
kernel-core-4.17.9-200.fc28.x86_64
kernel-4.17.9-200.fc28.x86_64
libreport-plugin-kerneloops-2.9.5-1.fc28.x86_64
kernel-4.17.7-200.fc28.x86_64
kernel-devel-4.17.7-200.fc28.x86_64
kernel-modules-4.17.11-200.fc28.x86_64
kernel-modules-extra-4.17.11-200.fc28.x86_64
kernel-headers-4.17.11-1.fc28.x86_64
kernel-modules-4.17.7-200.fc28.x86_64
kernel-modules-4.17.9-200.fc28.x86_64
kernel-modules-extra-4.17.9-200.fc28.x86_64
kernel-core-4.17.11-200.fc28.x86_64
kernel-devel-4.17.9-200.fc28.x86_64
kernel-modules-extra-4.17.7-200.fc28.x86_64
kernel-devel-4.17.11-200.fc28.x86_64
kernel-4.17.11-200.fc28.x86_64
~ (aws:rean-gov-sd)(kc)$

Just pending a kernel update rebboot 😉

@rhatdan I tried compiling runc with and without seccomp and always see this. I even used the bundled runc from podman rpm

mheon · 2018-08-06T14:46:42Z

Those certainly look like official Fedora packages, and they are definitely built with seccomp

rhatdan · 2018-08-06T14:50:26Z

config provided but seccomp not supported is a runc error.

 grep -r "config provided but seccomp not supported" .
./libcontainer/seccomp/seccomp_unsupported.go:var ErrSeccompNotEnabled = errors.New("seccomp: config provided but seccomp not supported")

I think you are definitely using a runc without seccomp built in.

mheon · 2018-08-06T14:50:33Z

@frezbo That message is only in runc without Seccomp support - a runc with seccomp support shouldn't even contain the string

frezbo · 2018-08-07T10:33:38Z

@giuseppe #467 (comment) that would explain why plain runc works rootless

giuseppe · 2018-08-07T10:47:21Z

I am not able to reproduce it using buildah-1.3-1 and runc-1.0.0-46 from Bodhi. Have you used these versions?

frezbo · 2018-08-07T10:50:23Z

~ (aws:rean-gov-sd)(kc)$ rpm -qf /usr/bin/runc
runc-1.0.0-46.dev.gitb4e2ecb.fc28.x86_64
~ (aws:rean-gov-sd)(kc)$ rpm -qf $(which buildah)
buildah-1.2-1.gitbe87762.fc28.x86_64
~ (aws:rean-gov-sd)(kc)$

I am using the rpm's. I could compile from source and check as the buildah version differs significanlty

giuseppe · 2018-08-07T10:51:23Z

could you please try: https://bodhi.fedoraproject.org/updates/FEDORA-2018-a600343e06 and https://bodhi.fedoraproject.org/updates/FEDORA-2018-98c4c26a8c ?

frezbo · 2018-08-07T11:02:56Z

@giuseppe just build buildah from source:

img (aws:rean-gov-sd)(kc)$ $GOPATH/bin/buildah build-using-dockerfile  -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN ["echo", "hi"]
hi
STEP 3: COMMIT containers-storage:[vfs@/home/frezbo/.local/share/containers/storage+/run/user/1000/run]@bb9b3a832c4f692011ac98867146ab1cde2cc2b5b428f79b7a3d60affdf6562b
Getting image source signatures
Skipping fetch of repeat blob sha256:73046094a9b835e443af1a9d736fcfc11a994107500e474d0abf399499ed280c
Copying blob sha256:48eaf946e278225a2384fd53250d167868b5c7614c6d157766accfd9d17376a6
 132 B / 132 B [============================================================] 0s
Copying config sha256:cfb8ab732064d19ddb1a98ace0bd3d2760f0237ff6ca16b05e583b681b116cf4
 719 B / 719 B [============================================================] 0s
Writing manifest to image destination
Storing signatures
ERRO[0003] Error while applying layer: ApplyLayer exit status 1 stdout:  stderr: lchown /etc: invalid argument 
error copying layers and metadata: Error committing the finished image: error adding layer with blob "sha256:48eaf946e278225a2384fd53250d167868b5c7614c6d157766accfd9d17376a6": ApplyLayer exit status 1 stdout:  stderr: lchown /etc: invalid argument
ERRO[0003] exit status 1                                
img (aws:rean-gov-sd)(kc)$ 
buildah (aws:rean-gov-sd)(kc)(git:master)$ $GOPATH/bin/buildah --version
buildah version 1.4-dev (image-spec 1.0.0, runtime-spec 1.0.0)
buildah (aws:rean-gov-sd)(kc)(git:master)$

giuseppe · 2018-08-07T11:06:42Z

another thing to check, how many subuids/subgids are available to your user? They are defined in the /etc/subuid and /etc/subgid files?

frezbo · 2018-08-07T11:07:58Z

I hope this is not an issue:

img (aws:rean-gov-sd)(kc)$ cat /etc/subuid
frezbo:100000:65536
img (aws:rean-gov-sd)(kc)$ cat /etc/subgid
frezbo:100000:65536
img (aws:rean-gov-sd)(kc)$

giuseppe · 2018-08-07T11:19:42Z

the configuration looks fine, but the error message looks very similar to something that we fixed recently: #882

Could you confirm if the commit b956493 is included in your version of buildah?

giuseppe · 2018-08-07T11:20:32Z

or even better, what commit exactly are you using for the build? :-)

frezbo · 2018-08-07T12:15:05Z

@giuseppe I do have that commit:

buildah (aws:rean-gov-sd)(kc)(git:detached)$ gs
HEAD detached at b956493c
nothing to commit, working tree clean
buildah (aws:rean-gov-sd)(kc)(git:detached)$

and I'm at master on 308ad3d7fc63ee34ed213c2ffa6b345441600b8f

giuseppe · 2018-08-07T13:09:54Z

buildah has a nice feature to create an usernamespace and run a command in it.

Could you try buildah unshare cat /proc/self/uid_map?

frezbo · 2018-08-07T13:11:36Z

~ (aws:rean-gov-sd)(kc)$ buildah unshare cat /proc/self/uid_map
         0       1000          1
    100000     100000      65536
~ (aws:rean-gov-sd)(kc)$ $GOPATH/bin/buildah unshare cat /proc/self/uid_map
         0       1000          1
         1     100000      65536
~ (aws:rean-gov-sd)(kc)$

giuseppe · 2018-08-07T13:19:57Z

do you have a similar outputh with /proc/self/gid_map? The buildah in the GOPATH is correct, that is the correct map. I am afraid somehow the system installed buildah is used for the build of your container, thus the error you have seen earlier.

frezbo · 2018-08-07T13:22:28Z

~ (aws:rean-gov-sd)(kc)$ $GOPATH/bin/buildah unshare cat /proc/self/uid_map
         0       1000          1
         1     100000      65536
~ (aws:rean-gov-sd)(kc)$ buildah unshare cat /proc/self/uid_map
         0       1000          1
    100000     100000      65536
~ (aws:rean-gov-sd)(kc)$ $GOPATH/bin/buildah unshare cat /proc/self/gid_map
         0       1000          1
         1     100000      65536
~ (aws:rean-gov-sd)(kc)$ buildah unshare cat /proc/self/gid_map
         0       1000          1
    100000     100000      65536
~ (aws:rean-gov-sd)(kc)$

I could uninstall buildah and try, I prefer using compiled binaries in GOPATH

giuseppe · 2018-08-07T13:27:14Z

it might be something wrong in the re-exec code in buildah, could you just move the compiled buildah in /usr/local/bin to see if it makes any difference?

frezbo · 2018-08-07T13:34:23Z

same sadly ⭕

~ (aws:rean-gov-sd)(kc)$ which buildah
/usr/bin/buildah
~ (aws:rean-gov-sd)(kc)$ sudo mv /usr/bin/buildah /tmp/
[sudo] password for frezbo: 
~ (aws:rean-gov-sd)(kc)$ sudo cp $GOPATH/bin/buildah /usr/bin/buildah
~ (aws:rean-gov-sd)(kc)$ cd git/work/docker/img
img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile  -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
hi
STEP 3: COMMIT containers-storage:[vfs@/home/frezbo/.local/share/containers/storage+/run/user/1000/run]@029fae12bed890145991eb5527d485a0824b5b5cea9fe2361391d52ff8b41462
Getting image source signatures
Skipping fetch of repeat blob sha256:73046094a9b835e443af1a9d736fcfc11a994107500e474d0abf399499ed280c
Copying blob sha256:4e3b9e2843588404968be95f542fada9f09388b9098d8f21b120746da81e66b8
 132 B / 132 B [============================================================] 0s
Copying config sha256:49f996efff4db8f9b7d78979ad5e57a4551606439d7c72e5d732a7d0aa6a1dea
 721 B / 721 B [============================================================] 0s
Writing manifest to image destination
Storing signatures
ERRO[0002] Error while applying layer: ApplyLayer exit status 1 stdout:  stderr: lchown /etc: invalid argument 
error copying layers and metadata: Error committing the finished image: error adding layer with blob "sha256:4e3b9e2843588404968be95f542fada9f09388b9098d8f21b120746da81e66b8": ApplyLayer exit status 1 stdout:  stderr: lchown /etc: invalid argument
ERRO[0002] exit status 1                                
img (aws:rean-gov-sd)(kc)$

giuseppe · 2018-08-07T13:58:08Z

oh it can be that the storage got corrupted from the previous broken version. Could you try to nuke the storage before the build? sudo rm -rf /home/frezbo/.local/share/containers/storage

giuseppe · 2018-08-07T14:01:28Z

I've just spawned a new F28 droplet on Digital Ocean to try again on a clean system:

this is all I've done:

# dnf upgrade -y
# dnf install -y https://kojipkgs.fedoraproject.org//packages/buildah/1.3/1.git4888163.fc28/x86_64/buildah-1.3-1.git4888163.fc28.x86_64.rpm \
    https://kojipkgs.fedoraproject.org//packages/runc/1.0.0/46.dev.gitb4e2ecb.fc28/x86_64/runc-1.0.0-46.dev.gitb4e2ecb.fc28.x86_64.rpm
# adduser foo
#  mkdir /run/user/1000 && chown 1000:1000 /run/user/1000
# su -l foo
$ printf "FROM docker.io/library/alpine\nRUN echo hi\n" > Dockerfile
$ buildah bud .
STEP 1: FROM docker.io/library/alpine
Getting image source signatures
Copying blob sha256:8e3ba11ec2a2b39ab372c60c16b421536e50e5ce64a0bc81765c2e38381bcff6
 2.10 MiB / 2.10 MiB [======================================================] 0s
Copying config sha256:11cd0b38bc3ceb958ffb2f9bd70be3fb317ce7d255c8a4c3f4af30e298aa1aab
 1.48 KiB / 1.48 KiB [======================================================] 0s
Writing manifest to image destination
Storing signatures
STEP 2: RUN echo hi
STEP 3: COMMIT containers-storage:[vfs@/home/foo/.local/share/containers/storage+/run/user/1000/run]@685ddf5a1ca930e4564c5af28874dc901b0bb6f0b95a863e5a93c89d1904d858
Getting image source signatures
Skipping fetch of repeat blob sha256:73046094a9b835e443af1a9d736fcfc11a994107500e474d0abf399499ed280c
Copying blob sha256:55738ddf6159ab2ca873a05a6268d88acce61bb59dbcac34616d4b1b43fe8a71
 132 B / 132 B [============================================================] 0s
Copying config sha256:54a40d3470caa67c22057c9657f7a7e66c1ecdc5953319cb2fe9c2b647058f5b
 721 B / 721 B [============================================================] 0s
Writing manifest to image destination
Storing signatures
--> 685ddf5a1ca930e4564c5af28874dc901b0bb6f0b95a863e5a93c89d1904d858

frezbo · 2018-08-07T14:01:43Z

I thought I ha removed that, yeh it worked. Thanks. So I assume the next set of upcoming rpms fix it.

frezbo · 2018-08-07T14:02:18Z

@giuseppe Thanks for all the help. Even the compiled runc works.

giuseppe · 2018-08-07T14:03:52Z

great! @rhatdan I think we can close this issue

frezbo · 2018-08-07T14:04:10Z

ahh so builda does not cache stages, woudn't that slow the builds, I was thinking of benchmarking with img, buildctl, buildah etc

giuseppe · 2018-08-07T14:05:55Z

@frezbo buildah bud --layers ... to enable the cache

rhatdan · 2018-08-07T14:18:23Z

@frezbo Also if you want to default to buildah --layers. then set the environment variable.

export BUILDAH_LAYERS=true

And you will get it by default.

anjupawaria · 2020-11-23T18:48:30Z

I get the same error on F28 with the latest updates installed, runc came packaged with podman:

img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile  -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile --runtime $GOPATH/bin/runc -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$

Tried using compiled runc with/without seccomp. I see the same issue using img compiled with seccomp. Is there any package I'm missing

hey i am also facing the same error? did you find anything on this issue?

lsm5 · 2020-11-23T18:57:53Z

I get the same error on F28 with the latest updates installed, runc came packaged with podman:

img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile  -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$ buildah build-using-dockerfile --runtime $GOPATH/bin/runc -f Dockerfile.new .
STEP 1: FROM docker.io/library/alpine
STEP 2: RUN echo hi
container_linux.go:336: starting container process caused "seccomp: config provided but seccomp not supported"
error running container: error creating container for [/bin/sh -c echo hi]: : exit status 1
error building at step {Env:[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin] Command:run Args:[echo hi] Flags:[] Attrs:map[] Message:RUN echo hi Original:RUN echo hi}: exit status 1
ERRO[0001] exit status 1                                
img (aws:rean-gov-sd)(kc)$

Tried using compiled runc with/without seccomp. I see the same issue using img compiled with seccomp. Is there any package I'm missing

hey i am also facing the same error? did you find anything on this issue?

You quoted a comment about f28 which has been dead for a long time now. Perhaps better to file a new issue.

rhatdan closed this as completed Feb 12, 2018

nalind pushed a commit that referenced this issue Apr 2, 2018

Fix a potential race around container removal in ps

7516dfd

Signed-off-by: Matthew Heon <matthew.heon@gmail.com> Closes: #467 Approved by: baude

rhatdan reopened this Aug 6, 2018

rhatdan closed this as completed Sep 17, 2018

robco mentioned this issue Nov 20, 2020

OS5 packages WDCommunity/wdpksrc#57

Open

github-actions bot added the locked - please file new issue/PR label Sep 8, 2023

github-actions bot locked as resolved and limited conversation to collaborators Sep 8, 2023

seccomp: config provided but seccomp not supported #467

seccomp: config provided but seccomp not supported #467

Comments

etnbrd commented Feb 10, 2018

rhatdan commented Feb 11, 2018

rhatdan commented Feb 11, 2018

etnbrd commented Feb 11, 2018

rhatdan commented Feb 11, 2018

etnbrd commented Feb 11, 2018

etnbrd commented Feb 11, 2018

rhatdan commented Feb 11, 2018 • edited Loading

rhatdan commented Feb 11, 2018

mheon commented Feb 12, 2018

mheon commented Feb 12, 2018

etnbrd commented Feb 12, 2018 • edited Loading

rhatdan commented Feb 12, 2018

rhatdan commented Feb 12, 2018

etnbrd commented Feb 12, 2018

etnbrd commented Feb 12, 2018 • edited Loading

rhatdan commented Feb 13, 2018

frezbo commented Aug 6, 2018

mheon commented Aug 6, 2018

mheon commented Aug 6, 2018

frezbo commented Aug 6, 2018

mheon commented Aug 6, 2018

rhatdan commented Aug 6, 2018

rhatdan commented Aug 6, 2018

frezbo commented Aug 6, 2018 • edited Loading

mheon commented Aug 6, 2018

rhatdan commented Aug 6, 2018

mheon commented Aug 6, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018 • edited Loading

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018 • edited Loading

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018 • edited Loading

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

frezbo commented Aug 7, 2018

giuseppe commented Aug 7, 2018

rhatdan commented Aug 7, 2018

anjupawaria commented Nov 23, 2020

lsm5 commented Nov 23, 2020 • edited Loading

rhatdan commented Feb 11, 2018 •

edited

Loading

etnbrd commented Feb 12, 2018 •

edited

Loading

etnbrd commented Feb 12, 2018 •

edited

Loading

frezbo commented Aug 6, 2018 •

edited

Loading

frezbo commented Aug 7, 2018 •

edited

Loading

giuseppe commented Aug 7, 2018 •

edited

Loading

frezbo commented Aug 7, 2018 •

edited

Loading

lsm5 commented Nov 23, 2020 •

edited

Loading