Docker engine and Docker CLI on riscv64


I was looking for a way to run a current version of Docker on my VisionFive board. As there are no pre-built packages yet (compared to Podman, which is already available via package manager) I’d need to build it from source.
Luckily I stumbled across build instructions dated last year but they are more or less still up to date:

I’ve been using a Lubuntu 21.10 image which is discussed in another thread: Lubuntu 21.10 image for Starfive VisionFive V1

As the flashed image only has a 10gb root partition I had to resize it otherwise I’d have ended in a no space left error.

Package-wise I’ve only installed the following:

sudo apt install build-essential cmake pkg-config libseccomp2 libseccomp-dev libdevmapper-dev golang libbtrfs-dev

Not quite sure which Go version is required as a minimum. Likely 16. I’ve used 17 and had no issues.

Steps to build all the necessary binaries, engine and CLI version 20.10.13 (don’t forget to set GOPATH first!):

mkdir -p $HOME/riscv-docker
cd $HOME/riscv-docker

git clone
pushd runc
sudo make install

git clone
pushd containerd
make BUILDTAGS="no_btrfs"
sudo make install

mkdir -p $GOPATH/src/
pushd $GOPATH/src/
git clone
pushd cli
git checkout v20.10.13
sudo cp build/docker-linux-riscv64 /usr/local/bin
sudo ln -sf /usr/local/bin/docker-linux-riscv64 /usr/local/bin/docker

git clone
pushd tini
cmake . && make
sudo cp tini-static /usr/local/bin/docker-init

mkdir -p $GOPATH/src/
pushd $GOPATH/src/
git clone
pushd libnetwork
go get
GO111MODULE=off go build ./cmd/proxy
sudo cp proxy /usr/local/bin/docker-proxy

mkdir -p $GOPATH/src/
pushd $GOPATH/src/
git clone
pushd rootlesskit
sudo make install

mkdir -p $GOPATH/src/
pushd $GOPATH/src/
git clone docker
pushd docker
git checkout v20.10.13
sudo cp contrib/ /usr/local/bin
VERSION=20.10.13 DISABLE_WARN_OUTSIDE_CONTAINER=1 GO111MODULE=off GOOS=linux GOARCH=riscv64 ./hack/ binary
sudo cp bundles/binary-daemon/dockerd-20.10.13 /usr/local/bin/dockerd

Took about an hour or more to compile all binaries. Systemd service files can be created as originally stated in the linked how-to.
One of the lasts steps would be to create a docker group, otherwise one of the systemd services did not start.

If nothing went wrong you’re greeted with this:

$ docker version
 Version:           20.10.13
 API version:       1.41
 Go version:        go1.17
 Git commit:        a224086349
 Built:             Sun Mar 20 18:35:08 2022
 OS/Arch:           linux/riscv64
 Context:           default
 Experimental:      true

  Version:          20.10.13
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17
  Git commit:       906f57ff5b
  Built:            Sun Mar 20 18:13:55 2022
  OS/Arch:          linux/riscv64
  Experimental:     false
  Version:          v1.6.0-117-ged1a76270
  GitCommit:        ed1a762707cea5055dec47ed4b049159ac9f23a3
  Version:          1.1.0+dev
  GitCommit:        v1.1.0-92-g98b75bef
  Version:          0.19.0
  GitCommit:        378bbbc
1 Like

I understand the want to use Docker but many distributions come with systemd and thus a built-in container engine aka systemd-nspawn. Considering how many images you’ll find on Docker Hub working for anything but x86_64, you may as well use a native solution (no static blob built by Go even) should you find the need to torture yourself. :stuck_out_tongue:

A quick rundown on how things work:

1 Like

You can use the following project which will make docker images for other archs work inside RISC-V:

I will test it today inshallah

That will emulate the platform the image was made for, this means you’ll have to accept slow TCG by Qemu which is usually running at a fraction of the speed of a similarly clocked native-CPU/core.

Forking is also incredibly slow in user-mode via binfmt, since it’ll have to fork an entire Qemu each time. Imagine a autoconf configure script, nuts when each bash call takes >2s.

It’ll work but it’s hardly a solution for everyone.

There is clearly always another approach also on how to get things done :smiley: In my use case I just wanted to check out the current status of Docker specifically and also to incorporate it into my zoo of different architectures I’m currently running.

But thanks for highlighting systemd-nspawn, looks quite interesting though :+1:

NVM, You already said that