-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chown: Value too large for defined data type #656
Comments
|
The kaniko debug image is defined by https://github.com/GoogleContainerTools/kaniko/blob/master/deploy/Dockerfile_debug This Dockerfile is multi stage, preps busybox in one of the prior steps and copies it over to the final kaniko debug image. This intermediate step is dependent on the distroless repository where it sets up busybox via a bazel build. According to https://bugs.busybox.net/show_bug.cgi?id=11651#c2 this should not matter though since for the file sizes following is described: Yet many point out that switchting to amd64 glibc-based busybox from 32-bit uclibc fixes their issue. |
So is switching to amd64 glibc variant an option? |
I started using kaniko as well some time ago and directly ran into this issue. I'm trying to build on Kubernetes using the kaniko debug image, if this matters. Is a fix for this in sight? If not, I will have to build a kaniko image on my own using glibc, but I would prefer to use the official images ;-) Any feedback is appreciated. |
I'm having the same issue |
Meanwhile I've build an Alpine Linux image with kaniko that works quite well. Maybe this might help you, too. https://gitlab.com/griffinplus/gitlab-kaniko EDIT: If you use |
i have the same issue :( have to build my own kaniko build... UPDATE: |
FYI I keep having a "Value too large for defined data type" when I even do an Tested both with distroless (related to GoogleContainerTools/distroless#225) and kaniko-debug, just to confirm - see below.
and btw, @ravenpride alpine based image worked like a charm, thank for putting that together! |
Currently using kaniko is a bit unfortunately, because it still failes most builds (for us) on k8s clusters. The reason as above written is a broken busybox/uclibc coming from distroless (which is i686 and breaks on hitting 64bit inodes) The fix for us was to just add an additional layer over
Would be nice if this problem could finally be fixed after so many months. |
@gebi Sorry about the lack of support. We are a small team and trying to re-vamp our support level. Looks like this was fixed on distroless GoogleContainerTools/distroless#437 in Nov 2019. We did a release in Dec and this should be fixed now. Tejal |
I'm encountering the same issue having tried the v0.15.0 image indicated above, when on a mac.
However it works correctly when running as a container inside my kubernetes cluster. |
Ran into this issue trying to build images with kaniko in a GitLab managed EKS Kubernetes cluster. https://gitlab.com/griffinplus/gitlab-kaniko did not work, since it does not seem to have the amazon-ecr-credential-helper embedded and I do need to push to AWS ECR. The quick and easy workaround from @gebi did the trick. Thanks @gebi! I've implemented it here https://github.com/lmakarov/kaniko and using
|
Does anyone have a somewhat similar issue in GKE cluster where the build goes through but the image build misses chown-ing a folder ? Im referring to #1079 |
@jeunii i will try to reproduce your issue on GKE. |
I'm running into the same issue (running ls) on a Rancher/RKE kubernetes cluster running docker 19.3.5. The builds otherwise run fine. The issue doesn't exist on a development Ubuntu 18.04 VM running docker 19.03.7. I tried it on the debug and debug-v0.18.0 tagged images. |
I've run into this as well with local Docker, but have not been able to reproduce it since. I concur with the others in that the root cause is likely due to commands making not being able to handle system calls with 64-bit values. |
My attempts to reproduce the issue have so far failed, but I definitely ran into this with my first time using Kaniko and Docker. Tried creating a 167GB file:
But |
Just to add another data point I run into the issue on a shell session in
Pod is created by the following spec: apiVersion: v1
kind: Pod
metadata:
name: kaniko-test
spec:
containers:
- name: builder
image: gcr.io/kaniko-project/executor:debug-v0.19.0
command: ["sh", "-c", "trap : TERM INT; (while true; do sleep 1000; done) & wait"]
restartPolicy: Never |
erm .. encountered the same issue workaround from @gebi and (GoogleContainerTools/distroless#225 (comment)) has worked perfectly fine |
Kaniko build fails (randomly) with
Value too large for defined data type
Dockerfile snippet:
Build error :
Kaniko : gcr.io/kaniko-project/executor:debug
Build Env: Jenkins - Kubernetes
The text was updated successfully, but these errors were encountered: