cockpit
cockpit copied to clipboard
Provide cockpit/ws image for arm64
Hi, I am using Fedora IoT on 64 bit ARM (aarch64). The cockpit packages in dnf are available on aarch64, but it would be nice if the container images also were built for this. Currently x86_64 is the only architecture available for cockpit-ws at Docker Hub.
Docker hub has support for multiple architectures in the same repo, see https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/ Example of a multi arch repo: https://hub.docker.com/_/influxdb?tab=tags&page=1&ordering=last_updated
I managed to build 64 bit ARM (aarch64) images based on the Dockerfile etc provided by this repository. But I had to do some modifications:
- remove the
cockpit-previewrepo as it doesn't seem to have anaarch64variant - add
updates-testingrepos as they have recent cockpit-ws and cockpit-bridge packages foraarch64
The changes are here: https://github.com/svenfoo/cockpit-container/tree/aarch64
With these changes I can build a podman image of cockpit-ws and run it on a Raspberry Pi 4. However I assume that these changes won't work for other platforms, that's why I haven't made a pull request.
I enabled aarch64 in the cockpit-preview COPR repo, thanks for pointing out!
Just to make sure, @svenfoo 's changes should not be necessary any more since March 30, our cockpit-preview copr has had arm64 builds since then. I'm not sure yet how to build arm64 on quay.io though, I haven't found any instructions or settings for that.
Right, I reverted the changes in my copy and have been able to build images for the Raspberry Pi recently.
Since I keep running into this issue when googling my own issue: https://github.com/danielvandenberg95/cockpit-ws/pkgs/container/cockpit-ws cockpit-ws in docker on debian.
We are going to remove this cockpit-container repository (it was never really meant to be an user-facing one), so transferring to cockpit.
@martinpitt I've noticed the recent changes in the workflows for the quay.io cockpit/ws container. Are there any plans on making this a "proper" alternative installation approach or is the container simply used for testing purposes?
No, that container is an official product which we support. Github does not have ARM runners. quay.io container builds are back -- but not sure if they support ARM somehow, I don't find any architecture selection in the build trigger config.
I've just opened #17935 that should solve this issue. There are a few open topics I added to the PR, hence the draft status.
I'd appreciate any guidance on some of the topics there, especially about the Docker/podman compatibility that might not be necessary. I'm pretty sure the solution isn't the best as of now, but it'll get there. 🙂