Closed lstellway closed 1 month ago
Additional notes ...
I came across this script from the qemu/qemu repo (via this article) for setting up QEMU. The script has an option specific to setting up QEMU on Debian (Ubuntu is based on Debian).
When executing this script within the container environment, I need to additionally install an extra package: binfmt-support
. Afterwards, I can successfully mount QEMU with the --debian
option.
Sample workflow step:
- name: Set up QEMU
run: |
sudo apt-get update
sudo apt-get install -y binfmt-support
curl -L -o /tmp/qemu.sh 'https://raw.githubusercontent.com/qemu/qemu/master/scripts/qemu-binfmt-conf.sh'
chmod +x /tmp/qemu.sh
/tmp/qemu.sh --debian
With this, my /usr/share/binfmts/
directory is populated with the following:
But the only platforms available to Docker buildx
are:
linux/amd64,linux/amd64/v2,linux/amd64/v3,linux/386
As documented in multiarch/qemu-user-static, this script can also be run via Docker:
docker run --rm --privileged multiarch/qemu-user-static:register [--reset][--help][options]
My Gitea-runner host is in an Alpine linux container _(gitea/act_runner:0.2.6-dind-rootless
)_.
When I run this with no options:
docker run --rm --privileged multiarch/qemu-user-static:register
I get the error:
mount: permission denied (are you root?)
When I run it with the --debian
flag:
docker run --rm --privileged multiarch/qemu-user-static:register --debian
I get the same error with a warning (source reference):
mount: permission denied (are you root?) WARNING: your system is not a Debian based distro
Also found an issue in the action's repository that looks related: docker/setup-qemu-action#67
You are trying to run a root action in rootless daemon. No idea how to help.
Hello,
I'm currently using Gitea with the Gitea act runner. I have the following labels configured to run jobs:
When trying to use the docker/setup-qemu-action@v3 action to prepare the environment for cross-platform builds, I get the following error:
Anybody else have this issue? Any ideas how to get the mount working?
I'm thinking it maybe has something to do with the Docker daemon running outside of this container's filesystem and not having permissions to write to the mount path..?
Here is a sample of my workflow: