Closed BunkerMelon closed 1 year ago
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:
Finally, remember to use https://discuss.ipfs.io if you just need general support.
This probably has something to do with how we build and deploy to dockerhub (https://github.com/ipfs/go-ipfs/blob/480defab689610550ee3d346e31441a2bb881fcb/.circleci/config.yml#L308-L340). We probably need some extra logic to get this to work cross-architecture.
Unfortunately, this is not something the go-ipfs team is likely to have time to tackle in the near future. However, if you have some spare time and want to try to get cross building working on CircleCI, it looks like https://www.docker.com/blog/multi-arch-build-what-about-circleci/ is a good place to start.
Ah okay, that makes sense. Thank you for the confrimation. If I do get some spare time, I will look deeper into the cross building issue.
Totally understandable that this isn't a top priority, just thought I would bring it to the teams attention if they weren't aware. If I come up with any solutions for this, I will surely return back with a solution.
Yeah, thanks for bringing this up.
Also an issue if you want to run ipfs-go in docker on a Raspberry currently. The build from the docker file works flawlessly though. But it would be nice to be able to refer to a single image from the docker-compose file to support amd64 and arm64
the provided docker compose still fails on raspberry pi 4 with pulled images, but still works on images built from source. linuxserver has been maintaining a multi-platform-aware ipfs image for awhile that, at a glance, appears to be go-ipfs in alpine. https://github.com/linuxserver/docker-ipfs Why not do what they do?
Could someone build a Raspberry Pi version of go-ipfs, upload it to Docker Hub, and post a link to this thread?
It looks like #4931 has some links to Docker images on Docker Hub.
I was able to get this Docker container to run go-ipfs v11 on a Raspberry Pi 4:
I build my own as well to run on my rpi4, would be nice if they would build an ARM build. I wish I knew how to change their builds to fix it, but no clue unfortunately,
We did add ARMv7 and ARM64 builds recently, but they are not running for tagged releases, which is a bug, so I just opened https://github.com/ipfs/go-ipfs/issues/8829. But you can see them on the master branch builds here: https://hub.docker.com/r/ipfs/go-ipfs/tags .
Sorry not a bug, it just hasn't been included in a release yet. It should be in v0.13. Once v0.13.0-rc1 is released, we should auto-publish an ARM docker image...it'd be really helpful if you try those out on your devices and let us know if it works.
Fixed in https://github.com/ipfs/kubo/pull/10021, will ship when final Kubo 0.22.0 is released.
Version Info Golang version: 1.14 IPFS Version: Latest, Docker container Architecture: aarch64/Cortex-A53 Operating System: Ubuntu 20.05.4
Description Wanted to test running IPFS docker image on my Pine64 SBC. Went over to dockerhub and found the go-ipfs image Went ahead and pulled this image; "docker pull ipfs/go-ipfs".
This downloaded and extracted fine, but when doing a test run with "docker run -d --name ipfs_host -v $ipfs_staging:/export -v $ipfs_data:/data/ipfs -p 4001:4001 -p 127.0.0.1:8080:8080 -p 127.0.0.1:5001:5001 ipfs/go-ipfs:latest" I get the container hash that the container started, but when checking logs "docker logs -f ipfs_host" I recieve exec user process caused "exec format error" similair to the problem encountered here #7422
When running docker ps -a I can see the container was exited as soon as it was started.
I was able to solve this problem by cloning the repo and building the image myself (no changes to the Dockerfile) and re-running the docker run command listed above. I have a spare Rock64 where I can reproduce this for testing.