Bug#842299: autopkgtest-virt-qemu: attaching base image makes btrfs very confused
Package: autopkgtest
Version: 4.1
Severity: normal
Tags: patch
btrfs gets *really* confused if you attach multiple copies of the
same filesystem, because it tracks filesystems by UUID, not by
device node (part of its built-in RAID-equivalent):
<https://btrfs.wiki.kernel.org/index.php/Gotchas#Block-level_copies_of_devices>
In my experiments with a btrfs-based virtual machine, /proc/self/mounts
etc. thought the mounted partitions and subvolumes all came from
/dev/vdb, even though they clearly weren't because only /dev/vda could
have been mounted read/write.
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.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages autopkgtest depends on:
ii apt-utils 1.3.1
ii libdpkg-perl 1.18.10
ii procps 2:3.3.12-2
ii python3 3.5.1-4
ii python3-debian 0.1.29
Versions of packages autopkgtest recommends:
ii autodep8 0.8
Versions of packages autopkgtest suggests:
pn lxc <none>
pn lxd-client <none>
ii qemu-system 1:2.7+dfsg-1
ii qemu-utils 1:2.7+dfsg-1
ii schroot 1.6.10-2+b1
-- no debconf information
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-autopkgtest-virt-qemu-add-no-attach-base-image-optio.patch
Type: text/x-diff
Size: 4056 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20161027/15c582d0/attachment.patch>
Reply to: