Bug#842091: autopkgtest-virt-qemu: better support for read-only rootfs

[mpitt@debian.org (Martin Pitt)]

Hello Simon,

Simon McVittie [2016-10-25 21:15 +0100]:

> Subject: [PATCH 1/6] VirtSubproc: open arbitrary files in binary mode
> Subject: [PATCH 2/6] VirtSubproc: if check_exec status is nonzero, include
> Subject: [PATCH 3/6] qemu: put the shared directory in /run

These are straightforward, applied to git.

> Subject: [PATCH 4/6] virt-qemu: re-create eofcat on every boot

Looks okay, but depends on and should thus be merged into patch 5.
(See below)

> Subject: [PATCH 5/6] qemu: put eofcat in an executable tmpfs on
>  /run/autopkgtest
> 
> This avoids having to write it to /bin, which might be read-only.

Good catch!

> -    term.send(b'''mkdir -p -m 1777 /run/autopkgtest/shared
> +    term.send(b'''mkdir -p /run/autopkgtest
> +mount -t tmpfs run-autopkgtest /run/autopkgtest
> +mkdir -p -m 1777 /run/autopkgtest/shared
>  mount -t 9p -o trans=virtio,access=any autopkgtest /run/autopkgtest/shared
>  chmod 1777 /run/autopkgtest/shared
>  touch /run/autopkgtest/shared/done_shared
> @@ -240,7 +242,7 @@ touch /run/autopkgtest/shared/done_shared
>      # arg), or an "exit flag" file exists.
>      # We don't run that from /run/autopkgtest/shared as 9p from older QEMU
>      # versions is buggy and causes "invalid numeric result" errors on that.
> -    term.send(b'''PYTHON=$(which python3) || PYTHON=$(which python); cat <<EOF > /bin/eofcat; chmod 755 /bin/eofcat
> +    term.send(b'''PYTHON=$(which python3) || PYTHON=$(which python); cat <<EOF > /run/autopkgtest/eofcat; chmod 755 /run/autopkgtest/eofcat

Would you be okay with putting this into /tmp instead? We wouldn't
need another mount for this, and autopkgtest itself is already relying
on /tmp/ carrying executable scripts as it puts autopkgtest-reboot
(and friends) there.

I can do this myself, just want to get your confirmation.

> Subject: [PATCH 6/6] testbed: mount / rw before invoking dpkg/apt
> 
> This assumes we can "apt-get update" without remounting (in other words,
> /var is always rw), but might need to remount the root read/write
> before proceeding.

I don't want to apply this as-is. We use autopkgtest to test stuff on
real read-only testbeds (like Ubuntu Touch or snappy), and autopkgtest
has a fallback mode of extracting test dependencies into /tmp and
setting PATH, LD_LIBRARY_PATH, PYTHONPATH etc. to it. (This of course
does not work with arbitrary test dependencies.). We currently use the
ssh runner for this mostly, but with your fixes it becomes possible to
use QEMU too.

Unconditionally remounting stuff r/w would be both unepxected and
intrusive for these cases, and also not really respect that one would
actually try to achieve with a r/o testbed: ensure that nothing
actually changes it, to not disrupt image-based installs/upgrades.

So for those cases where you want to explicitly "undermine" the r/o
file system, I would rather recommend to add

  --setup-commands 'mount -o remount,rw /'

to the autopkgtest command line, to keep this explicit. For the case
of "only run apt-get update with r/w root fs" there is a canned script
already (--setup-commands ro-apt-update), but this doesn't apply to
your case.

Would that be appropriate to you? I guess so as your patch never
actually sets it back to r/o (which is also often not possible due to
the fs being busy).

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)