Currently rpm-ostree will fail with rawhide if the host is using BTRFS. There will likely be similar issues with mock. Since http://cgit.freedesktop.org/systemd/systemd/commit/?id=fed2b07ebc9e8694b5b326923356028f464381ce and http://cgit.freedesktop.org/systemd/systemd/commit/?id=814f000872fc2d254250831607bdca9b27e5705e and because we run systemd-tmpfiles --create in `%post`, we end up creating a subvolume in the temporary chroot. We really only want to do subvolumes if we're doing a non-chroot install. This is quite similar to https://bugzilla.redhat.com/show_bug.cgi?id=1197204 in that I think we need to somehow pass down to systemd-tmpfiles whether or not we're doing a chroot install. Possibly RPM has an environment variable for this? Then we could do something like: %post systemd-tmpfiles --create ${RPM_IS_CHROOTED:+--chroot} /dev/null 2>&1 || : ? Or maybe even simpler, have systemd-tmpfiles detect whether it's in a chroot.
(The actual problem that breaks rpm-ostree is it tries to clean up its chroot afterwards and a normal recursive removal fails with a read-only subvolume /var/tmp/chroot/var/lib/machines)
Mock has already been patched to deal with this, see https://bugzilla.redhat.com/show_bug.cgi?id=1205564.
Also, see my original post regarding tmpfiles to the systemd-devel: http://lists.freedesktop.org/archives/systemd-devel/2015-April/030036.html
Cleaning them up afterwards helps but they should not be created in the first place.
I followed upon the thread http://lists.freedesktop.org/archives/systemd-devel/2015-May/032140.html
Well, I simply disagree. Either prohibit them in your build environment (using seccomp), or learn to clean them up.
Is there any chance that the /var/lib/machines sub vol only be created when it is actually used? For me it is just a useless unused annoyance. I don't know how other people feel about the machines they admin, but my attitude to btrfs sub vols is similar to real-on-disk-filesystems - I want to be in control of these, and having some OS package attempting to enforce its ideas about these on everyone, is quite unwelcome.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Quite some time ago tmpfiles has been changed to create new subvols only if the root dir is a subvol too. THis should fix your issue.