download-1 | exec /docker/download.sh: exec format error

[blue-eyed-g]

I follow the page:https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup git clone the repo,then docker compose --profile download up --build in the folder. and then an error occured: [+] Building 2.2s (9/9) FINISHED docker:default => [download internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [download internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 171B 0.0s => [download internal] load metadata for docker.io/library/bash:alpine3.15 2.1s => [download 1/4] FROM docker.io/library/bash:alpine3.15@sha256:463b668dccc38f32a5b 0.0s => [download internal] load build context 0.0s => => transferring context: 128B 0.0s => CACHED [download 2/4] RUN apk add parallel aria2 0.0s => CACHED [download 3/4] COPY . /docker 0.0s => CACHED [download 4/4] RUN chmod +x /docker/download.sh 0.0s => [download] exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:5f350568a8839f416aa58d37fca2ec7538cf1439febec1aad3fb7a2d 0.0s => => naming to docker.io/library/webui-docker-download 0.0s [+] Running 1/0 ✔ Container webui-docker-download-1 Created 0.0s Attaching to download-1 download-1 | exec /docker/download.sh: exec format error download-1 exited with code 1

i don't know how to solve it, can anybody help me? thanks

[simonmcnair]

can you verify download.sh ?

[blue-eyed-g]

can you verify download.sh ?

sorry, i cant. i dont know how to open download.sh.

[jsjolund]

Can you describe in more detail how to reproduce this? Follow the bug report template that you deleted when you wrote the issue:

Hardware / Software

• OS: [e.g. Windows 10 / Ubuntu 22.04]
• OS version:
• WSL version (if applicable):
• Docker Version:
• Docker compose version:
• Repo version:
• RAM:
• GPU/VRAM:

[blue-eyed-g]

Has this issue been opened before?

• [*] It is not in the FAQ, I checked.
• [*] It is not in the issues, I searched.

Describe the bug try to run docker compose --profile download up --build, and then error occure:

[+] Building 2.2s (9/9) FINISHED docker:default => [download internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [download internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 171B 0.0s => [download internal] load metadata for docker.io/library/bash:alpine3.15 2.1s => [download 1/4] FROM docker.io/library/bash:alpine3.15@sha256:463b668dccc38f32a5b 0.0s => [download internal] load build context 0.0s => => transferring context: 128B 0.0s => CACHED [download 2/4] RUN apk add parallel aria2 0.0s => CACHED [download 3/4] COPY . /docker 0.0s => CACHED [download 4/4] RUN chmod +x /docker/download.sh 0.0s => [download] exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:5f350568a8839f416aa58d37fca2ec7538cf1439febec1aad3fb7a2d 0.0s => => naming to docker.io/library/webui-docker-download 0.0s [+] Running 1/0 ✔ Container webui-docker-download-1 Created 0.0s Attaching to download-1 download-1 | exec /docker/download.sh: exec format error download-1 exited with code 1

Which UI

no

Hardware / Software

• OS: linux
• OS version: archlinux ,Linux 6.6.2-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Mon, 20 Nov 2023 23:17:26 +0000 x86_64 GNU/Linux
• Docker Version: 24.0.7, build afdd53b4e3
• Docker compose version: 2.23.1
• Repo version: master
• RAM:32G
• GPU/VRAM:2070S

Steps to Reproduce

1. git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.git
2. cd stable-diffusion-webui-docker/
3. docker compose --profile download up --build
4. See error

Additional context no

[DevilaN]

CRLF vs CR line endings issue maybe?

Conversion is done by local git during pulling files. This behavior depends on git configuration.

[blue-eyed-g]

CRLF vs CR line endings issue maybe?

Conversion is done by local git during pulling files. This behavior depends on git configuration.

How to check if the configuration is correct? i did not modify any configuration on git global or repo

[simonmcnair]

The files you're talking about haven't been updated in 5 months or so, and no one else has reported the issue. This leads me to believe that you may have corruption or an interrupted download. I would recommend deleting the tree and starting again from scratch and seeing if it happens again.

[simonmcnair]

I would also ensure that you are using docker installed from https://docs.docker.com/desktop/install/archlinux/ not from any distribution package manager.

I am using Debian and it works fine for me.

[jsjolund]

I would also ensure that you are using docker installed from https://docs.docker.com/desktop/install/archlinux/ not from any distribution package manager.

I am using Debian and it works fine for me.

I am using Arch Linux, and the docker from the package manager works fine.

[simonmcnair]

I would also ensure that you are using docker installed from https://docs.docker.com/desktop/install/archlinux/ not from any distribution package manager. I am using Debian and it works fine for me.

I am using Arch Linux, and the docker from the package manager works fine.

I am sure it does work fine. It probably just doesn't satisfy the requirements of https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup which state https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup#make-sure-you-have-the-latest-version-of-docker-and-docker-compose-installed

Normally there is a delay between Docker releasing packages, and arch, or whichever distribution, repackaging them for their package manager. But if it works for you that's great. I was just covering the out of date docker angle.

[DevilaN]

If you have git-bash installed then in the shell you can check it using file command like this:

Correct line endings:

$ file services/download/download.sh 
services/download/download.sh: Bourne-Again shell script, ASCII text executable

Incorrect line endings:

$ file services/download/download.sh 
services/download/download.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

[jsjolund]

I am sure it does work fine. It probably just doesn't satisfy the requirements of https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup which state https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup#make-sure-you-have-the-latest-version-of-docker-and-docker-compose-installed

Normally there is a delay between Docker releasing packages, and arch, or whichever distribution, repackaging them for their package manager. But if it works for you that's great. I was just covering the out of date docker angle.

Slightly off-topic, but it does satisfy the version requirement (docker version 24.0.7).

https://docs.docker.com/engine/release-notes/24.0/

https://archlinux.org/packages/extra/x86_64/docker/

Arch Linux is a rolling-release distro and updates packages much faster than Debian.

[simonmcnair]

I am sure it does work fine. It probably just doesn't satisfy the requirements of https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup which state https://github.com/AbdBarho/stable-diffusion-webui-docker/wiki/Setup#make-sure-you-have-the-latest-version-of-docker-and-docker-compose-installed Normally there is a delay between Docker releasing packages, and arch, or whichever distribution, repackaging them for their package manager. But if it works for you that's great. I was just covering the out of date docker angle.

Slightly off-topic, but it does satisfy the version requirement (docker version 24.0.7).

https://docs.docker.com/engine/release-notes/24.0/

https://archlinux.org/packages/extra/x86_64/docker/

Arch Linux is a rolling-release distro and updates packages much faster than Debian.

lol. It's later than mine ;-)

Docker version 24.0.2, build cb74dfc

[edit] one of my machines was up to date, one wasn't. turns out my sources on one machine didn't have docker in it. thanks for the assist !

[jsjolund]

@blue-eyed-g

I am also using Arch, with the same docker version, although with the standard kernel (not zen), and the download works for me.

Although git makes corrupted files unlikely, have you tried cloning again and re-running?

Also, please post your /etc/docker/daemon.json. It should look something like this:

{
  "runtimes": {
    "nvidia": {
      "path": "/usr/bin/nvidia-container-runtime",
      "runtimeArgs": []
    }
  },
  "default-runtime": "nvidia",
  "max-concurrent-uploads": 2,
  "features": {
    "buildkit": true
  }
}

Edit:

Also, are you using some unusual file system like zfs?

[simonmcnair]

@blue-eyed-g

I am also using Arch, with the same docker version, although with the standard kernel (not zen), and the download works for me.

Although git makes corrupted files unlikely, have you tried cloning again and re-running?

Also, please post your /etc/docker/daemon.json. It should look something like this:

{
  "runtimes": {
    "nvidia": {
      "path": "/usr/bin/nvidia-container-runtime",
      "runtimeArgs": []
    }
  },
  "default-runtime": "nvidia",
  "max-concurrent-uploads": 2,
  "features": {
    "buildkit": true
  }
}

Edit:

Also, are you using some unusual file system like zfs?

Another thing I learnt. I installed nvidia-container-runtime, but I never executed sudo nvidia-ctk runtime configure --runtime=docker

I wonder why I didn't get any errors.

[blue-eyed-g]

@jsjolund I am also using Arch, with the same docker version, although with the standard kernel (not zen), and the download works for me. Although git makes corrupted files unlikely, have you tried cloning again and re-running? Also, please post your /etc/docker/daemon.json. It should look something like this:

{
  "runtimes": {
    "nvidia": {
      "path": "/usr/bin/nvidia-container-runtime",
      "runtimeArgs": []
    }
  },
  "default-runtime": "nvidia",
  "max-concurrent-uploads": 2,
  "features": {
    "buildkit": true
  }
}

Edit: Also, are you using some unusual file system like zfs?

Another thing I learnt. I installed nvidia-container-runtime, but I never executed sudo nvidia-ctk runtime configure --runtime=docker

I wonder why I didn't get any errors.

I have tried remove the repo(rm -r stable-diffusion-webui-docker),remve the image((webui-docker-download:latest) and container(webui-docker-download-1). Then restart my arch. Clone the repo and run again. But the same error appeared.

This is my /etc/docker/daemon.json

{ "runtimes": { "nvidia": { "path": "nvidia-container-runtime", "runtimeArgs": [] } },

"data-root": "/home/username/docker"

}

[simonmcnair]

what happens when you run this from a terminal ? /usr/bin/env bash

[blue-eyed-g]

what happens when you run this from a terminal ? /usr/bin/env bash

nothing

[blue-eyed-g]

If you have git-bash installed then in the shell you can check it using file command like this:

Correct line endings:

$ file services/download/download.sh 
services/download/download.sh: Bourne-Again shell script, ASCII text executable

Incorrect line endings:

$ file services/download/download.sh 
services/download/download.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

Thanks, I have checked and it is correct

[jsjolund]

Well, I am out of ideas, so I asked ChatGPT:

Assuming the Dockerfile and script are correct and work on other systems, it's less likely that the issue is with the Docker system configuration itself. However, there are a few Docker-related aspects that might cause or contribute to the "exec format error" in certain scenarios:

• Architecture Mismatch: If you're running Docker on a different architecture than the one the image was built for (e.g., trying to run an ARM image on an x86 system or vice versa), you might encounter this error. This can happen if you're using a multi-architecture setup or a different type of hardware.

• Storage Driver Issues: The Docker storage driver in use (overlay2, aufs, devicemapper, etc.) might have compatibility issues or bugs, although this is less common. If you've changed the storage driver from the default, try switching back to see if it resolves the issue.

• Corrupted Docker Image Cache: Sometimes, the local Docker image cache can become corrupted. You can try clearing the cache and rebuilding the image. Use docker system prune to clean up unused images and then rebuild the image.

• Filesystem Issues: If you've changed the Docker "data-root" to a filesystem that doesn't support certain features (like exec permissions), this could potentially cause problems. Ensure that the filesystem where Docker stores its data supports all necessary features.

• SELinux/AppArmor Profiles: If you're running Docker on a system with SELinux or AppArmor, and these security modules are configured to restrict certain actions, they might interfere with Docker's operation. Check the relevant security policies to ensure they're not causing the issue.

• Docker Daemon Configuration: Although less likely, certain configurations in /etc/docker/daemon.json might impact how containers are run. Review this configuration file for any non-standard settings that might affect container execution.

• Kernel Version or Configuration: In some cases, the Linux kernel version or specific kernel configurations might affect Docker's operation, particularly in terms of executing binaries within containers.

To troubleshoot further, you can try running the container on a different system with a similar environment or checking the Docker daemon logs for more detailed error messages. Additionally, verifying that the Docker version is up-to-date and consistent with the version used in the working systems could also provide clues.

[jsjolund]

@blue-eyed-g

Just to make sure, have you checked that the folder /home/username/docker actually exists?

[blue-eyed-g]

thanks you everyone, maybe the problem is from download.sh, i just add echo "Script is starting after the line #!/usr/bin/env bash, then it works. but i dont know why.

[lrstanley]

FWIW, exec format error is very likely to be a mismatch in CPU architecture (funnily enough, also noted here by chatgpt https://github.com/AbdBarho/stable-diffusion-webui-docker/issues/619#issuecomment-1829780349). These are the two most common situations I've seen:

1. mismatch inside of the given container/image.
   • e.g. one of the cli binaries, in this case bash, aria2c, or parallel from what I see in the download.sh script, being x86_64 (because of the base image being pulled), not being runnable by your architecture.
2. mismatch between what architecture in general the container/image was built with.
   • usually caused by pulling down the wrong image, the "default" (and only) architecture type of the image not being the one you're running with, etc.

[simonmcnair]

FWIW, exec format error is very likely to be a mismatch in CPU architecture (funnily enough, also noted here by chatgpt #619 (comment)). These are the two most common situations I've seen:

1. mismatch inside of the given container/image.

   • e.g. one of the cli binaries, in this case bash, aria2c, or parallel from what I see in the download.sh script, being x86_64 (because of the base image being pulled), not being runnable by your architecture.

2. mismatch between what architecture in general the container/image was built with.

   • usually caused by pulling down the wrong image, the "default" (and only) architecture type of the image not being the one you're running with, etc.

I strongly disagree with this statement ;-). I don't know many people running Stable diffusion on ARM and x64 is pretty much a base requirement to do anything useful on Docker. I would say over 99.8% of people will be running x86_64. Just my opinion though.

[simonmcnair]

For me the most common reasons are probably carriage return, line feed conventions between Windows and Linux, corrupt download (although git shouldn't do that), corrupt filesystem (also unlikely). Out dated Docker, or failure of aria to download a file.