-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(qemu_static_image): add qemu_static_image option #104
base: master
Are you sure you want to change the base?
Conversation
@@ -20,7 +20,8 @@ The action also accepts some optional input parameters: | |||
* `dockerRunArgs`: Additional arguments to pass to `docker run`, such as volume mappings. See [`docker run` documentation](https://docs.docker.com/engine/reference/commandline/run). | |||
* `setup`: Shell commands to execute on the host before running the container, such as creating directories for volume mappings. | |||
* `install`: Shell commands to execute in the container as part of `docker build`, such as installing dependencies. This speeds up subsequent builds if `githubToken` is also used, but note that the image layer will be publicly available in your projects GitHub Package Registry, so make sure the resulting image does not have any secrets cached in logs or state. | |||
* `base_image`: Specify a custom base image, such as [busybox](https://hub.docker.com/_/busybox), `arch` and `distro` should be set to `none` in this case. This will allow you to chose direcly the image that will be used in the *FROM* clause of the internal docker container without needing to create a Dockerfile.arch.distro for a specific arch/distro pair. For more detials, see [PR #103](https://github.com/uraimo/run-on-arch-action/pull/103#issuecomment-1363810049). Known limitation: Only one base_image configuration for each workflow if you use GitHub images caching. | |||
* `base_image`: Specify a custom base image, such as [busybox](https://hub.docker.com/_/busybox), `arch` and `distro` should be set to `none` in this case. This will allow you to chose direcly the image that will be used in the *FROM* clause of the internal docker container without needing to create a Dockerfile.arch.distro for a specific arch/distro pair. For more details, see [PR #103](https://github.com/uraimo/run-on-arch-action/pull/103#issuecomment-1363810049). Known limitation: Only one base_image configuration for each workflow if you use GitHub images caching. | |||
* `qemu_static_image`: Specify a custom image for registering QEMU emulators. If not set, **multiarch/qemu-user-static** will be used by default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that work with aptman/qus (https://dbhi.github.io/qus/) ?
AFAIK QUS is also still on QEMU 7.1 but I wonder how generic this new setting is - does it support any qemu-user-static provider or just forks of multiarch/qemu-user-static.
One thing I like better in QUS is that it works on other platforms too, e.g. you can emulate x86_64 on aarch64 machine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now, I have tested with my own fork of multiarch/qemu-user-static, which can be used from longhronshens/qemu-user-static:latest. This fork has been updated to use qemu 7.2. As for aptman/qus, this is more complicated than what run-on-arch-action does. That is not very good for simple cases. This is why I'd rather to use run-on-arch-action.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for emulating x86_64 on aarch64 machine, I think my fork can also be used like that, since I have pushed qemu-user-static:latest with multiple architectures. But since uraimo/run-on-arch-action can only be used on GitHub Action runner which runs on x86_64 by default, multi-arch support is somewhat meaningless.
sudo apt-get update -q -y | ||
sudo apt-get -qq install -y qemu qemu-user-static | ||
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes --credential yes | ||
docker run --rm --privileged $QEMU_STATIC_CONTAINER --reset -p yes --credential yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this answers my earlier question. It won't work with QUS because it uses different options' names (https://dbhi.github.io/qus/tests.html)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, currently I think we can only use multiarch/qemu-user-static compatible images.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good
By default, we use multiarch/qemu-user-static for non-x86 containers. The offical multiarch/qemu-user-static has been stuck at QEMU 7.1 for a while, and I have found a bug of QEMU 7.1 that has been fixed in QEMU 7.2. So I built a fork of multiarch/qemu-user-static with QEMU 7.2. The next thing is, adding a custom qemu_static_image option to use it.
By the way, it is not necessary to install any qemu apt package outside of the container, since the qemu-user-static binaries has been included in the multiarch/qemu-user-static image.