On 11/07/2016 12:08, Alex Bennée wrote: > > Paolo Bonzini <pbonz...@redhat.com> writes: > >> On 11/07/2016 05:20, Fam Zheng wrote: >>> This allows a docker file to say "ENV QEMU_CHROOT /path/to/new/root" to >>> indicate that the test execution should be done in a chroot in the >>> container. >>> >>> Bind mount dev,sys,proc into QEMU_CHROOT to make them avaiable for >>> testing scripts. >>> >>> The SYS_ADMIN is a required capability for mount, add it to the >>> docker run command line. >>> >>> Signed-off-by: Fam Zheng <f...@redhat.com> >>> --- >>> tests/docker/Makefile.include | 1 + >>> tests/docker/run | 12 ++++++++++++ >>> 2 files changed, 13 insertions(+) >>> >>> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include >>> index c5546ee..e9821ba 100644 >>> --- a/tests/docker/Makefile.include >>> +++ b/tests/docker/Makefile.include >>> @@ -107,6 +107,7 @@ docker-run-%: docker-qemu-src >>> $(call quiet-command,\ >>> $(SRC_PATH)/tests/docker/docker.py run $(if $V,,--rm) \ >>> -t \ >>> + --cap-add SYS_ADMIN \ >>> $(if $(DEBUG),-i,--net=none) \ >>> -e TARGET_LIST=$(TARGET_LIST) \ >>> -e EXTRA_CONFIGURE_OPTS=$(EXTRA_CONFIGURE_OPTS) >>> \ >>> diff --git a/tests/docker/run b/tests/docker/run >>> index 38ce789..4e80cc3 100755 >>> --- a/tests/docker/run >>> +++ b/tests/docker/run >>> @@ -19,6 +19,18 @@ fi >>> >>> BASE="$(dirname $(realpath $0))" >>> >>> +# cp files into the chroot and execute there >>> +if test -n "$QEMU_CHROOT"; then >>> + mkdir -p $QEMU_CHROOT/$BASE >>> + cp $BASE/* $QEMU_CHROOT/$BASE >>> + QEMU_CHROOT_SAVE="$QEMU_CHROOT" >>> + for bp in dev sys proc; do >>> + mount --bind /$bp $QEMU_CHROOT/$bp >> >> Can you ask docker to do these bind mounts instead? > > AFAICT docker's various mount directives are all focused on tasks like > mounting data > volumes from the host into the container. > > It's a bit of a shame having to do this as the original approach was to > use docker to avoid having fancy bind mounts on my hosts system. We are > now getting to inception levels of nesting here. But the benefit is not > requiring the host having the pre-requisites to bootstrap the system. > > That said looking at the debootstrap requirements I've seen instructions > that start with download the deb, ar extract and then run the script by > hand so maybe this is over complicating things? > > Is it possible to bootstrap a Fedora rootfs with a similar script?
In theory "yum" is all that you need to bootstrap a Fedora rootfs. Paolo