search

chainguard-dev / apko

Build OCI images from APK packages directly without Dockerfile
https://apko.dev
Apache License 2.0
1.19k stars 119 forks source link

Buildah cannot use apko generated image as base #344

Open vdemeester opened 2 years ago

vdemeester commented 2 years ago

This is related to the following issue : https://github.com/containers/buildah/issues/4213.

Running buildah bud --storage-driver=vfs with the following Dockerfile, as root (just not privileged) will not work.

FROM ghcr.io/distroless/alpine-base:latest

But using other images like docker.io/library/alpine do work. Note also that it works just fine using docker build 🙃.

I am really not sure if it's a buildah issue or an apko issue, hence creating an issue in both repository to figure that out.

STEP 1/1: FROM ghcr.io/distroless/alpine-base:latest
Trying to pull ghcr.io/distroless/alpine-base:latest...
Getting image source signatures
Copying blob afb725cdfbe4 done  
Copying blob afb725cdfbe4 done  
error creating build container: copying system image from manifest list: writing blob: adding layer with blob "sha256:afb725cdfbe4a41f1de8dbb3ac124dee12eaabec5398eecd92ee585cd946f018": ApplyLayer stdout:  stderr: operation not permitted exit status 1
kaniini commented 2 years ago

I am not able to reproduce this with Buildah 1.27 in Alpine, but this is pretty strange. Have you tried strace yet?

vdemeester commented 2 years ago

I am not able to reproduce this with Buildah 1.27 in Alpine, but this is pretty strange. Have you tried strace yet?

Not really. I also didn't try with buildah 1.27 on alpine, just the latest publish "officilal" buildah image quay.io/buildah/stable 😅.

kaniini commented 2 years ago

The fact that it is failing with stdio file access resulting in EPERM indicates to me that it is likely some sort of internal detail inside buildah, most likely tracing with strace would help figure out what syscall is returning EPERM.