So I was talking this over with rwmj in IRC today. At first we thought the dnf update was working successfully, but after he left I realized it isn't, it's dying apparently silently halfway through.

To reproduce, run this on an F23 or F24 system (I've reproduced on two different boxes, one with F23, one with F24):

LIBGUESTFS_BACKEND=direct virt-builder fedora-23 -o disk_f23_minimal_x86_64.img --arch x86_64 --no-delete-on-failure --run-command "dnf -y -v --best update"

It will get to the dnf command step and then error out with "virt-builder: error: dnf -y -v --best update: command exited with an error"

In the log dnf reaches the end of the Cleanup phase:

  Cleanup     : libgcc-5.1.1-4.fc23.x86_64                              285/285
1039 blocks
No '/dev/log' or 'logger' included for syslog logging
No '/dev/log' or 'logger' included for syslog logging
virt-builder: error: dnf update -y --best -v: command exited with an error

so it kinda looks like it was done, but in fact there should be the Verify stage after that. If you mount the image with virt-rescue and poke about, you can see that in /var/log/dnf.log , the transaction gets to "DDEBUG RPM transaction start." but never reaches "DDEBUG RPM transaction over." as it should. So it seems pretty clear that the dnf run just crashes or aborts silently for some reason.

I can't reproduce this by doing a clean install of F23 minimal from the Server DVD, booting it, and running 'dnf -y -v --best update', which is why I'm filing against guestfs for now.

I am now playing Package Bingo, changing the dnf command to update various different package sets in the hopes I'll stumble across the one that triggers the error...I've tried excluding dracut, kernel, dracut and kernel, and dnf from the transaction, none of those helped.

This is a big problem for openQA as we can't refresh our base test disk images.