Failed to solve rpc error code unknown desc failed to solve with frontend dockerfile v0

I am locking the conversation on this ticket, because it’s collecting many comments that are unrelated to the original issue, but let me describe some steps that may help users arriving here.

Reading the errors produced during build

The error messages returned by current versions of Docker when using BuildKit can be rather verbose, and many will start with the same prefix (failed to solve.. ). The errors that are printed are a colon (:) separated chain of errors from BuildKit’s subsystems that are involved in processing the build. The exact errors may differ slightly between versions of Docker, and depending on what «subsystem» the error occurs in, but generally follow the same pattern.

If you get such an error, be sure to read the whole error message; the underlying error is usually at the end. Some examples from the discussion above;

Example 1

failed to solve with frontend dockerfile.v0: failed to build LLB: failed to load cache key: rpc error: code = Unknown desc = error getting credentials - err: exec: "docker-credential-desktop.exe": executable file not found in $PATH, out: ``

The above error can be split to:

(1) failed to solve with frontend dockerfile.v0:
(2) failed to build LLB: failed to load cache key:
(3) rpc error: code = Unknown desc = error getting credentials - err:
(4) exec: "docker-credential-desktop.exe": executable file not found in $PATH, out: ``

Where (4) is the underlying error that caused the problem (in this case the client is configured to use the docker-credential-desktop.exe credentials-helper, which is not accessible from the WSL2 environment (#415 (comment)). (1) .. (3) are the BuildKit components that are affected by the underlying problem (the gRPC API, the code constructing the BuildKit «LLB» graph, and the Dockerfile frontend / parser.

Example 2

failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to build LLB: Error processing tar file(exit status 1): unexpected EOF

(1) failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0:
(2) failed to build LLB:
(3) Error processing tar file(exit status 1): unexpected EOF

Here, the underlying error is (3), and happened when handling a tar file (without further context / details it’s hard to tell what the cause ise, but could be (for example) when using ADD to add a remove tar-archive, and there was a networking issue, the server had an issue, or the file that’s added is not in the right format).

Example 3

failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /var/lib/docker/tmp/buildkit-mount840562661/dockerfile: no such file or directory

(1) failed to solve with frontend dockerfile.v0:
(2) failed to read dockerfile:
(3) open /var/lib/docker/tmp/buildkit-mount840562661/dockerfile:
(4) no such file or directory

Here, (2)...(4) describe that docker / BuildKit was unable to load the Dockerfile. This looks like the issue that was originally reported, and was related to situations where the Dockerfile was named dockerfile (lowercase); fixes for this were merged (#415 (comment)).

Example 4

failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = failed to build LLB: failed to compute cache key: "/Build/release/authenticator/conf/nginx.conf" not found: not found

(1) failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0:
(2) failed to solve with frontend gateway.v0:
(3) rpc error: code = Unknown desc = failed to build LLB:
(4) failed to compute cache key: "/Build/release/authenticator/conf/nginx.conf" not found:
(5) not found

The not found is a bit duplicate here (see moby/buildkit#2047), but the underlying error is that the nginx.conf file is not present on your client, is excluded by .dockerignore, or (depending on your setup) could be referenced using the wrong «casing» (uppercase/lowercase); double check that the file exists, that it’s not excluded by a .dockerignore file, that it’s readable by the current user, and if the path is correct and has the correct casing.

Example 5

failed to solve with frontend dockerfile.v0: failed to build LLB: error from sender: open node_moduleseslint-plugin-testing-librarynode_modules@typescript-eslintexperimental-utils_ts3.4distts-eslint-scope: Access is denied

(1) failed to solve with frontend dockerfile.v0:
(2) failed to build LLB:
(3) error from sender:
(4) open node_moduleseslint-plugin-testing-librarynode_modules@typescript-eslintexperimental-utils_ts3.4distts-eslint-scope:
(5) Access is denied

Here the error looks to be on the «client» (cli) side: the docker / buildkit daemon requested the CLI to send a file, but the user running the client did not have access to the file or directory.

Note that filesystem errors (e.g. «Access is denied») may differ between operating systems, and the error message can sometimes be somewhat misleading; they should give you a starting point to debug (and hopefully solve) what’s wrong in your situation though.

Example 6

failed to solve with frontend dockerfile.v0: failed to create LLB definition: dockerfile parse error line 4: unknown instruction: LIBMCRYPT-DEV

(1) failed to solve with frontend dockerfile.v0:
(2) failed to create LLB definition:
(3) dockerfile parse error line 4:
(4) unknown instruction: LIBMCRYPT-DEV

This error is a syntax error in the Dockerfile; make sure you didn’t miss (for example) a line-continuation () marker; I expect LIBMCRYPT-DEV was part of a RUN ... line, but due to a missing line-continuation marker, the Dockerfile parser attempted to read it as a Dockerfile instruction, instead of as part of the RUN instruction.

But these errors are so hard to read!

Yes, some of these errors are horrible; they’re often too verbose and while the extra information may help us to find in what part / subsystem of the build process the error is occurring, they can be daunting for users.

We’re looking at improving these errors to make the more readable. For example: moby/moby#42329 (comment) shows an improved error message when using Buildx;

Dockerfile:3
--------------------
   1 |     # syntax=docker/dockerfile-upstream:master
   2 |     FROM busybox
   3 | >>> RUNCMD
   4 |
--------------------
error: failed to solve: rpc error: code = Unknown desc = failed to create LLB definition: dockerfile parse error line 3: unknown instruction: RUNCMD

But further improvements will still be made.

I hope the above helps users that run into errors to narrow down the cause. If you run into an issue, and still think there’s a bug, feel free to open a new ticket, but (as may be clear from the above) make sure to include details about the issue, and provide the exact steps to reproduce (taking into account that maintainers of this project do not have access to your private GitHub and Docker Hub repositories).

[SOLVED] failed to solve with frontend dockerfile.v0

In this article, we have explored the reason behind the error «failed to solve with frontend dockerfile.v0» and presented multiple ways (5) to fix it. This error is related to Buildkit and LLB component of Docker.

Table of contents:

1. The Error: failed to solve with frontend dockerfile.v0
2. Fix 1: Disable Buildkit of Docker
3. Fix 2: Ensure Dockerfile is named correctly
4. Fix 3: Specify filename in docker-compose.yml
5. Fix 4: Delete token seed
6. Fix 5: Disable Buildkit from settings
7. Concluding Note

Following error summarizes the case of this error:

Point Details on error Error: failed to solve with frontend dockerfile.v0 Variants of the error:

• failed to compute cache key: «/.env» not found: not found
• error from sender: context canceled
• rpc error: code = Unknown desc = failed to parse
• and more.

Source of error: Modcache, Buildkit or LLB component in Docker When error comes? While building a Docker file Number of possible fixes 5

The Error: failed to solve with frontend dockerfile.v0

While building a Docker using the following command, you may encounter a specific error that will act as a blocker.

Following is the error you may get depending on your environment:

This can be attributed to a known issue with the Modcache or Buildkit in Docker system. There can be other sources of this error and as we have presented multiple solutions.

• LLB stands for Low Level Build and is a binary format that is used internally by Docker. It uses a graph data structure.
• Frontend is the component in Docker that converts the defined Docker build format to LLB.
• The error happens in this step.

Following components are the source of this error:

• Buildkit
• LLB
• Frontend (error occurs in this step)

Fix 1: Disable Buildkit of Docker

Buildkit is a new utility in Docker that replaces the legacy builder. It has a feature to reuse dockerfiles for optimal performance and handle complex situations. It has been observed that the utility does not work well with all legacy docker files and hence, the error will come. The fix is to disable Buildkit using the following two environmental variables:

Following this, try building the Docker again and the error will be fixed:

Depending on your system environment, if this fix does not work, move to the next fix. You need not revert back the changes in this fix.

Fix 2: Ensure Dockerfile is named correctly

Make sure that the docker file is named as «Dockerfile» exactly and not as other variants like «DockerFile», «dockerfile» and others.

The docker command fetches this file in a case-sensitive fashion and if it is wrongly named, the docker command is unable to find the setting file and hence, the error may come up.

Fix 3: Specify filename in docker-compose.yml

If the above fix does not work, we may try to specific the Docker file name in docker-compose.yml file to ensure that the Docker picks up the right file overcoming Modcache component.

By default, docker-compose.yml will look as follows:

It should be updated as:

Notice the last line where the filename is specified.

Fix 4: Delete token seed

If you are using MacOS and you get this error:

The simple fix is to delete the following 2 files in /Users/opengenus/.docker/ directory:

This will start a fresh build ignoring the cached components from the previous failed Docker builds.

Fix 5: Disable Buildkit from settings

In Fix 1, we tried to disable Buildkit through environment variables. In some cases, when Docker is used in a Desktop system running Windows or MacOS, we need to disable it from the settings.

Disable buildkit in «Docker Engine» JSON config (in Docker on desktop system). The steps are as follows:

• Open Docker Desktop applications
• Go to Settings
• Go to «Docker Engine»
• Update the true value for buildkit to false in features section.

This should finally fix the error and you can proceed forward building the Docker file.

Concluding Note

Docker is an important tool with several components which may not work well with legacy Docker files. Resolving such errors and proceeding to build Docker files is easy if you find the right fix as presented in this article at OpenGenus.

With this article at OpenGenus, you must have the complete idea of how to solve this Docker error successfully.

Benjamin QoChuk, PhD

Benjamin QoChuk is a Computer Science Researcher, Inventor and Author. His educational background include Bachelors at Vanderbilt University and PhD in Computer Science at Peking University.

Источник

Solution for Docker issue failed to solve: rpc error: code = unknown desc

This post presents a solution to an error I encountered recently with Docker when trying to bring up a docker container using docker-compose.

The solution in the post helped me fix the Docker issue failed to solve: rpc error: code = unknown desc = failed to solve with frontend dockerfile v0

Docker Error Messages

If you have been having the same problem as me, you might get one of the following error messages from Docker:

docker failed to solve rpc error code = unknown desc

docker failed to solve with frontend dockerfile.v0

failed to solve: rpc error: code = unknown desc = failed to solve with frontend dockerfile v0

Docker build error: failed to solve with the frontend dockerfile

Problem

The problem with Docker was happening when I was trying to bring up docker using a docker-compose file. I was using a command similar to this one:

> sudo -E docker-compose -f docker-compose.yml -f docker-compose.local.yml up —build

The error message I got was as follows:

I tried a few variations to bring up the docker containers

> sudo docker-compose -f docker-compose.local.yml up -d

I got similar error messages from docker:

I also tried to clear out existing docker containers and images from the cache. > sudo docker system prune -a -f This did not work when I tried to rebuild docker containers as above.

The consistent error from each of the commands I tried that failed seemed to be not finding a docker file.

Docker Setup

You can skip to the solution here, as this section helps check if docker is correctly installed.

The first step you can try is to make sure you can actually run a ‘hello world’ docker image successfully. You can do this by executing the following command:

> docker run hello-world

The output of this command should be as follows:

As suggested in the output of the docker hello world example, you can try a more advanced docker test, which would be to run the latest ubuntu image and execute command via the bash terminal in ubuntu.

> docker run -it ubuntu bash

The output should be as follow, and should give you terminal access as the root user.

Solution

The solution is to explicitly give the name of the docker file in the docker-compose.yml. Change how you specify the location of your dockerfile from dockerfile: . to dockerfile: Dockerfile

This is an sample of the docker-compose file which did not work on Ubuntu 20.04 or Windows10, it only seems to work on MacOS only. As you can see, the dockerfile location is specified as a ‘.’

The sample docker-compose file shown below is a working cross platform file, which works on MacOS, Ubuntu, Windows10.

As you can see, the line specifying the dockerfile has been changed from a dot ‘.’ to the explicit file name, in my case, it was ‘Dockerfile’.

This also works with lower and uppercase docker files as dockerfile: Dockerfile or dockerfile: dockerfile

Conclusion

The problem seemed to originate from the cross platform development and testing of the docker-compose script, between MacOS and Ubuntu / Window10 using version 3 of docker-compose. In the scenario of specifying the location of the dockerfile.

The original docker-compose file was built on MacOS, I was trying to use the same file but on Ubuntu 20.04. I believe this same problem can also occur if also trying to use docker-compose developed using MacOS on Windows10.

If you are using MacOS, then this docker-compose file will most likely run without any problems (if you do not have any other unrelated problems).

You can read more about how I have used docker in my other projects.

What can you do to improve your life as a programmer?

my article provides some ideas!

If this article helped you out, consider buying me a beer coffee?

Creating your first programming language is easier than you think,
. also looks great on your resume/cv.

Any comments? Send me a message on twitter @AyeshAlshukri or on Reddit /user/AyeshAlshukri/

Источник

WSL2: docker build — error getting credentials #11261

Actual behavior

On new installed system/device (non-English localized Windows, WSL2, Docker Desktop, no credentials in windows credential store), docker build . exits for a fairly simple Dockerfile (see: steps to reproduce) with the error:

Expected behavior

On new installed system/device (non-English localized Windows, WSL2, Docker Desktop, no credentials in windows credential store), docker build . for a fairly simple Dockerfile (see: steps to reproduce) just works as expected.

Information

Is it reproducible? Yes

Is the problem new? Yes

Did the problem appear with an update? No

Windows Version: 20H2 (Build 19042.508) — non-English localized

Docker Desktop Version: 3.3.3 (64133)

WSL2 or Hyper-V backend? WSL2

Are you running inside a virtualized Windows e.g. on a cloud server or a VM? No

Steps to reproduce the behavior

1. Install a new copy / set you current copy of Windows 10 Version 20H2 (Build 19042.508) with language set to anything but English
2. Install WSL2 following the manual at Microsoft Docs with latest Debian image
3. Install Docker Desktop for Windows Version 3.3.3 (64133), enable WSL integration
4. Ensure that there are non entries in windows credential manager
5. Create a (temporary) directory for testing docker build (whether within WSL or Windows filesystem — does not make a difference)
6. cd into the previously created (temporary) testing directory
7. Create this fairly simple Dockerfile:

Working Quick-Fix

I found out that disabling the buildkit feature by configuring the Docker Engine via Docker Desktop solves this issue.

Nevertheless I wanted to report my struggle here, since I was just installing everything at current versions on a clean and new system and it does not work without custom configuration. Also I do not know the side-effects for disabling buildkit , so I am looking for a clean solution, i.e. bugfix, for this basic use-case issue.

Some guesses

This issue might be related to the WSL users Docker .config file.

But maybe I am wrong with this guess.

The text was updated successfully, but these errors were encountered:

I just found out that executing C:Program FilesDockerDockerresourcesbindocker-credential-desktop.exe list from within standard Windows command prompt gives the same error:

Credential Helper version: 0.6.3

By the way, editing

/.docker/config.json will not last. «credsStore»: «desktop.exe» gets added automatically on Docker restart.

I investigated a bit further and found something interesting.

First, the issue does not show on English-language systems or when there is any credential saved in windows credential store (It does not matter which one but there has to be one).

So this issue only shows on non-English systems with no credentials stored in the windows credential store.

And here is the explanation:

The currently most recent (released) Credential Helper (version 0.6.3) has been released on 16 Jul 2019.

Источник

Cannot build from local image with buildctl (OCI Worker) #1142

Description

Cannot build from a local image with buildctl which always tries to resolve to docker.io . This applies to a multi-stage setup or simply from a local image in a CI setup. The base image should not be expected to be pushed to any repository (either docker.io or even private). It is only available locally ( docker images ).

This works with docker build and even DOCKER_BUILDKIT=1 using image names (but not SHA ID in the last case). See also moby/moby#39769.

This looks similar to the problems with local cache described here: moby/moby#39003.

Steps to reproduce the issue:

1. Demo project available here: https://github.com/virgile-hogman/docker-buildkit
2. Run ./buildctl-build.sh from bash
3. See logs, fails to resolve FROM docker.io/library/bk1:latest

Describe the results you received:

Describe the results you expected:

This should work as for docker build when using image names (with or without DOCKER_BUILDKIT=1 . Note with SHA-ID it does not work either in the last case as described in moby/moby#39769).

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version :

Output of docker info :

Additional environment details (AWS, VirtualBox, physical, etc.):

Connected to a private repository on a different host but this should not have effect here since it works with standard docker build .

The text was updated successfully, but these errors were encountered:

Buildkit with oci worker does not provide an image store. This has been discussed in the past but would mean we would need to add image management commands in the API. You can use containerd worker with the containerd image store(managed with ctr) or docker/buildx with docker image store.

@tonistiigi thanks for the answer, but coming just from the «docker world» i don’t know exactly how to use containerd from buildkit in practice, especially the fetching part.

In this example i have a Dockerfile depending on a first one built only locally. Let’s assume it is stored with containerd. But then it’s still buildkit that needs to load it, so how would it find it in that local store? Do you need to name the local image in a particular way?

But then it’s still buildkit that needs to load it, so how would it find it in that local store? Do you need to name the local image in a particular way?

The first build would export it with a name —output type=image,name=myname and then another build can refer to it by that name.

I tried this but the second build still fails for the same reason. I don’t still understand how the loaders work and how buildkit is going to find such image. I’m using the dockerized version of buildkit:

The first build produces an image that i can «somehow» see with buildctl du -v though i don’t see the image name. There are some IDs which are not prefixed by sha apart from the base image corresponding to the alpine image. What am i missing? I don’t know how to use ctr with this. The first image seems to be stored somewhere but i can’t tell where.

moby/buildkit:latest image is only configured for the oci worker. To run the containerd worker you need to have containerd running and start buildkitd with —oci-worker=false —containerd-worker=true

Is there any simple tutorial or documentation for setting up such a configuration? I have never used containerd and it sounds quite obscure to an end-user not familiar with terms like rund, containerd, workers or OCI, this all sounds like internal stuff for container developers which i’m not. The nice thing with Docker is its convenience and accessibility, it can be used out of the box from a simple apt installation. Here i don’t even know where to look.

I face the same problem, and tried to switch from oci to containerd worker but fails to boot the buildkit deamon.

The image tag for moby/buildkit is 8ce8d3df040f. I am running on Mac Docker desktop (2.1.03) with Engine version 19.03.2

Is that I must build the buildkitd myself if I want to test with the containerd worker? Thanks for your help.

I’m experiencing the same issue. Looking into the moby/buildkit image ( 8ce8d3df040f ) looks to me that there is no trace of containerd executables.

@tonistiigi since you suggested to start containerd before buildkitd —oci-worker=false —containerd-worker=true , can you please explain the necessary steps?
I went through the docs of docker/buildx , moby/buildkit and containerd/containerd with no luck.

I’m also freshly started with docker, but from the official documentation buildx is described as an improved version of build , but I’m a bit puzzled on why it can fail the very simple (and common I think) use case of creating an image starting from a base image already available locally under docker images .

As I wrote in #1142 (comment) moby/buildkit is made for oci worker. It does not come with containerd binaries. If you want to run containerd you can refer to their getting started guide https://github.com/containerd/containerd/blob/master/docs/getting-started.md#getting-started-with-containerd . If you have containerd running you can start buildkitd binary with configuration pointing to your containerd daemon. As containerd runs in host and requires clients to share the filesystem, normally you would run buildkitd in host as well in that case. There’s an old example of how to run them both in containers in #192 (comment) but that’s probably not what you want.

I’m also freshly started with docker, but from the official documentation buildx is described as an improved version of build, but I’m a bit puzzled on why it can fail the very simple (and common I think) use case of creating an image starting from a base image already available locally under docker images.

buildx doesn’t have anything to do with the question in here that is about buildctl. in buildx results are automatically get/put to docker images with docker driver, and with container driver —load loads the build results into docker. buildx never interacts with containerd daemon, nor does running a containerd daemon have any influence on the output of docker images .

Ok, I think I’m getting even more confused, maybe I’ll describe my use case more in detail to explain how I ended up here.
I’m running docker desktop on Mac OS.

• I want to build a base image of a linux OS, for which I need to use the new buildkit experimental RUN —security=insecure in my Dockerfile
• From the official docs, docker buildx build «extends the docker command with the full support of the features provided by Moby BuildKit builder» that looked to me like an easy entry point to use BuildKit
• To be able to use RUN —security=insecure , I need to create a builder instance with the insecure entitlement enabled for the buildkitd daemon by:
  docker buildx create —name insecure-builder —buildkitd-flags ‘—allow-insecure-entitlement security.insecure’
  which creates and enables a builder using the docker-container driver
• Now I can build my first image with: docker buildx build -t fvg/test:latest —load —allow security.insecure -f test.Dockerfile .
  here’s the sample test.Dockerfile:

• The image is correctly visible (and usable) under docker image ls . Now I want to build a second image that is based on the first: docker buildx build -t fvg/test2:latest —load —allow security.insecure -f test2.Dockerfile .
  here’s the test2.Dockerfile:

• The build fails looking to resolve docker.io/fvg/test:latest , failing to load the local image.

If I try the same using the default builder under docker buildx ls with driver docker it works without error, but then I cannot build using —allow security.insecure , which is not allowed apparently.

@gfrancesco If you want buildx to access docker images it needs to use docker driver. It is true that for the —security it was just added lately and can’t be enabled atm. in docker. The PR for that is in moby/moby#39144 and you need to wait for that fix in order to use these 2 features together. If you want to use —security today with the container driver you can use a registry or combine your requests into a multi-stage Dockerfile for the same behavior.

Thanks for helping, I’ll keep an eye on the PR and look into use a registry in the meantime 🙂

moby/moby#39144 has been merged in yet it looks like I got the same problem on circleci:

The dockerfile is a multi-stage dockerfile.

partial docker build script:

Output of the above is:

docker build script log:

Note that base image on circleci worked fine with buildkit enabled, so buildkit can work with circleci — it’s just fails in the situation above for some reason 🤔

Источник