RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1243494 - Masking tmp.mount with an entry for /tmp in fstab leads to a ro root fs
Summary: Masking tmp.mount with an entry for /tmp in fstab leads to a ro root fs
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-15 15:03 UTC by Ryan Barry
Modified: 2016-01-11 15:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-03 13:33:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2074783 0 None None None Never

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?
Note You need to log in before you can comment on or make changes to this bug.