Bug#842091: autopkgtest-virt-qemu: better support for read-only rootfs
smcv at debian.org
Wed Oct 26 17:40:25 UTC 2016
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
> 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 :-)
More information about the autopkgtest-devel