Still running into issue … by simple "docker build -t "
Docker recently changed the default docker build behavior to --rm=true
by default, so you just need to switch your docker build command to docker build --rm=false
Hi everyone, I think an issue I have with Docker builds may also be related:
However - I am not docker run
ing anything, so the workaround doesn’t work for me, my issues are on the docker build
itself.
I just need some clarity on this issue. I too see these errors in the logs:
Error removing intermediate container d9506c265c8d: rmdriverfs: Driver btrfs failed to remove root filesystem d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540: Failed to destroy btrfs snapshot /var/lib/docker/btrfs/subvolumes for d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540: operation not permitted
Error removing intermediate container d9506c265c8d: nosuchcontainer: no such id: d9506c265c8d342f23e3150a1a0c4e363186f504a1d9d22dcf83486037692540
I’m executing the docker build by way of a Maven Plugin. It completes the Docker Image build successfully despite the errors.
What I need to know is does this error in any way affect the Docker Image Build? Will the contents of the image be any different if I built it on my local machine? I need to have confidence that what I build locally is exactly the same as what CircleCI will build.
Thanks!
Please see https://circleci.com/docs/docker-btrfs-error/ for the details on why you see this error. It does not affect your Docker build in any way.
I think the confusion here is that somehow on CircleCI --rm
is getting set anyways (even if the user hasn’t set it). This makes things unintuitive hence this long discussion about why this error is happening and what it means. Admittedly yes users could override this behavior by disabling --rm
explicitly, I guess the question is why should one need to do this at all? Shouldn’t the default configuration of docker
on CircleCI be one such that --rm
is not supplied by default? It might save further discussion on this point. Just something to think about.
This is not a possibility since your builds run in a shared environment in an unprivileged LXC container.
The best solution going forward for people who need full docker functionality is to run inside of a VM on 2.0
The tradeoff here is that the VM takes a bit longer to spin up.