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