Bug#842091: autopkgtest-virt-qemu: better support for read-only rootfs
mpitt at debian.org
Thu Oct 27 14:48:36 UTC 2016
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
> 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.)
> 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
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 ☺
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
More information about the autopkgtest-devel