Hi everyone, I'm working at Scaleway on the multiarch images system, I'm @moul on IRC and talked with @Arrfab and @Evolution (thanks a lot, guys). --- Context: Today, we are using Docker as a build-step to generate our baremetal servers rootfs, what we call, the "Scaleway images". Here is an example of "1 click app" image: - Public Hub: https://hub.scaleway.com/wordpress.html - DevHub (aggregate APIs): http://devhub.scaleway.com/#/images/wordpress:latest - Source (GitHub): https://github.com/scaleway-community/scaleway-wordpress/ - Docker Hub: https://hub.docker.com/r/scaleway/wordpress/ - Build logs: https://travis-ci.org/scaleway/qa/builds/98515979 We are quite happy today with this method and are succesfully running plenty Linux distributions (Ubuntu, openSUSE, Gentoo, Fedora, Debian, Arch Linux and Alpine Linux). Actually we also have a proof-of-concept of CentOS image, but based on an old development CubieTruck snapshot with no public mirrors. Here is how I built this POC image (I wasn't aware of virt-tar-out): https://github.com/armbuild/centos-img/blob/master/buildcontainers.sh --- We will soon release new server models with new architectures, our next priorities are: `arm64` and `x86_64`, but we plan to support more architectures if we feel enough people will need it so the development worth it. I started to work on "multiarch" images (one image per architecture). Here are some images: - https://github.com/multiarch/alpine -> built with `apk-static` in a chroot - https://github.com/multiarch/busybox -> static binaries extracted from latest busybox-static.deb - https://github.com/multiarch/ubuntu-debootstrap -> qemu-debootstrap - https://github.com/multiarch/debian-debootstrap -> same as above - https://github.com/multiarch/ubuntu-core -> based on released rootfs tarballs at https://partner-images.canonical.com/core/wily/current/ All those images also contains an `x86_64` `qemu-${ARCH}-static` so you can run them on an `x86_64` host with `binfmt-support` available. Look at the README.md files for usage and examples. I began to work on the Centos image https://github.com/multiarch/centos, I successfully built the `armhf` and `arm64` images by `virt-tar-out`ing the CubieTruck released image, i.e.: http://mirror.centos.org/altarch/7.2.1511/isos/armhfp/ I also successfully built the `x86_64` and `i386` images using kickstart: livemedia-creator --arch=i386 --make-disk \ --iso=/tmp/boot7-i386.iso \ --ks=$(pwd)/centos-7.ks \ --image-name=centos-7-base-i386 based on https://github.com/CentOS/sig-cloud-instance-build/tree/livemedia_builds/docker For now I failed to build the `ppc64` nor `ppc64le` images, but that's not a priority. I have now an issue, my `armhf` and `x86_64` images are not the same, the ones based on real boards .img.xz embed about 300M of kernel images, dtb, kernel modules, firmware (I don't want them) + a lot more apps that we can find by default in the <200Mb `x86_64` Docker image. I would like to find a solution to build "same" images for all the targets and avoid as much as possible the need of diffing the outputs of `yum list installed`. My favorite solution would be to use kickstart files, which are very cool to put on GitHub. But the non `x86_64` architectures lack of a `boot.iso` file packing `isolinux`. Is it possible to add those `boot.iso` files on the mirror or tell me how to build them ? Do you see alternative ways to build identical images ? -- Manfred Touron - @moul CTO @ scaleway.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160114/bda3bf89/attachment-0007.sig>