Bug 1243494

Summary:	Masking tmp.mount with an entry for /tmp in fstab leads to a ro root fs
Product:	Red Hat Enterprise Linux 7	Reporter:	Ryan Barry <rbarry>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED WORKSFORME	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	fdeutsch, jraju, lnykryn, rbarry, systemd-maint-list
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-12-03 13:33:05 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 Ryan Barry 2015-07-15 15:03:38 UTC

Description of problem:
If tmp.mount is masked (as it is in all the cloud images, to block tmp on tmpfs by default) and an entry is added to fstab for /tmp (ext4, tmpfs, and bind mount have all been tested), the system will come back up with / readonly when rebooted 

Version-Release number of selected component (if applicable):
systemd-208-20.el7_1.2.x86_64

How reproducible:
100%

Steps to Reproduce:
1. systemctl mask tmp.mount
2. Add "tmpfs /tmp none defaults 0 0" to fstab 
3. Reboot

Actual results:
/ is readonly

Expected results:
/ is rw, and /tmp is mounted to match fstab

Additional info:

Comment 2 Lukáš Nykrýn 2015-07-16 09:32:52 UTC

tmp.mount is not ebnabled by default on rhel so it does not make any sence to mask it

If you mask it than you have also masked the line in fstab, because systemd is not reading fstab directly, there is a generator which rewrites its content to mount units 

http://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html


And this seems to work on rhel-7.2 systemd

Comment 3 Ryan Barry 2015-07-16 14:47:13 UTC

Whether or not tmp.mount is enabled by default in RHEL is not the point of the bug here. We do mask tmp.mount since that better matches the Fedora images (where it is enabled), but I filed a bug because masking tmp.mount (as the unit which mounts tmpfs on tmp should not lead to a ro root fs with an entry in fstab.

We can change the component to Fedora if you wish, but there's a disconnect between recommending masking tmp.mount to disable tmpfs-on-tmp and coming up with a ro rootfs. 

While the Fedora feature page indicates in the small print that this will disable mounting *any* filesystem on tmp, it does not indicate that leaving an entry for /tmp in fstab with tmp.mount masked will result in a ro rootfs on reboot, and I cannot imagine that it's intended behavior.

Whether or not tmp.mount is enabled on RHEL on Fedora, masking tmp.mount ON RHEL and putting an entry for /tmp in fstab will result in a ro root fs. And, as far as I'm aware, we are not closing bugs just because it doesn't make sense to do something. I'm happy to move this to Fedora or somewhere else (on the same BZ), but it is fixed in the current release.

The question is "why does masking tmp.mount with an entry for /tmp in fstab lead to a ro root fs"? That should not happen. It should spit a warning/error out in the journal about how it's ignoring the mountpoint for /tmp or similar.

Comment 4 Lukáš Nykrýn 2015-07-17 06:58:33 UTC

I have closed the bug because this seems to be fixed in 7.2.

[root@localhost ~]# systemctl mask tmp.mount
[root@localhost ~]# echo "tmpfs /tmp tmpfs defaults 0 0" >> /etc/fstab 
[root@localhost ~]# reboot
.
.
.
[root@localhost ~]# mount | grep root
/dev/mapper/rhel-root on / type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
[root@localhost ~]# rpm -q systemd
systemd-219-3.el7.x86_64

Can you reproduce it with some 7.2 version of systemd?