I simply started docker build . after cloning github tarantool/docker repository and got the error message:
cp: can't stat '.libs/libprofiler.so*': No such file or directory
This error is reproduced for every container version that I tried to build from 1.9 to 2.1. So I think I've stumbled on some well-known problem (?).
My docker version is:
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:31 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:13:06 2019
OS/Arch: linux/amd64
Experimental: false
Problem is in line endings. Setup your git client to not change line endings to CRLF if you're working with cross-platform projects.
Workaround in this particular case: go to gperftools_alpine.diff, change all line endings to LF, rerun the build.
Related
I've installed docker in windows 10 successfully.
I can run docker version and see this result
$ docker version
Client: Docker Engine - Community
Cloud integration: 1.0.4
Version: 20.10.0
API version: 1.41
Go version: go1.13.15
Git commit: 7287ab3
Built: Tue Dec 8 18:55:31 2020
OS/Arch: windows/amd64
Context: myacicontext
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.0
API version: 1.41 (minimum version 1.24)
Go version: go1.13.15
Git commit: eeddea2
Built: Tue Dec 8 19:07:44 2020
OS/Arch: windows/amd64
Experimental: false
but when I run $ docker images I receive this error
unknown command "images" for "docker"
The problem is that you're not in the right context.
From your logs I can see that you're in the "acicontext" where the $ docker images command is not available. I had the same issue when I tried to deploy a container to Azure.
To resolve this, first, run the command $ docker context list in Powershell. You should be seeing a list of contexts and the one that you're on has a star right next to its name like so :
If you want to be able to use the $ docker images command you have to go inside the right context, which in this example is "default". To do so, run $ docker context use default
Then run $ docker images again, it should be working.
You can read more about Docker context here https://docs.docker.com/engine/context/working-with-contexts/
I had the same issue, and I had to uninstall and reinstall, wich
From the look of the doc, I was under the impression that
docker -D -l debug --debug pull ...
will print verbose logging of some kind. But that wasn't the case.
Neither was the setting in advance setting:
Am I missing something? docker info does confirm I am in debug mode, though it doesn't say anything about logging location. Not sure if I am missing something here.
I'm on Mac
➜ ~ docker version
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:21:31 2018
OS/Arch: darwin/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:29:02 2018
OS/Arch: linux/amd64
Experimental: true
Nevermind I found that there's rarely any debug logging in the source code, for this pull target especially there is none: https://github.com/docker/docker-ce/blob/master/components/cli/vendor/github.com/docker/docker/client/image_create.go
I just got a new Mac. My old Mac had a shell script that included these lines:
ACTIVE=`docker-machine active 2>/dev/null`
HOST_IP=`docker-machine ip $ACTIVE`
When I run this on the new machine it doesn't work. Just running the docker-machine active command independently I get output like this:
No active host found
I figured I try to create a default with docker-machine create default, but got this:
dial-http tcp 127.0.0.1:49719: unexpected EOF
I'm not sure what version of Docker my old Mac was running, but it was native. New Mac:
Client:
Version: 17.06.1-ce
API version: 1.30
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:53:38 2017
OS/Arch: darwin/amd64
Server:
Version: 17.06.1-ce
API version: 1.30 (minimum version 1.12)
Go version: go1.8.3
Git commit: 874a737
Built: Thu Aug 17 22:54:55 2017
OS/Arch: linux/amd64
Experimental: true
New versions of Docker for Mac no longer user VirtualBox and docker-machine. It's running on xhyve and you can run docker commands very similar to if you were running docker natively on a linux host. There's still a VM under the covers (using moby), but your scripts shouldn't see that anymore. Anything you use to connect to published ports can now connect to localhost as if it is running directly on the Mac host.
I'm creating a Docker container with the following command:
docker run -v /data -d ubuntu
Afterwards I try to find out the real location of the volume with:
docker inspect 12345678
and it shows that it's in /var/lib/docker/volumes/0ef2ed2715456b767fe52d38a316074c3da4a6fa82e4e42e5595c8dd8b5f0440/_data
ls: /var/lib/docker/volumes/0ef2ed2715456----/_data:
But I don't actually have a /var/lib/docker directory.
What am I missing?
I'm using Docker 1.12 on Mac.
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.7.1
Git commit: 6f9534c
Built: Thu Sep 8 10:31:18 2016
OS/Arch: darwin/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 17:52:38 2016
OS/Arch: linux/amd64
Docker on Mac runs a docker engine in a Linux VM, not your Mac OS, so you can't find the volume's mount point in your Mac OS file system. Please check my answer in this question: Docker Named Volume location Mac
When I execute 'docker load file', something was wrong:
XXXdeMacBook-Pro:~ wuxinming$ sudo docker load -i crm_mysql-0.1.tar
invalid argument
XXXdeMacBook-Pro:~ wuxinming$ docker version
Client:
Version: 1.12.0-rc2
API version: 1.24
Go version: go1.6.2
Git commit: 906eacd
Built: Fri Jun 17 20:35:33 2016
OS/Arch: darwin/amd64
Experimental: true
Server:
Version: 1.12.0-rc2
API version: 1.24
Go version: go1.6.2
Git commit: a7119de
Built: Fri Jun 17 22:09:20 2016
OS/Arch: linux/amd64
Experimental: true
The command works well on Windows and Linux, but not Mac.