search

openhab / openhab-docker

Repository for building Docker containers for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
209 stars 128 forks source link

Docker unable to build from 2.5.11 -- copy files error #348

Closed cacack closed 3 years ago

cacack commented 3 years ago

Given this Dockerfile:

FROM openhab/openhab:2.5.11

RUN echo "test"

When I build it, I receive the error failed to copy files: copy file range failed: invalid argument:

❯ docker build .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM openhab/openhab:2.5.11
2.5.11: Pulling from openhab/openhab
6ec7b7d162b2: Already exists 
311d5afe43fe: Pull complete 
1cb842843fb9: Pull complete 
c9d59ff9e9c9: Pull complete 
6cc6a0d3d94d: Pull complete 
3951db9532a5: Pull complete 
Digest: sha256:4ca2294fd2cbf2a3c6844e9b016f54d7c7e355176402a77faa563cb50cef4afc
Status: Downloaded newer image for openhab/openhab:2.5.11
 ---> e159c57dec83
Step 2/2 : RUN echo "test"
failed to copy files: copy file range failed: invalid argument

Docker info:

❯ docker info                         
Client: 
 Context:    default
 Debug Mode: false   
 Plugins:    
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-tp-docker)

Server:                                
 Containers: 0
  Running: 0                                            
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 20.10.2
 Storage Driver: zfs
  Zpool: tank
  Zpool Health: ONLINE
  Parent Dataset: tank/local/redshirt/docker
  Space Used By Parent: 222960713728
  Space Available: 1787867099136
  Parent Quota: no
  Compression: off
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b.m
 runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.9-arch1-1
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.26GiB
 Name: ...
 ID: OH73:P3TE:XU4D:NYBG:CCVC:PIXK:C6II:5QV3:KOKL:6V7J:6VJZ:D2U3
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: ...
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio weight support
WARNING: No blkio weight_device support

At first I thought it was caused by using the devicemapper storage driver even though I am using ZFS. However, after switching, I'm still receiving the same error. Any help in troubleshooting this would be appreciated!

Also, I originally created a bug ticket against the wrong project (openhab/openhab-distro#1252); moving it here.

cacack commented 3 years ago

Given the warnings about the production-ness of the zfs storage driver, I'm currently migrating /var/lib/docker to a XFS filesystem on a ZVOL, where I'll be able to use the overlay2 storage driver. We'll see if this fixes things.

wborn commented 3 years ago

Works fine for me on Ubuntu 20.04.1 with an ext4 filesystem, so it's probably due to something in your OS:

$ docker build .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM openhab/openhab:2.5.11
2.5.11: Pulling from openhab/openhab
6ec7b7d162b2: Already exists 
311d5afe43fe: Pull complete 
1cb842843fb9: Pull complete 
c9d59ff9e9c9: Pull complete 
6cc6a0d3d94d: Pull complete 
3951db9532a5: Pull complete 
Digest: sha256:4ca2294fd2cbf2a3c6844e9b016f54d7c7e355176402a77faa563cb50cef4afc
Status: Downloaded newer image for openhab/openhab:2.5.11
 ---> e159c57dec83
Step 2/2 : RUN echo "test"
 ---> Running in afa32c4c0fc6
test
Removing intermediate container afa32c4c0fc6
 ---> 3adf78aed2a6
Successfully built 3adf78aed2a6
cacack commented 3 years ago

Happy to report that fixing my storage driver did the trick. With the newer versions, docker falls back to devicemapper which appears to cause issues with buildkit now? Either way, moving to an XFS filesystem on top of a ZVOL allowed me to force docker to use overlay2 (still didn't use it by default, but maybe related to the existing cruft).

Sorry for the noise but maybe this will help any other poor soul who runs docker on a "unique" setup.

wborn commented 3 years ago

Great! For me the benefits of using xfs, btrfs etc. on a daily basis didn't outweigh the convenience and tools available for plain old boring ext4. :wink: