kaniko: Copying rootfs fails
Dockerfile to reproduce:
FROM debian:buster-slim AS importer
RUN apt-get update && apt-get install -y libguestfs-tools wget xz-utils
RUN wget -nv https://raspi.debian.net/verified/20210718_raspi_4_buster.img.xz && xz -d 20210718_raspi_4_buster.img.xz && mkdir /rootfs && guestfish --ro -a 20210718_raspi_4_buster.img -m /dev/sda2 copy-out / /rootfs/ && rm 20210718_raspi_4_buster.img
FROM scratch
COPY --from=importer /rootfs/ /
For v1.6.0 this hangs at “Saving file rootfs for later use”. This is also described in #960 and the PR #1724 improves the situation. However, it now stops in the copy step reporting
error building image: error building stage: failed to execute command: copying dir: chown /sys: read-only file system
The workaround from #1007 seems to work though.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 1
- Comments: 15 (2 by maintainers)
Unfortunately it doesn’t work either.
I tried this example:
Hi @niekcandaele,
Thank you a lot for support. We are using keycloak operator to generate keycloak instance. I just updated keycloak docker image and it requires to update keycloak operator to 22.0.4 as well (I forgot to update this one) and it is using http-get to do health check (https://www.keycloak.org/server/health#_kubernetes), then no need install curl anymore and no need to deal with install stuff currently. Thanks!
Maybe try like this? It’s a bit verbose but should work around the symlink issue. I did notice that our Kaniko version is wildly outdated, might need to look into upgrading that 😅
gcr.io/kaniko-project/executor:debug-v0.22.0Depending on versions of stuff, you might need to copy over more or less of these .so files. I found the list for my instance like this
I am using version
gcr.io/kaniko-project/executor:v1.9.0-debugwhich is also not working.I am building the Dockerfile inside of a AWS EKS (Kubernetes) cluster on Fargate (AWS Serverless compute) pods. They are running without privileged mode.
Here’s my Dockerfile (with some unrelated things stripped out). Hope this helps
Heya, I made an oopsie when copying my suggestion, my bad! 🙈
Give the following a try:
Tested like this
I struggeled using your image in our Gitlab CI/CD pipeline. I digged a little deeper and it turns out that multiple achitectures are mixed up there. When pulling from x64 I obtain an arm64 image where for example /busybox/sh is indeed arm64 but the executor is x64: