Deleting <none> images won't work

[DeusProx]

Hi! I'm using docker in a Virtualbox VM with limited space. Due to that I run all builds with --no-cache=true and --force-rm=true, but still there will be a lot of "none" images. Due to that I need to delete all images from time to time with following command:
$sudo docker rmi -f $(sudo docker images -a | grep <none> | awk '{print $3}')

with following STDOUT:
Error response from daemon: Conflict, d31f88fd9974 wasn't deleted
Error response from daemon: Conflict, ed5604f1b0d8 wasn't deleted
Error response from daemon: Conflict, 110bc4cd7e4c wasn't deleted
Error response from daemon: Conflict, a1360bb6c3b0 wasn't deleted
Error response from daemon: Conflict, 92afa040558b wasn't deleted
Error response from daemon: Conflict, 39dda916ec63 wasn't deleted
Error response from daemon: Conflict, 4ea8bd9bec57 wasn't deleted
Error response from daemon: Conflict, 1522b0d467aa wasn't deleted
Error response from daemon: Conflict, e6e765e2dfa2 wasn't deleted
Error response from daemon: Conflict, f160b0d444f4 wasn't deleted
Error response from daemon: Conflict, 830e795837db wasn't deleted
Error response from daemon: Conflict, 5e7ecd63123f wasn't deleted
Error response from daemon: Conflict, c06fc73425a2 wasn't deleted
Error response from daemon: Conflict, 4903eaff0680 wasn't deleted
Error response from daemon: Conflict, 97f9076e2840 wasn't deleted
Error response from daemon: Conflict, 5b48e0d6f6e7 wasn't deleted
Error response from daemon: Conflict, 904b2088caaf wasn't deleted
Error response from daemon: Conflict, 0555adefb753 wasn't deleted
Error response from daemon: Conflict, b7737639c6db wasn't deleted
Error response from daemon: Conflict, 0e6787c7c755 wasn't deleted
Error response from daemon: Conflict, 5427f16b1bd4 wasn't deleted
Error response from daemon: Conflict, 5dfcd2731dcc wasn't deleted
Error response from daemon: Conflict, 00cf824c2575 wasn't deleted
Error response from daemon: Conflict, ace5f1353316 wasn't deleted
Error response from daemon: Conflict, e466276f4e40 wasn't deleted
Error response from daemon: Conflict, a8375cdfd1c5 wasn't deleted
Error response from daemon: Conflict, bd34e272b0c6 wasn't deleted
Error response from daemon: Conflict, d24dcb780442 wasn't deleted
Error response from daemon: Conflict, 7a806cfe2e9a wasn't deleted
Error response from daemon: Conflict, 065e41fab6d1 wasn't deleted
Error response from daemon: Conflict, 0c7827cd370a wasn't deleted
Error response from daemon: Conflict, fe26a3fb74a3 wasn't deleted
Error response from daemon: Conflict, 848657207f27 wasn't deleted
Error response from daemon: Conflict, 009b53b58e57 wasn't deleted
Error response from daemon: Conflict, 63466593fa03 wasn't deleted
Error response from daemon: Conflict, f60878bee201 wasn't deleted
Error response from daemon: Conflict, 117ee323aaa9 wasn't deleted
Error response from daemon: Conflict, 1c8294cc5160 wasn't deleted
Error response from daemon: Conflict, fa4fd76b09ce wasn't deleted
Error response from daemon: Conflict, ea13149945cb wasn't deleted
Error response from daemon: Conflict, df7546f9f060 wasn't deleted
Error response from daemon: Conflict, 511136ea3c5a wasn't deleted
FATA[0000] Error: failed to remove one or more images

There is no container running as "sudo docker ps -a" gives an empty output. In "sudo docker images -a" are only "none" images and my builded images which I need to proceed my work. I'm using Xubuntu 14.04 and newest docker:
$sudo docker --version
Docker version 1.5.0, build a8a31ef

[phemmer]

Not a solution, just a comment, but if you're limited on space, the --no-cache=true is the opposite of what you want, as this will cause docker to use more disk space.

[jessfraz]

instead of sudo docker rmi -f $(sudo docker images -a | grep | awk '{print $3}')

your want sudo docker rmi -f $(sudo docker images -a | grep \<none\> | awk '{print $1}') for the container id ;)

[DeusProx]

You mixed up containers and images I think. With containers it would be right to use awk '{print $1}' to get container IDs but I want to delete images which ist row 3.
I just want no intermediary images getting saved on my disk as "--force-rm=true" should do. still their is a big list of images:

$sudo docker images -a | grep
6e2564c6035c 3 hours ago 292.3 MB
....
511136ea3c5a 20 months ago 0 B

I also really don't understand why the last image is 0B big and was created 20 months ago as I'm using docker since a few weeks.

[jessfraz]

so the created date is when the original image was created, so if it is based on an official image or something, that layer was probably created then pushed up to the hub

also yes sorry I mixed up the containers output, seeing as you are gettting conflict errors back you must be either running these images w containers or the images the container is running relies on these images

[jessfraz]

also check out docker rmi $(docker images -q --filter dangling=true) that deletes any images that are "dangling" (are not being used by any parent image)

[DeusProx]

1:
$sudo docker rmi $(sudo docker images -q --filter dangling=true)
deleted 12 images but not all intermediary images.

2:
Before I looked into this I deleted all containers with the following commands under root privileges:
$docker stop $(docker ps -a -q)
$docker rm $(docker ps -a -q)

I also deleted all my images today and builded new ones and got new intermediary images. It seems to me that I either don't understand the basics behind those inermediary images and that they are pure virtualy or --force-rm=true isn't working like it's supposed.

[jessfraz]

are you using the build command with docker build --rm --force-rm

[phemmer]

inermediary images and that they are pure virtualy or --force-rm=true isn't working like it's supposed

See the --help output:

--force-rm=false     Always remove intermediate containers, even after unsuccessful builds

Note that it removes intermediate containers, not intermediate images.

[DeusProx]

Ah thanks so I mixed up too? and no-cache will in fact create bigger images too?

[DeusProx]

@jfrazelle tried with both switches and just with --force-rm=true and saw no change.

[thanizebra]

any solution ?

[robdodson]

@Chocoloper do you have any tagged images laying around still? Running docker images -tree I found that the untagged images were actually layers used to build up my tagged images.

ex:

├─e9e06b06e14c Virtual Size: 188.1 MB
│ └─a82efea989f9 Virtual Size: 188.3 MB
│   └─37bea4ee0c81 Virtual Size: 188.3 MB
│     └─07f8e8c5e660 Virtual Size: 188.3 MB Tags: ubuntu:14.04

If I take that first id, e9e06b06e14c, and run docker images -a, it shows up in the list of untagged images.

REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
<none>              <none>              37bea4ee0c81        2 weeks ago         188.3 MB
ubuntu              14.04               07f8e8c5e660        2 weeks ago         188.3 MB
<none>              <none>              a82efea989f9        2 weeks ago         188.3 MB
<none>              <none>              e9e06b06e14c        2 weeks ago         188.1 MB

Some tagged images have quite a few layers. training/postgres has 11 I think. So if you have a few tagged images laying around it can produce a pretty long list.

[Eli-Goldberg]

You could also just use:
docker images --all | grep | awk '{print $3}'