kaniko: Kaniko builds sometimes produces broken image (doesn't happen on first build, only building w/ cache?)

I’m using kaniko 0.17.1 on my gitlab runner (Docker 19.03.5).

This is my dockerfile:

FROM docker.io/alpine:3.10
RUN apk add --no-cache openjdk9-jre-headless

This is the command to build the image:

/kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE:ci --build-arg=SSH_PRIVATE_KEY="${SSH_PRIVATE_KEY_GIT}"

The image build succeeds, but when I pull the image from my registry, I get the following error (tested on multiple machines and operating systems):

docker pull gitlab.mydomain.net:5050/myname/toolbox:ci
ci: Pulling from myname/toolbox
4167d3e14976: Already exists
ae6394e466fb: Extracting [==================================================>]  71.28MB/71.28MB
failed to register layer: Error processing tar file(exit status 1): mkdir /usr/lib/jvm/default-jvm/bin: no such file or directory

When building the image with kaniko 0.16.0, the image works as expected.

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 13
  • Comments: 19 (4 by maintainers)

Most upvoted comments

I still got

failed to register layer: Error processing tar file(exit status 1): failed to mknod(“/usr/local/lib/node_modules/npm/appveyor.yml”, S_IFCHR, 0): file exists

with using debug-v0.18.0

Also seeing this on 0.19.0 and 0.20.0 with --cache=true:

failed to register layer: Error processing tar file(exit status 1): failed to mknod("/lib/x86_64-linux-gnu/libgpg-error.so.0.21.0", S_IFCHR, 0): file exists

It works with --cache=false.

Still having this issue on multi tenanted cluster running a mix of 0.17.1 and 0.19.0

@cvgw was using :debug image ( till yesterday) to build images from gitlab shared runner and push to AWS ECR. This week errors started to appear while pulling:

failed to register layer: Error processing tar file(exit status 1): no such file or directory

Referring to this issue and using debug-a1af057f997316bfb1c4d2d82719d78481a02a79 solved it. So I’m afraid i the issue is still there on “latest”