[Libguestfs] nbdkit build failure in Koji

[Eric Blake]

On 7/31/20 7:07 AM, Richard W.M. Jones wrote:
> Hi Eric,
> 
> I wonder if you have any thoughts about this build failure in
> tests/test-nozero.sh?
> 
>    https://koji.fedoraproject.org/koji/taskinfo?taskID=48259627
>    log: https://kojipkgs.fedoraproject.org//work/tasks/9762/48259762/build.log
> 
> The error is “nozero6.img was trimmed by mistake”.  I added “set -x”
> to the script earlier today so we can see exactly what's wrong, and it
> is that:
> 
>    ++ stat -c %b nozero2.img
>    ++ stat -c %b nozero6.img
>    + test 4096 '!=' 2048
>    + echo 'nozero6.img was trimmed by mistake'

Hmm, maybe it is file-system dependent (not all filesystems reserve the 
same amount of space for a sparse file - that's something that qemu 
iotests keep on hitting).

> 
> AFAICT what this means is that nozero2.img is growing during the test
> (from 2048 to 4096 blocks).  When I run the test locally this file
> stays at 2048 blocks the whole time, and the test does not fail.

Growing a small amount but still being sparse is different from growing 
a huge amount to be non-sparse altogether.  I'll have to double-check 
what the test is actually doing (the size of the files involved) and see 
if we can relax the test into allowing a range of sizes that show a file 
is still reasonably sparse.  But knowing what filesystem koji is using 
may matter (for example, if this is something that shows up on btrfs but 
not ext4, that would explain why koji fails when I pass locally...)

> 
> One other unfortunate problem is that Fedora is having lots of
> toolchain problems right now (see Fedora devel list passim) so we
> cannot really be sure that *any* other tool we are using has been
> built correctly :-(  I've already disabled LTO in qemu and libguestfs,
> but possibly there are other toolchain bugs.
> 
> Rich.
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org