#Unable to use Dagger in Windows or Windows WSL

1 messages · Page 1 of 1 (latest)

half ruin
#

Always getting

failed to copy: httpReadSeeker: failed open: failed to do request: Get "...": EOF
! failed to run command: exit status 1
Error: start engine: failed to pull image: failed to run command: exit status 1

Anyone an idea? Here the full output.

<user>@<pc-name> ~ $ dagger init --sdk=typescript --source=./dagger
✘ connect 2.9s
┃ 16:33:41 WRN failed to get stable ID, defaulting to random value error="failed to rename stable
┃ <truncated for brevity>

Error logs:

✘ connect 2.9s
16:33:41 WRN failed to get stable ID, defaulting to random value error="failed to rename stable
D temp file: rename C:\\Users\\<user>\\AppData\\Local\\dagger\\stable_client_id1752168551 C:\
sers\\<user>\\AppData\\Local\\dagger\\stable_client_id: Der Prozess kann nicht auf die Datei
greifen, da sie von einem anderen Prozess verwendet wird."
! start engine: failed to pull image: failed to run command: exit status 1

✘ exec docker inspect --type=image registry.dagger.io/engine:v0.15.1 0.0s
[]
Error response from daemon: No such image: registry.dagger.io/engine:v0.15.1
! failed to run command: exit status 1

✘ exec docker pull registry.dagger.io/engine:v0.15.1 2.8s
v0.15.1: Pulling from engine
874d7134a279: Pulling fs layer
<truncated for brevity>
e969f256d7ee: Pulling fs layer
874d7134a279: Download complete
failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-conta
iners.githubusercontent.com/ghcr1/blobs/sha256:7d8ab13a3c11ee7e85687a8b7392aa54aace8da2c4
db3cc414612b25d82962f6?se=2025-01-03T15%3A40%3A00Z&sig=RR7P16IZakTZT6S5o305oPD8%2BEHmsJ11
i2k2Dip0Bhs%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF
! failed to run command: exit status 1
Error: start engine: failed to pull image: failed to run command: exit status 1

I installed Dagger via WinGet. Current Dagger version is 015.1.

#

Additional context

<user>@<pc-name> ~ $ docker info
Client:
 Version:    27.4.0
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Ask Gordon - Docker Agent (Docker Inc.)
    Version:  v0.5.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.19.2-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.31.0-desktop.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.37
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Beta) (Docker Inc.)
    Version:  v0.1.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
    Path:     C:\Program Files\Docker\cli-plugins\docker-feedback.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.15.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe
#
Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 27.4.0
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 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 splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2 nvidia
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 472731909fa34bd7bc9c087e4c27943f9835f111
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.167.4-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 15.5GiB
 Name: docker-desktop
 ID: 5d7ba38b-6b2e-49f9-8809-5ef05da68cfb
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
haughty oxide
#

I'm able to use dagger fine with the WinGet install. Is your docker-desktop daemon running? I think the cli tool still works without that running

#

If you open up docker desktop, can you see this?

half ruin
#

Yep, everything seems fine!

haughty oxide
#

HMM

#

I'm on a slightly older version of docker , im going to update and see what happens

#

right now im on4.35.0

haughty oxide
#

Hey Teneko, is this a simple basic starter dagger module you are trying to create? no private dependencies or private git repo things? want to rule out anyhting that might not be related to 'windows'

#

sanity check like dagger core container from --address alpine with-exec --args echo,hello stdout should work for you. If that works, then it might be related to something else, configuration, git setup

half ruin
#

I simply bootstrapped a new git folder <repo>/ and run dagger develop inside this folder. I already tested docker itself by running docker run hello-world and docker run --rm busybox ping -c 4 google.com wich both work as expected.

Now by running dagger core container from --address alpine with-exec --args echo,hello stdout I face the exact same as outlined in my initial post.

#

Oh yes it is a private git repo actually.

#

I mean I linked the origin (git remote set-url origin) of the root repo to a private GitHub repo.

haughty oxide
#

Something to bear in mind, i dont think its your issue though, something I raised not too long ago is now documented here RE: windows + private git repos & ssh:
https://docs.dagger.io/api/remote-modules#known-limitations-and-workarounds

Dagger supports the use of HTTP and SSH protocols for accessing remote repositories as Dagger modules, compatible with all major Git hosting platforms such as GitHub, GitLab, BitBucket, Azure DevOps, Codeberg, and Sourcehut. Dagger supports authentication via both HTTPS (using Git credential managers) and SSH (using a unified authentication appr...

half ruin
#

I also make use of a trick by using a subdomain.github.com to pin point to another deploy key in context of ssh.

haughty oxide
#

oh, it may be related then

#

but, the simple example above also isnt working for you right? so i think we do have a weird thing going on

#

And for some reason, my docker desktop install hung/froze when trying to update to the same version as you

half ruin
#

my ~/.ssh/config looks something like this:

Host <synthetic-subdomain-a>.github.com
  Hostname github.com
  User git
  IdentityFile <redacted>

Host <synthetic-subdomain-b>.github.com
  Hostname github.com
  User git
  IdentityFile <redacted>

Host <synthetic-subdomain-c>.github.com
  Hostname github.com
  User git
  IdentityFile <redacted>
haughty oxide
#

Dagger (Windows) and SSH isn't supported at the moment. they need to implement an alternative

#

would you be able to try the WSL version of dagger? it's really simple to install just like winget

#

Pretty sure i had a https auth popup last week with a https dagger mod, and im not using WSL dagger tbh

half ruin
#

Oh yes sure. I just need to somehow symlink my windows user ssh folder to the wsl /root/.ssh, since I get autoamtically logged in as root when using the wsl command

half ruin
#

okay, you have given me a lot new ideas, and I will try them all out. 🙂

haughty oxide
#

if you can WSL, I always recommend having the WSL dagger installed as a backup anyway, its nice so you can check things, it's helped a lot to validate any windows related bugs or config I had in the past

half ruin
#

okay done. dagger installed on ubuntu (wsl) and wow, linked my cygwin home folder to ubuntu and everything works like a charm now:

<user>@<pc-name> /repos/<repo> (main●)$ which dagger
/home/<user>/.local/bin/dagger

also ssh in ubuntu inside my repo works just as expected..

<user>@<pc-name> /repos/<repo> (main●)$ ssh -vT git@<synthetic-subdomain-a>.github.com
... You've successfully authenticated ...

and git can pull and push too...
when restarting wsl and the docker wsl integration is not running, then dagger complains as expected: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon
once re-enabling the docker wsl integration, the exact same issue as outlined in the initial post is occuring:

...

failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-conta
iners.githubusercontent.com/ghcr1/blobs/sha256:b86ce4ea6dcba8bdf04414f7a93cd184e796eb8a4c
703f44fd90326a1e561f4f?se=2025-01-03T20%3A05%3A00Z&sig=2MWud4ONt7R3hkBBSkLr06yAjbn9PuiOE3
hX5v7JwLU%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF
#

then the problem may lye in the synthetic subdomain. 🙂

#

I am getting a bit lost. To be sure. I simply have created a private git repo on GitHub. It is still empty.. then I downloaded it and it is now present. I updated the origin remote url to have that synthetic subdomain for resolving to another deploy key referenced in my user-scoped ssh config file, since I have multiple deploy keys for the same github.com host and ssh and git seems to ignore the synthetic subdomain, for whatever reason. now dagger: I am not entirely sure how dagger is resolving the git repo.. I just want to bootstrap a NEW dagger project inside this private repo, not an existing module from the internet.

#

so I use dagger init --sdk=typescript --source=./dagger from within the root direectory of the repo.

#

resulting in the issue outlined in my initial post.

#

Unable to use Dagger in Windows or Windows WSL

haughty oxide
#

Hmm, yeah looking at the error you pasted

failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-conta
iners.githubusercontent.com/ghcr1/blobs/sha256:b86ce4ea6dcba8bdf04414f7a93cd184e796eb8a4c
703f44fd90326a1e561f4f?se=2025-01-03T20%3A05%3A00Z&sig=2MWud4ONt7R3hkBBSkLr06yAjbn9PuiOE3
hX5v7JwLU%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF
``` suggests a permission/access issue?
#

And this simple command does work? dagger core container from --address alpine with-exec --args echo,hello stdout

#

As thats not going to be connected to anything

modern lake
haughty oxide
#

certainly not a docker version issue, as i managed to upgrade and im now runing the same version as you on windows. starting to think its also your subdomain now

half ruin
#

Mhhh now I switched to the "credential.helper=manager" mechanic and eliminated the synthetic subdomain trick, but now the same issue persists

silk fern
#

According to this error seems like dagger can't execute your pipeline because it's failing to pull the engine image

#

can you try if docker pull registry.dagger.io/engine:v0.15.1 works for you?

half ruin
#
<user>@<pc-name> ~ $ docker pull registry.dagger.io/engine:v0.15.1
v0.15.1: Pulling from engine
failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:62ad11ce6b8cd06eaa8eb380d13cc4adbd0e8016be89447bde24613c45212dee?se=2025-01-04T00%3A50%3A00Z&sig=3ejIo8PzJxpMjumiO2sbnCH%2BIzWHYqCKSbPh6jZ6Jr8%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF

I really wonder.. I am not a network specialist, but I can ping registry.dagger.io, and I also can curl/wget https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:62ad11ce6b8cd06eaa8eb380d13cc4adbd0e8016be89447bde24613c45212dee?se=2025-01-04T00%3A50%3A00Z&sig=3ejIo8PzJxpMjumiO2sbnCH%2BIzWHYqCKSbPh6jZ6Jr8%3D&sp=r&spr=https&sr=b&sv=2019-12-12 from within the wsl instance, but not in cygwin:

Resolving pkg-containers.githubusercontent.com (pkg-containers.githubusercontent.com)... 2606:50c0:8000::154, 2606:50c0:8001::154, 2606:50c0:8003::154, ...
Connecting to pkg-containers.githubusercontent.com (pkg-containers.githubusercontent.com)|2606:50c0:8000::154|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

for sure a cygwin problem, but when curling the same address in a cmd terminal with the windows shipped curl, then I also can download the file just fine. Pinging `registry.dagger.io in windows also just works fine.. but wsl resolves registry.dagger.io/pkg-containers.githubusercontent.com to ipv4 and windows resolves registry.dagger.io/pkg-containers.githubusercontent.com to ipv6

half ruin
#

To reduce the friction between ipv6 and ipv4, I disabled ipv6 wsl-wide (via kernel parameter) and docker-daemon-wide (via (docker) daemon.json)

#

It still leads to the same issue when issuing docker pull registry.dagger.io/engine:v0.15.1 manually:

docker pull registry.dagger.io/engine:v0.15.1
v0.15.1: Pulling from engine
24b24fce2913: Pulling fs layer
<truncated for brevity>
5421fcb53af7: Pulling fs layer
failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:874d7134a279def99d71a73838d8074f86ba4fb9642826049ae7d9b3b50aa750?se=2025-01-04T01%3A35%3A00Z&sig=g0n23f9qzvYTp%2FWco1kB%2F9aBYpqD6YGAK38WXFCCLGg%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF
silk fern
half ruin
#

yes the docker pull in general works, when pulling for example busybox or hello-world also ping and nslookup of the busybox image work as intended, but as you can see, pulling some layers of registry.dagger.io/engine:v0.15.1 work until it breaks

#

I tinkering with hello-dagger repository, cloned it to my tenekon (github) org and I try to login via dagger login, but I get the following result:

$ dagger login
You are a member of multiple organizations. Please select one with `dagger login <org>`:

- teneko
- teneko

should the tenekon org not be listed and how I would ever be able to select the second teneko entry? :c

#

If alternatively trying to login via docker login registry.dagger.io, then I do not know what credentials it would expect.

#

To be honest, I cannot grasp the flow anymore that dagger follows to achieve what it wants to achieve in conjunction with docker login (required?), dagger login, GitHub GHCR (related to dagger login?), Dagger Cloud (I think optional?) and gh auth login (I think optional?). I really miss a mental model.

silk fern
#

It's weird since I can pull the image without issues

half ruin
#

I already tried switching the underlying WSL distro from Ubuntu to the self-shipped Docker Desktop distro, disabling BuildKit, enabling the host network, disabling IPv6, or reinstalling docker. Also google is outputting so many weird solutions. Most are related to proxy. But I do not have a proxy. The only proxy I can see is when printing docker info:

 <truncated for brevity>
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 <truncated for brevity>
silk fern
half ruin
#

When using

docker pull ghcr.io/infrastructure-as-code/hello-world
docker run --name hello-world --publish 8000:8080 ghcr.io/infrastructure-as-code/hello-world
curl localhost:8000

it happily prints:

Hello, World!%
silk fern
#

through ghcr

half ruin
#

no it doesn't work, same issue. let me just recheck..

docker pull ghcr.io/dagger/engine:v0.15.1
v0.15.1: Pulling from dagger/engine
failed to copy: httpReadSeeker: failed open: failed to do request: Get "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:62ad11ce6b8cd06eaa8eb380d13cc4adbd0e8016be89447bde24613c45212dee?se=2025-01-04T04%3A05%3A00Z&sig=Fd80%2BzkhBmm3Z7t5n2HGBQA5N6Z%2FSbziTY6%2BNv%2Fc3rE%3D&sp=r&spr=https&sr=b&sv=2019-12-12": EOF
silk fern
#

any chance you have a VPN to try?

#

maybe your ISP is doing something funky?

#

first time I've seen this kind of issue

#

tbh

half ruin
#

maybe cloudflare is doing something funky?

silk fern
#

can you try pulling the v0.15.0 version?

#

instead of v0.15.1?

half ruin
#

tried alredy earlier versions, but let me try

#

same

silk fern
#

🤷‍♂️ this is definitely strange..

#

do you have a VPN to try?

half ruin
#

sadly not

#

I will change my dns server

#

using cloudflare on windows level

silk fern
#

what do you get with curl "https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:62ad11ce6b8cd06eaa8eb380d13cc4adbd0e8016be89447bde24613c45212dee?se=2025-01-04T04%3A05%3A00Z&sig=Fd80%2BzkhBmm3Z7t5n2HGBQA5N6Z%2FSbziTY6%2BNv%2Fc3rE%3D&sp=r&spr=https&sr=b&sv=2019-12-12". EOF?

#

^ that curl works for me

half ruin
#

I tried that already and everything just passed, let me recheck

silk fern
#

ok..definitely strange

#

try pulling several times? Maybe eventually it'll succeed?

#

could be some networking issue from your ISP to ghcr

half ruin
#
C:\Users\<user>>curl "https://pkg-containers.githubusercontent.com"
curl: (35) Recv failure: Connection was reset

C:\Users\<user>>curl "https://pkg-containers.githubusercontent.com"
curl: (35) Recv failure: Connection was reset

C:\Users\<user>>curl "https://pkg-containers.githubusercontent.com"
<?xml version="1.0" encoding="utf-8"?><Error><Code>InvalidQueryParameterValue</Code><Message>Value for one of the query parameters specified in the request URI is invalid.
RequestId:72eff636-701e-0069-405d-5e8281000000
Time:2025-01-04T04:05:45.9621151Z</Message><QueryParameterName>comp</QueryParameterName><QueryParameterValue /><Reason /></Error>
C:\Users\<user>>
#

you do not have by chance another image registry/provider?

silk fern
#

so if you download it and re-tag it, that should work

half ruin
silk fern
#

interesting.. they have a mirror of ghcr?

half ruin
#

download succeeded ^^'

silk fern
#

🎉

half ruin
silk fern
#

so now you need to re-tag your image

#

so the engine can use it and doesn't try to download it

#

@half ruin are you in China by any chance?

half ruin
#

Yes, makes sense. I just will do that.

#

No.. I digged deep into the deep sea of google..

silk fern
#

lol

#

what ISP do you have if you mind me asking?

half ruin
#

I am from Germany. We are very open.. We love democracy and such..

#

I think..? 😄

silk fern
half ruin
#

one sec

#
$ nslookup registry.dagger.io
Server:  one.one.one.one
Address:  2606:4700:4700::1111

Nicht autorisierende Antwort:
Name:    registry.dagger.io
Addresses:  2a09:8280:1::a:cf02
          66.241.125.89
silk fern
half ruin
#
docker image tag ghcr.nju.edu.cn/dagger/engine:v0.15.1 registry.dagger.io/engine:v0.15.1

done

silk fern
#

since the org doesn't exist multiple times in our system for sure

silk fern
half ruin
#

🙂

silk fern
#

you can try with dagger core version

half ruin
#
$ dagger core version
✔ connect 3.2s
✔ loading type definitions 0.4s
✔ parsing command line arguments 0.0s

✔ version: String! 0.0s
                                                                                                 v0.15.1

Full trace at https://dagger.cloud/teneko/traces/<redacted>
silk fern
#

🚀 you're good to go

half ruin
#

thanks for your tips and hints. 🙂

silk fern
#

sure! anytime

half ruin
#

I tried tried traceroute and a two online traceroute providers and those who are in the eu (including me) seem stopping at ISP or data center (Hetzner) and are not getting through. It also seems that githubusercontent.com is more prevalant to this issue according to google.

#

The domain pkg-containers.githubusercontent.com has four DNS records, each pointing to an IP address linked to data storage. My guess is, some of these addresses were used for illegal activities due to malicious users. However, IP addresses have been partially blocked by the EU, likely to mitigate illegal activities such as malware distribution and bot infrastructure.