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

[Simon McVittie]

On Wed, 26 Oct 2016 at 17:39:45 +0200, Martin Pitt wrote:
> > 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.

Hmm. I thought I'd structured it so that 4 can safely be applied before
5 at the cost of doing a small amount of unnecessary work to overwrite
eofcat with an identical eofcat after each reboot (but not vice versa,
because putting eofcat in the tmpfs won't work unless you re-create it
every time); but if I failed to do that, merging them is fine.

> 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, if /tmp mounted noexec is explicitly a non-goal. I know
some sysadmins do this on their servers as a hardening thing, and it
wouldn't be inconceivable for embedded devices to do the same; but as
it happens, ours doesn't.

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.

> 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.

OK, noted. We're pretty much treating this as a necessary evil for the
moment: longer term we too would like to use an image-based approach,
but until our tests stop needing to parachute in extra system-wide
dependencies, we have to go behind the production system's back and
undermine the point of having a read-only filesystem for the sake of
test coverage.

> 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?

> 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).

Indeed. I hear rumours that it might occasionally be possible to remount
a rw filesystem ro, but I don't think I've ever actually seen it done
successfully by anything less intrusive than magic sysrq + U :-)

    S