My initial deploy to the server succeeded without any problem. But anytime I try to deploy after that, I get the following error:
remote: tar: node-v8.1.3-linux-x64/bin: Directory renamed before its status could be extracted
remote: tar: Exiting with failure status due to previous errors
Any advice on how to fix this?
Here's the Dokku info:
-----> uname: Linux linus 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
-----> memory:
total used free shared buff/cache available
Mem: 990 196 431 3 362 751
Swap: 1023 109 914
-----> docker version:
Client:
Version: 17.10.0-ce
API version: 1.33
Go version: go1.8.3
Git commit: f4ffd25
Built: Tue Oct 17 19:04:16 2017
OS/Arch: linux/amd64
Server:
Version: 17.10.0-ce
API version: 1.33 (minimum version 1.12)
Go version: go1.8.3
Git commit: f4ffd25
Built: Tue Oct 17 19:02:56 2017
OS/Arch: linux/amd64
Experimental: false
-----> docker daemon info:
Containers: 5
Running: 1
Paused: 0
Stopped: 4
Images: 18
Server Version: 17.10.0-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 06b9cb35161009dcb7123345749fef02f7cea8e0
runc version: 0351df1c5a66838d0c392b4ac4cf9450de844e2d
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-21-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 990.8MiB
Name: linus
ID: HL5G:L4NU:6X7H:PICU:C7A3:KYH5:VCXD:BQYQ:UMCT:4K3Q:JORL:REX4
Docker Root Dir: /var/lib/docker
Debug Mode (client): true
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
-----> sigil version: 0.4.0
-----> herokuish version:
herokuish: 0.3.32
buildpacks:
heroku-buildpack-multi v1.0.0
heroku-buildpack-ruby v168
heroku-buildpack-nodejs v99
heroku-buildpack-clojure v77
heroku-buildpack-python v99
heroku-buildpack-java v53
heroku-buildpack-gradle v23
heroku-buildpack-scala v78
heroku-buildpack-play v26
heroku-buildpack-php v122
heroku-buildpack-go v72
heroku-buildpack-erlang fa17af9
buildpack-nginx v8
-----> dokku version: 0.10.5
-----> dokku plugins:
plugn: 0.3.0
00_dokku-standard 0.10.5 enabled dokku core standard plugin
20_events 0.10.5 enabled dokku core events logging plugin
apps 0.10.5 enabled dokku core apps plugin
build-env 0.10.5 enabled dokku core build-env plugin
certs 0.10.5 enabled dokku core certificate management plugin
checks 0.10.5 enabled dokku core checks plugin
common 0.10.5 enabled dokku core common plugin
config 0.10.5 enabled dokku core config plugin
docker-options 0.10.5 enabled dokku core docker-options plugin
domains 0.10.5 enabled dokku core domains plugin
enter 0.10.5 enabled dokku core enter plugin
git 0.10.5 enabled dokku core git plugin
logs 0.10.5 enabled dokku core logs plugin
named-containers 0.10.5 enabled dokku core named containers plugin
nginx-vhosts 0.10.5 enabled dokku core nginx-vhosts plugin
plugin 0.10.5 enabled dokku core plugin plugin
proxy 0.10.5 enabled dokku core proxy plugin
ps 0.10.5 enabled dokku core ps plugin
repo 0.10.5 enabled dokku core repo plugin
shell 0.10.5 enabled dokku core shell plugin
ssh-keys 0.10.5 enabled dokku core ssh-keys plugin
storage 0.10.5 enabled dokku core storage plugin
tags 0.10.5 enabled dokku core tags plugin
tar 0.10.5 enabled dokku core tar plugin
Seems maybe docker-related, and nothing we can do about it: https://github.com/moby/moby/issues/19647
I would try:
I know this thread is a bit stale, but in case it helps anyone, using the "--absolute-names" switch on tar can workaround this (it worked for me on a 4.1.12-112.14.13.el7uek.x86_64 Oracle Linux kernel): https://lists.gnu.org/archive/html/bug-tar/2004-04/msg00021.html (there are some caveats to using this parameter on tar so have a look at man page first before using). HTH Gil
@gstanden
Your answer helps me solve such problem . Thanks very much.
@lemongao mind making a pull request to our tar deploy docs outlining the fix?
Most helpful comment
I know this thread is a bit stale, but in case it helps anyone, using the "--absolute-names" switch on tar can workaround this (it worked for me on a 4.1.12-112.14.13.el7uek.x86_64 Oracle Linux kernel): https://lists.gnu.org/archive/html/bug-tar/2004-04/msg00021.html (there are some caveats to using this parameter on tar so have a look at man page first before using). HTH Gil