Control: tag -1 pending
Hello Christian,
Christian Seiler [2016-10-31 17:35 +0100]:
> I believe there might be a race condition here: autopkgtest-virt-qemu
> sends udevadm control --reload to the container, but doesn't wait for
> the prompt to reappear, before attaching the device itself. Adding
On 10/30/2016 09:45 PM, Christian Seiler wrote:
> On 10/30/2016 09:40 PM, Martin Pitt wrote:
>> Christian Seiler [2016-10-30 21:12 +0100]:
>>> Well, it's not actually SYSTEMD_READY, the "btrfs ready" builtin is
>>> actually the culprit.
>>
>>> So one needs to make sure the btrfs ready builtin is
On 10/30/2016 09:40 PM, Martin Pitt wrote:
> Christian Seiler [2016-10-30 21:12 +0100]:
>> Well, it's not actually SYSTEMD_READY, the "btrfs ready" builtin is
>> actually the culprit.
>
>> So one needs to make sure the btrfs ready builtin is never executed
>> for the corresponding devices. Which
Christian Seiler [2016-10-30 21:12 +0100]:
> Well, it's not actually SYSTEMD_READY, the "btrfs ready" builtin is
> actually the culprit.
> So one needs to make sure the btrfs ready builtin is never executed
> for the corresponding devices. Which is why I did the LABEL/goto
> logic in my example.
On 10/30/2016 09:25 PM, Martin Pitt wrote:
> Christian Seiler [2016-10-30 20:04 +0100]:
>> Also, just because I'm the only one that's implemented nested tests
>> so far
>
> BTW, you are probably be the only one who uses the nested base image
> -- but I've seen several tests that use nested QEMU.
Christian Seiler [2016-10-30 20:04 +0100]:
> Also, just because I'm the only one that's implemented nested tests
> so far
BTW, you are probably be the only one who uses the nested base image
-- but I've seen several tests that use nested QEMU. Just that they
usually download a current cloud image
On 10/30/2016 09:01 PM, Martin Pitt wrote:
> Hello Christian,
>
> Christian Seiler [2016-10-30 20:04 +0100]:
>> 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*",
Hello Christian,
Christian Seiler [2016-10-30 20:04 +0100]:
> 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"' >
(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).
Hello Simon,
adding Christian to the recipients as the author of the "supply base
image" feature of QEMU and leaving fullquote for his convenience.
Simon McVittie [2016-10-27 21:15 +0100]:
> btrfs gets *really* confused if you attach multiple copies of the
> same filesystem, because it tracks
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):
11 matches
Mail list logo
