Skip to content

Conversation

@QuantumEntangledAndy
Copy link
Collaborator

@QuantumEntangledAndy QuantumEntangledAndy commented Sep 21, 2020

In issue #73 we had a request for a docker image sutable for a raspberry pi (armhf architecture).

I looked into getting such an image to work on github actions. The solution was to build the docker with xbuild and qemu.

I went to the trouble of creating a multiarch build that supports all architectures that rust supports.

  • amd64
  • i386
  • arm64
  • armhf

It works in two stages:

  • BUILD which runs on the host arch and cross compiles neolink (p.s. are there any archs that we should build for in the CI?)
  • Publish which runs on the target arch using qemu which copies over neolink from the build machine.

I could not do this on alpine as that is amd64 only, so it is on debian buster. What I did was publish two tags

  • :branchname which is the multiarch debian build
  • :branchname-alpine which is the amd64 only alpine build

closes #73

@thirtythreeforty
Copy link
Owner

Thanks for looking at this.

It works in two stages:

  • BUILD which runs on the host arch and cross compiles neolink (p.s. are there any archs that we should build for in the CI?)
  • Publish which runs on the target arch using qemu which copies over neolink from the build machine.

I appreciate the attempt to use buildx; I think I would like to try to let someone else handle abstracting away the various platforms. I am concerned that the build/publish workflow might be tricky to maintain.

I did some looking into the bug you hit; seems it's something others are starting to hit. The root cause is based on a bad interaction with the Qemu 32-bit guest API and the host 64-bit ext4 kernel driver, which uses 64-bit inode numbers.

The workaround seems to be creating a small filesystem for Cargo's Git repo, which will prevent the host from using 64-bit inodes.

I think this should be possible to integrate with buildx, or with an Actions plugin like run-on-arch-action. What do you think?

@QuantumEntangledAndy
Copy link
Collaborator Author

I would certainly like to not have to cross compile too if possible. I will try the tmpfs route

mkdir ~/.cargo
mount -t tmpfs -o size=2048m tmpfs ~/.cargo

Then see how it goes

Using buildkit to mount inside docker build
Put back in missing AS name

Debugging the issue with docker...

Explicit cargo path

Attempt setting exec on tmpfs

Avoid execfs issues

Just use the setup path env

Typo fix in docker build

More debuging of the docker build

Just amd64 and arm7

Explicitly set cacert path

Add arm v8

Add arm v6

Remove armv6
@QuantumEntangledAndy
Copy link
Collaborator Author

I have gotten it to build via tmpfs so the cross compile isn't needed anymore.
It supports the following

  • amd64
  • armhf
  • arm64

Does not support

  • armv6 (rasp pi 1)

We could probable do this all in alpine as pointed out in #84 which would make the armv6 maybe possible

@QuantumEntangledAndy
Copy link
Collaborator Author

QuantumEntangledAndy commented Oct 17, 2020

@thirtythreeforty Probably ready for review when you have the time

@QuantumEntangledAndy
Copy link
Collaborator Author

With no progress on my PRs in years I am closing them in favour of working on my own fork. If your interested in these features please see there

@QuantumEntangledAndy QuantumEntangledAndy deleted the rpi-docker branch March 1, 2023 07:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Raspberry Pi support for the docker image

2 participants