{"action":"created","issue":{"url":"https://api.github.com/repos/moby/moby/issues/37340","repository_url":"https://api.github.com/repos/moby/moby","labels_url":"https://api.github.com/repos/moby/moby/issues/37340/labels{/name}","comments_url":"https://api.github.com/repos/moby/moby/issues/37340/comments","events_url":"https://api.github.com/repos/moby/moby/issues/37340/events","html_url":"https://github.com/moby/moby/issues/37340","id":335337403,"node_id":"MDU6SXNzdWUzMzUzMzc0MDM=","number":37340,"title":"Problem with \"deep\" multistage builds: `layer does not exist` error","user":{"login":"jcberthon","id":1397088,"node_id":"MDQ6VXNlcjEzOTcwODg=","avatar_url":"https://avatars2.githubusercontent.com/u/1397088?v=4","gravatar_id":"","url":"https://api.github.com/users/jcberthon","html_url":"https://github.com/jcberthon","followers_url":"https://api.github.com/users/jcberthon/followers","following_url":"https://api.github.com/users/jcberthon/following{/other_user}","gists_url":"https://api.github.com/users/jcberthon/gists{/gist_id}","starred_url":"https://api.github.com/users/jcberthon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jcberthon/subscriptions","organizations_url":"https://api.github.com/users/jcberthon/orgs","repos_url":"https://api.github.com/users/jcberthon/repos","events_url":"https://api.github.com/users/jcberthon/events{/privacy}","received_events_url":"https://api.github.com/users/jcberthon/received_events","type":"User","site_admin":false},"labels":[{"id":73616520,"node_id":"MDU6TGFiZWw3MzYxNjUyMA==","url":"https://api.github.com/repos/moby/moby/labels/area/builder","name":"area/builder","color":"fbca04","default":false},{"id":87450956,"node_id":"MDU6TGFiZWw4NzQ1MDk1Ng==","url":"https://api.github.com/repos/moby/moby/labels/area/storage/btrfs","name":"area/storage/btrfs","color":"fbca04","default":false},{"id":190258329,"node_id":"MDU6TGFiZWwxOTAyNTgzMjk=","url":"https://api.github.com/repos/moby/moby/labels/kind/bug","name":"kind/bug","color":"FF8C94","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-06-25T09:56:02Z","updated_at":"2018-09-17T07:47:23Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"**Description**\r\n\r\nWe are having a problem with the multistage builds where on first run we have the `layer does not exist` error, but if we run the build again it works. So on a clean system (with no cache) it fails, but not on a dirty system with cache.\r\n\r\nI have first reported this problem in issue #33974 (see comment https://github.com/moby/moby/issues/33974#issuecomment-399445187). But it looks to be distinct, so I took the advice of @thaJeztah and created a new issue.\r\n\r\n**Steps to reproduce the issue:**\r\nI have setup a GitHub repo with all the code to reproduce the problem: https://github.com/jcberthon/multistage-fails\r\n\r\nIn the readme, there are the instructions (step-by-step to reproduce the bug). You can find also all Dockerfiles. The Dockerfile for which the multistage build fails is under the `level3` directory.\r\n\r\nOf course you can build every images locally (it fails at level3), or you can directly try to build level3 as I have pushed to Docker Hub the intermediate images.\r\n\r\n**Describe the results you received:**\r\n\r\nThe first time one runs the above example project, he gets the following result:\r\nWhen building `level3` it fails with the error `layer does not exist` (see the GitHub project above for more details).\r\n\r\n**Describe the results you expected:**\r\n\r\nWhen running it a second time, it works as I expect it. Albeit, it should run like that on the first try already.\r\n\r\n**Additional information you deem important (e.g. issue happens only occasionally):**\r\n\r\nThe bug is triggered always on a clean system, never when running a 2nd time. So `docker system prune -a` helps to trigger the bug again.\r\n\r\n**Output of `docker version`:**\r\n\r\n```\r\nClient:\r\n Version:      18.05.0-ce\r\n API version:  1.37\r\n Go version:   go1.9.5\r\n Git commit:   f150324\r\n Built:        Wed May  9 22:16:04 2018\r\n OS/Arch:      linux/amd64\r\n Experimental: false\r\n Orchestrator: swarm\r\n\r\nServer:\r\n Engine:\r\n  Version:      18.05.0-ce\r\n  API version:  1.37 (minimum version 1.12)\r\n  Go version:   go1.9.5\r\n  Git commit:   f150324\r\n  Built:        Wed May  9 22:19:55 2018\r\n  OS/Arch:      linux/amd64\r\n  Experimental: false\r\n```\r\n\r\n**Output of `docker info`:**\r\n\r\n```\r\nContainers: 0\r\n Running: 0\r\n Paused: 0\r\n Stopped: 0\r\nImages: 0\r\nServer Version: 18.05.0-ce\r\nStorage Driver: btrfs\r\n Build Version: Btrfs v4.15.1\r\n Library Version: 102\r\nLogging Driver: json-file\r\nCgroup Driver: cgroupfs\r\nPlugins:\r\n Volume: local\r\n Network: bridge host macvlan null overlay\r\n Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog\r\nSwarm: inactive\r\nRuntimes: runc\r\nDefault Runtime: runc\r\nInit Binary: docker-init\r\ncontainerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88\r\nrunc version: 4fc53a81fb7c994640722ac585fa9ca548971871\r\ninit version: 949e6fa\r\nSecurity Options:\r\n seccomp\r\n  Profile: default\r\nKernel Version: 4.16.13-300.fc28.x86_64\r\nOperating System: Fedora 28 (Workstation Edition)\r\nOSType: linux\r\nArchitecture: x86_64\r\nCPUs: 2\r\nTotal Memory: 3.852GiB\r\nName: spcbo-jcb-fedora.vcs.de\r\nID: 7ENM:NU5S:7XAB:K2MJ:CVKB:6BUO:HIMM:NW3M:QZ35:KNL6:VCOT:KBRM\r\nDocker Root Dir: /var/lib/docker\r\nDebug Mode (client): false\r\nDebug Mode (server): false\r\nRegistry: https://index.docker.io/v1/\r\nLabels:\r\nExperimental: false\r\nInsecure Registries:\r\n 127.0.0.0/8\r\nLive Restore Enabled: false\r\n```\r\n\r\n**Additional environment details (AWS, VirtualBox, physical, etc.):**\r\n\r\nI have tested this behaviour on 3 different platforms:\r\n* VM VBox: Fedora 28 (Kernel 4.16.13-300.fc28.x86_64) with Docker CE 18.05.0-ce - btrfs\r\n* Bare metal: CentOS 7.5 (Kernel 3.10.0-862.3.2.el7.x86_64) with Docker CE 18.03.1-ce - devicemapper\r\n* Bare metal: Ubuntu 16.04.4 (Kernel 4.13.0-45-generic) with Docker CE 18.03.1-ce - btrfs\r\n"},"comment":{"url":"https://api.github.com/repos/moby/moby/issues/comments/421917657","html_url":"https://github.com/moby/moby/issues/37340#issuecomment-421917657","issue_url":"https://api.github.com/repos/moby/moby/issues/37340","id":421917657,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMTkxNzY1Nw==","user":{"login":"jcberthon","id":1397088,"node_id":"MDQ6VXNlcjEzOTcwODg=","avatar_url":"https://avatars2.githubusercontent.com/u/1397088?v=4","gravatar_id":"","url":"https://api.github.com/users/jcberthon","html_url":"https://github.com/jcberthon","followers_url":"https://api.github.com/users/jcberthon/followers","following_url":"https://api.github.com/users/jcberthon/following{/other_user}","gists_url":"https://api.github.com/users/jcberthon/gists{/gist_id}","starred_url":"https://api.github.com/users/jcberthon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jcberthon/subscriptions","organizations_url":"https://api.github.com/users/jcberthon/orgs","repos_url":"https://api.github.com/users/jcberthon/repos","events_url":"https://api.github.com/users/jcberthon/events{/privacy}","received_events_url":"https://api.github.com/users/jcberthon/received_events","type":"User","site_admin":false},"created_at":"2018-09-17T07:47:23Z","updated_at":"2018-09-17T07:47:23Z","author_association":"CONTRIBUTOR","body":"At work, we are using devicemapper-only.\r\n\r\nAt home I decided several years ago to play with fire and I've setup a mini-server with Ubuntu 12.04 (now 18.04) and btrfs for file system. I'm using it for backup and storing photos (note it is not my only backup, hence I can dare playing with fire). Why btrfs? Well it is slower, and 6 years ago there was a lot of file system full when it was only requiring some balancing, so I must have been masochistic somewhat... But since then it is still sluggish (my IO wait and queues are quite high for such a small low activity home server!!) but it has become reliable. One advantage on using btrfs (and one of the reasons I chose it in the first place) is data checksum. On my NAS - which is using ext4 - it has happen that some photos got corrupted (bit rot) and it is time consuming to find an older version which is not affected. On my mini home server, if it did happen (and I had 2 bad very old HDDs with bad sectors which I've replace since then) I never saw it in my data.\r\n\r\n6 years ago I've considered between FreeBSD+ZFS or Ubuntu+BTRFS. The latter won for 2 reasons: my platform was AMD and bhyve was not working on it back then, so I needed KVM; and I'm much more familiar with Linux than BSD so it would have been easier to setup. So I went with Ubuntu+BTRFS+KVM (using LVM for the KVM guests, not btrfs+qcow). But my underpower mini-server was quickly not able to run all services within VMs and that's why I started using containers instead, first LXD and then Docker. And when I started with Docker, I was not thinking of what should be my backend storage but rather how do I launch a hello world ;-)\r\n\r\nIn the end, I'm using btrfs for historical reason and it is the first time I see a bug on this backend with Docker. However, note that I'm not using this deep level multi-stage build at home, I only used that platform to see if the behaviour was reproducible there."}}
{"actor":{"display_login":"jcberthon"}}