Bug 1223467

Summary:	Suppress subvolume creation from tmpfiles when doing installroots
Product:	[Fedora] Fedora	Reporter:	Colin Walters <walters>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	johannbg, jsynacek, lnykryn, msekleta, s, suckfish, systemd-maint, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-02-10 14:19:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Colin Walters 2015-05-20 15:03:11 UTC

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.

Comment 1 Colin Walters 2015-05-20 15:03:56 UTC

(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)

Comment 2 Jan Synacek 2015-05-21 06:54:22 UTC

Mock has already been patched to deal with this, see https://bugzilla.redhat.com/show_bug.cgi?id=1205564.

Comment 3 Jan Synacek 2015-05-21 06:56:48 UTC

Also, see my original post regarding tmpfiles to the systemd-devel:
http://lists.freedesktop.org/archives/systemd-devel/2015-April/030036.html

Comment 4 Colin Walters 2015-05-21 14:47:56 UTC

Cleaning them up afterwards helps but they should not be created in the first place.

Comment 5 Colin Walters 2015-05-21 15:19:54 UTC

I followed upon the thread http://lists.freedesktop.org/archives/systemd-devel/2015-May/032140.html

Comment 6 Lennart Poettering 2015-05-21 20:46:31 UTC

Well, I simply disagree.

Either prohibit them in your build environment (using seccomp), or learn to clean them up.

Comment 7 Ralph Loader 2015-06-06 22:07:25 UTC

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.

Comment 8 Jan Kurik 2015-07-15 14:07:45 UTC

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

Comment 9 Lennart Poettering 2016-02-10 14:19:18 UTC

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.