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

[Martin Pitt]

Hello Simon,

Simon McVittie [2016-10-26 18:40 +0100]:
> > Would you be okay with putting [eofcat] 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.
> 
> That's fine

OK, I pushed this, it passes the tests and works fine with
tests/testpkg-reboot:

  https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=962350c16

> if /tmp mounted noexec is explicitly a non-goal.

I wouldn't call it a declared on-goal, but right now exec /tmp is an
assumption -- it's the weakest one that autopkgtest can make across
all supported backends. There are targets where you don't have
root/sudo privileges, or AppArmor/SELinux restricted ones where you
might not be able to do mounts (e. g. unprivileged containers).

I. e. as long as autopkgtest itself writes scripts to /tmp, we can
also do that in virt-qemu.

> I had initially made /run/autopkgtest be the shared filesystem mount
> point, but I think I prefer using /run/autopkgtest/shared, so that we
> have the option of populating the rest of /run/autopkgtest/ with an
> executable tmpfs (as in my currently proposed patches) if noexec
> /tmp becomes a desired thing to support.

Indeed, sounds good!

> > 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.
> 
> Unfortunately that doesn't work with autopkgtest -U (or other interesting
> setup commands), because the upgrade-before-testing causes a reboot, and
> there doesn't seem to be a hook point to run setup commands after each
> reboot; so installing the test dependencies fails. (One of my tests also
> does some reboots internally.)

Ah, bummer.

> Is a --per-boot-setup-commands something you'd consider?

I guess it's either that, or a more specific option to remount root
r/w at every boot; TBH I'm not too fond of the latter, as it's a bit
too specific. --setup-commands-boot sounds more universal/flexible to
me.

I won't get to that today and I'm on a sprint next week, but I figure
I might be able to hack on that while travelling on Sunday. If you
want to beat me to it, be my guest of course ☺

Thanks!

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