I am looking for arch container archive files like "Fedora-Container-Base-30-1.2.aarch64.tar.xz " for Fedora 30. I found the x86_64, aarch64 and s390x's archive files in below directory. But where is the archive file of armv7hl, i686 and ppc64le? I assume the multi archs except x86_64, aarch64 and s390x existed in the age of Fedora 24, 25 in below releases directory.
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ x86_64/ images/ Fedora-Container-Base-30-1.2.x86_64.tar.xz Fedora-Container-Minimal-Base-30-1.2.x86_64.tar.xz aarch64/ images/ Fedora-Container-Base-30-1.2.aarch64.tar.xz Fedora-Container-Minimal-Base-30-1.2.aarch64.tar.xz https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x/ images/ Fedora-Container-Minimal-Base-30-1.2.s390x.tar.xz => No Fedora-Container-Base-*.tar.xz
Thanks.
I change my question. Do you know who is creating this kind of multi arch container images? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/...
Jun
I found Fedora 30 armhfp container image here. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ I am still looking for Fedora 30 armv7hl, i686 and ppc64le container images.
On 5/6/19 4:58 AM, Jun Aruga wrote:
I am looking for arch container archive files like "Fedora-Container-Base-30-1.2.aarch64.tar.xz " for Fedora 30 I found the x86_64, aarch64 and s390x's archive files in below directory. But where is the archive file of armv7hl, i686 and ppc64le? I assume the multi archs except x86_64, aarch64 and s390x existed in the age of Fedora 24, 25 in below releases directory.
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
Those are things that failed in the final RC2 compose of Fedora30.
Since they were not release blocking, they... didn't block the release.
...snip...
I change my question. Do you know who is creating this kind of multi arch container images? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/...
Those were all made by the Fedora 30 rc2 compose.
pungi is the tool, and this: https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf was the config used.
Does that answer the question?
kevin
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
Those are things that failed in the final RC2 compose of Fedora30.
Since they were not release blocking, they... didn't block the release.
...snip...
I change my question. Do you know who is creating this kind of multi arch container images? https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/aarch64/...
Those were all made by the Fedora 30 rc2 compose.
pungi is the tool, and this: https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf was the config used.
Does that answer the question?
Yes, Kevin. Thank you for the info. What I do not understand is below DockerHub has Feodra 30 ppc64le, Fedora 29 armhfp that Fedora Project did not release.
https://hub.docker.com/r/ppc64le/fedora/ Fedora 29, 30 https://hub.docker.com/r/arm32v7/fedora/ Fedora 29 (not 30)
Anyway, as what I wanted is layer.tar in the image archive, maybe I will take it from DockerHub's image like this.
$ docker pull arm32v7/fedora:29 $ docker save arm32v7/fedora:29 -o 29-armhfp.tar $ tar -xf 29-armhfp.tar $ ls -l */layer.tar -rw-r--r-- 1 jaruga jaruga 256970240 Feb 20 14:00 88edf58c1d5b3ee606b724b19ac4b4866b20ba93d15d5b330fc6cc29055b480b/layer.tar
Thanks. Solved.
pungi is the tool, and this: https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf was the config used.
Kevin, I have a question.
https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_322
'arches': ['armhfp', 'aarch64', 'ppc64le', 's390x', 'x86_64'],
From above setting for Container, ideally those 5 archs should be released on URL [a] or [b]? Where is ppc64le's image?
"'distro': 'Fedora-22', " in https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_320 is right setting?
a. https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ aarch64, x86_64 b. https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x c. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ aarch64, armhfp, x86_64
On 5/6/19 11:57 AM, Jun Aruga wrote:
Yes, Kevin. Thank you for the info. What I do not understand is below DockerHub has Feodra 30 ppc64le, Fedora 29 armhfp that Fedora Project did not release.
https://hub.docker.com/r/ppc64le/fedora/ Fedora 29, 30 https://hub.docker.com/r/arm32v7/fedora/ Fedora 29 (not 30)
updating images in docker hub requires a human to file a pull request with the exact image that needs to be pulled. It's not automated at all. For a long time also, docker hub didn't do anything except x86_64.
So, likely we haven't had a armv7 fedora 30 compose recently, and so no one has updated it. The container sig would be the ones to ask here.
Kevin, I have a question.
https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_322
'arches': ['armhfp', 'aarch64', 'ppc64le', 's390x', 'x86_64'],
From above setting for Container, ideally those 5 archs should be released on URL [a] or [b]?
Yes. :)
The primary arches will be at a, the alternative arches will be at b.
Where is ppc64le's image?
Thats an alternative arch, so it would be at b (fedora-secondary). (If it composed with the final release)
"'distro': 'Fedora-22', " in https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_320 is right setting?
Yes. This is a koji setting thats passed to 'oz' for the images. Before Fedora 22 we used yum, after Fedora 22 dnf was used.
a. https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ aarch64, x86_64 b. https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x c. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ aarch64, armhfp, x86_64
c is for when a release is in development (ie, before final release).
kevin
On Tue, 7 May 2019 at 23:46, Kevin Fenzi kevin@scrye.com wrote:
On 5/6/19 11:57 AM, Jun Aruga wrote:
Yes, Kevin. Thank you for the info. What I do not understand is below DockerHub has Feodra 30 ppc64le, Fedora 29 armhfp that Fedora Project did not release.
https://hub.docker.com/r/ppc64le/fedora/ Fedora 29, 30 https://hub.docker.com/r/arm32v7/fedora/ Fedora 29 (not 30)
updating images in docker hub requires a human to file a pull request with the exact image that needs to be pulled. It's not automated at all. For a long time also, docker hub didn't do anything except x86_64.
So, likely we haven't had a armv7 fedora 30 compose recently, and so no one has updated it. The container sig would be the ones to ask here.
Yes I do the Dockerhub updates, and since we did not have a full compose working in a while I did my best to at least get something out for fedora 30.
The problem we have with the compose is tracked in this ticket --> https://pagure.io/releng/issue/8173
Kevin, I have a question.
https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_322
'arches': ['armhfp', 'aarch64', 'ppc64le', 's390x', 'x86_64'],
From above setting for Container, ideally those 5 archs should be released on URL [a] or [b]?
Yes. :)
The primary arches will be at a, the alternative arches will be at b.
Where is ppc64le's image?
Thats an alternative arch, so it would be at b (fedora-secondary). (If it composed with the final release)
"'distro': 'Fedora-22', " in https://pagure.io/pungi-fedora/blob/f30/f/fedora-final.conf#_320 is right setting?
Yes. This is a koji setting thats passed to 'oz' for the images. Before Fedora 22 we used yum, after Fedora 22 dnf was used.
a. https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Container/ aarch64, x86_64 b. https://dl.fedoraproject.org/pub/fedora-secondary/releases/30/Container/ s390x c. https://dl.fedoraproject.org/pub/fedora/linux/development/30/Container/ aarch64, armhfp, x86_64
c is for when a release is in development (ie, before final release).
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Kevin and Clement, thanks for the explanation.
I am looking forward to seeing the final compose.
So, likely we haven't had a armv7 fedora 30 compose recently, and so no
one has updated it. The container sig would be the ones to ask here.
Sure, I will subscribe the mailing list.
Yes I do the Dockerhub updates, and since we did not have a full
compose working in a while I did my best to at least get something out for fedora 30.
Thank you for your work! I appreciate it.
The problem we have with the compose is tracked in this ticket -->
https://pagure.io/releng/issue/8173
Sure, I will subscribe it.
By the way, let me tell you why I want the mult arch Container. I am working for multiarch project now [1].
As you may know, when we build or run different arch container (ex. aarch64) on the host arch (ex. x86_64), we can not do it.
``` $ docker run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:207: exec user process caused "no such file or directory" ```
But below commands should work on your x86_64 host OS. As it is not officially released on the multiarch project, it is still my private container repository.
$ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m aarch64 $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-s390x uname -m s390x
This technology enables you to debug your app on the multi arch environment on local easily or add the environment to your x86_64 base CI. If you are interested in how it works, see [2] and [3].
[1] multiarch project: https://github.com/multiarch [2] https://github.com/multiarch/qemu-user-static [3] https://github.com/multiarch/fedora
On Thu, May 9, 2019 at 10:22 AM Jun Aruga jaruga@redhat.com wrote:
Kevin and Clement, thanks for the explanation.
I am looking forward to seeing the final compose.
So, likely we haven't had a armv7 fedora 30 compose recently, and so no
one has updated it. The container sig would be the ones to ask here.
Sure, I will subscribe the mailing list.
Yes I do the Dockerhub updates, and since we did not have a full
compose working in a while I did my best to at least get something out for fedora 30.
Thank you for your work! I appreciate it.
The problem we have with the compose is tracked in this ticket -->
https://pagure.io/releng/issue/8173
Sure, I will subscribe it.
By the way, let me tell you why I want the mult arch Container. I am working for multiarch project now [1].
As you may know, when we build or run different arch container (ex. aarch64) on the host arch (ex. x86_64), we can not do it.
$ docker run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:207: exec user process caused "no such file or directory"
you should just run $ docker run --rm -t fedora:30 uname -m on all arches, we push manifest listed containers to dockerhub so that command will work everywhere.
Dennis
But below commands should work on your x86_64 host OS. As it is not officially released on the multiarch project, it is still my private container repository.
$ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m aarch64 $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-s390x uname -m s390x
This technology enables you to debug your app on the multi arch environment on local easily or add the environment to your x86_64 base CI. If you are interested in how it works, see [2] and [3].
[1] multiarch project: https://github.com/multiarch [2] https://github.com/multiarch/qemu-user-static [3] https://github.com/multiarch/fedora
-- Jun Aruga / He - His - Him jaruga@redhat.com / IRC: jaruga _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
$ docker run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:207: exec user process caused "no such file or directory"you should just run $ docker run --rm -t fedora:30 uname -m on all arches, we push manifest listed containers to dockerhub so that command will work everywhere.
Alright, I did not know the kind of alias feature. Thanks for the info.
you should just run $ docker run --rm -t fedora:30 uname -m on all arches, we push manifest listed containers to dockerhub so that command will work everywhere.
Alright, I did not know the kind of alias feature. Thanks for the info.
But my motivation is not like * Running x86_64 container on x86_64 machine * Running aarch64 container on aarch64 machine ...
but * Running aarch64, s390x, ppc64le and etc containers on x86_64 machine.
The reason is that makes multi arch's tests enable on x86_64 environment or x86_64 base CI service.
I am suggesting a new feature "podman buildx" like "docker buildx" that makes a better multi arch build experience. See below URL if you are interested in it.
Supporting building multi-platform images (podman buildx) https://github.com/containers/buildah/issues/1590
On 5/19/19 9:11 AM, Jun Aruga wrote:
I am suggesting a new feature "podman buildx" like "docker buildx" that makes a better multi arch build experience. See below URL if you are interested in it.
Supporting building multi-platform images (podman buildx) https://github.com/containers/buildah/issues/1590
I think this is something that the community would have to address, I don't see it as a huge priority for the core developers at this point.
$ docker run --rm -t arm64v8/fedora:30 uname -m
standard_init_linux.go:207: exec user process caused "no such file or directory"
$ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m aarch64
Recently our multiarch project released a new feature to enable to run a standard multi-architecture containers on x86_64, without multiarch/* container that was needed before, not depending on host OS environment.
That means below workflow works
``` $ uname -m x86_64
$ docker run --rm -t arm64v8/ubuntu uname -m standard_init_linux.go:211: exec user process caused "exec format error"
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -t arm64v8/fedora:30 uname -m aarch64 ```
Is it fine to advertise my talk at Flock 2019 this Friday here? :)
Title: Let's add Fedora multiarch containers to your CI. https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-...
* When: Friday August 9, 2019 10:30 - 10:55 * Where: the room Panorama (140m² / 40 people), The Danubius Hotel HELIA in Budapest, Hungary, at Flock Budapest 2019
= Table of contents = (it might be changed a little bit later) * Fedora and Upstream - Past and Present * CPU Architecture Kinds * Tools for multiarch - Today's topics * QEMU and binfmt_misc - on News * 5 steps - to add Fedora multiarch to upstream CI * 1. qemu-$arch-static - An interpreter * 2. binfmt_misc - A kernel feature for binary format * 3. qemu-user-static RPM on Fedora * 4. qemu-user-static RPM and container * 5. multiarch/qemu-user-static image and CI * Note A: ARM supported CI services * Note B: A Dockerfile to multi-arch images docker buildx, docker/(podman) build --platform
Please come!
On 8/6/19 7:56 AM, Jun Aruga wrote:
$ docker run --rm -t arm64v8/fedora:30 uname -mstandard_init_linux.go:207: exec user process caused "no such file or directory"
$ docker run --rm --privileged multiarch/qemu-user-static:register --reset $ docker run --rm -t quay.io/junaruga/multiarch-fedora:30-aarch64 uname -m aarch64
Recently our multiarch project released a new feature to enable to run a standard multi-architecture containers on x86_64, without multiarch/* container that was needed before, not depending on host OS environment.
That means below workflow works
$ uname -m x86_64 $ docker run --rm -t arm64v8/ubuntu uname -m standard_init_linux.go:211: exec user process caused "exec format error" $ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes $ docker run --rm -t arm64v8/fedora:30 uname -m aarch64Is it fine to advertise my talk at Flock 2019 this Friday here? :)
Title: Let's add Fedora multiarch containers to your CI. https://flock2019.sched.com/event/SJLx/lets-add-fedora-multiarch-containers-...
- When: Friday August 9, 2019 10:30 - 10:55
- Where: the room Panorama (140m² / 40 people), The Danubius Hotel
HELIA in Budapest, Hungary, at Flock Budapest 2019
= Table of contents = (it might be changed a little bit later)
- Fedora and Upstream - Past and Present
- CPU Architecture Kinds
- Tools for multiarch - Today's topics
- QEMU and binfmt_misc - on News
- 5 steps - to add Fedora multiarch to upstream CI
- qemu-$arch-static - An interpreter
- binfmt_misc - A kernel feature for binary format
- qemu-user-static RPM on Fedora
- qemu-user-static RPM and container
- multiarch/qemu-user-static image and CI
- Note A: ARM supported CI services
- Note B: A Dockerfile to multi-arch images docker buildx, docker/(podman) build --platform
Please come!
Would love to see your examples use podman...
Please come!
Would love to see your examples use podman...
Sorry here is the podman's example. And no worry. podman's examples are used as much as possible in my talk!
``` $ uname -m x86_64
$ podman run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:211: exec user process caused "exec format error"
$ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ podman run --rm -t arm64v8/fedora:30 uname -m aarch64 ```
On 8/6/19 9:15 AM, Jun Aruga wrote:
Please come!
Would love to see your examples use podman...
Sorry here is the podman's example. And no worry. podman's examples are used as much as possible in my talk!
$ uname -m x86_64 $ podman run --rm -t arm64v8/fedora:30 uname -m standard_init_linux.go:211: exec user process caused "exec format error" $ sudo podman run --rm --privileged multiarch/qemu-user-static --reset -p yes $ podman run --rm -t arm64v8/fedora:30 uname -m aarch64
Nice.