(Subscribing to the bug report, but feel free to keep me in Cc anyway.) On 10/30/2016 04:52 PM, Martin Pitt wrote: > Or perhaps there is some way how the base image could be a bit > obfuscated/hidden from the kernel/udev? (I can't think of any which > are cheap and not an utter/unrelibale hack).
Well, one could do the following before attaching the base image (pseudo-code, untested): if [ -e /lib/udev/rules.d/64-btrfs.rules ] ; then echo 'KERNEL=="vd*", ENV{ID_SERIAL}=="BASEIMAGE", goto="btrfs_skip_baseimage"' > /etc/udev/rules.d/64-btrfs.rules cat /lib/udev/rules.d/64-btrfs.rules >> /etc/udev/rules.d/64-btrfs.rules echo 'LABEL="btrfs_skip_baseimage"' >> /etc/udev/rules.d/64-btrfs.rules fi That would hopefully solve the problem for btrfs at least. It's a real shame that udev's last_rule is gone... (But I probably said that in the initial bug report as well.) >> For least-astonishment, the default should perhaps be to *not* provide >> the base image as a block device (and tests that need to exercise >> nested virtualization can specifically ask for it), but that would be >> a behaviour change so I haven't done it in the attached patch. > > I don't think this is widely used yet -- I think Christian's > open-iscsi tests are probably the only ones. As far as I know that's the case. > I never saw an "official" > Debian/Ubuntu autopkgtest fail due to that, and this feature is > limited to the QEMU runner, which isn't being used on Debian's and > Ubuntu's testing infrastructure. Yes - though I'd really like to see QEMU tests integrated in the future in DebCI (haven't had time to bring it up though) but only run them for all isolation-machine tests. > In other words, I think that providing an option for this and default > to off might be safer and not actually break compatibility > unacceptably hard. IIRC Christian's original patches back then even > did provide this as an option, I just didn't see a reason for it back > then as it's negligible overhead to provide. > > Christian, what's your opinion on this? Well, regardless of whether this is going to be made optional, the main problem here is that it doesn't work with btrfs. Let's think a couple of years into the future, and perhaps btrfs is the default filesystem by then. In that case, even autopkgtest images will be created with btrfs by default - and then I wouldn't be able to test open-iscsi with it. What I really don't want to do is to have to create a special image for open-iscsi. I use the autopkgtest QEMU image on my system for testing all sorts of packages, open-iscsi being only one of them. Also, just because I'm the only one that's implemented nested tests so far doesn't mean they are that special. I think they could be _very_ useful for the testing of early-boot stuff in a lot of packages. And while I initially did indeed suggest it as an optional feature, after my long discussions with Martin I've come to think that having this on by default is the better solution. I'd also be open to investigating whether we could export the image via a custom 9p filesystem handler (that will just be a single directory with a single file in it). As Debian/Ubuntu kernels support 9p out of the box, this should work - writing the 9p handler on the outside of the virtualization is going to be a bit more difficult, but should be doable. I'd be willing to work on that. That way, we don't have to deal with udev / block devices / this kind of automatic magic at all. We could then do the following: - I test the above hack with the udev rules to work around the immediate problem so that Simon can use btrfs-based adt images. A new version of autopkgtest is uploaded with that change. - This bug is kept open until I can come up with an implementation that doesn't use QEMU disk drives anymore but a custom 9p fs handler. That way, we will never run into the same kind of problem again in the future and bypass all udev/kernel etc. logic. Performance would likely suffer a tiny bit, but not too badly I hope. Would that be agreeable to both of you? Regards, Christian