Bug 1663810 - [downstream clone - 4.2.8] /tmp/ is not getting mounted in RHV-M appliance image during boot
Summary: [downstream clone - 4.2.8] /tmp/ is not getting mounted in RHV-M appliance im...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhvm-appliance
Version: 4.2.7
Hardware: All
OS: Linux
high
high
Target Milestone: ovirt-4.2.8
: ---
Assignee: Yuval Turgeman
QA Contact: Pavel Novotny
URL:
Whiteboard:
Depends On: 1659450
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-07 07:02 UTC by RHV bug bot
Modified: 2022-03-13 16:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: tmp.mount is masked during build Consequence: /tmp is not mounted in the appliance Fix: Remove the masking of tmp Result: /tmp is mounted as expected
Clone Of: 1659450
Environment:
Last Closed: 2019-01-22 12:45:35 UTC
oVirt Team: Integration
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3820162 0 None None /tmp is not getting mounted in RHV-M appliance image during boot 2019-03-08 04:18:15 UTC
Red Hat Product Errata RHBA-2019:0129 0 None None None 2019-01-22 12:45:37 UTC

Description RHV bug bot 2019-01-07 07:02:51 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1659450 +++
======================================================================

Description of problem:

In the RHV-M appliance image, the /tmp/ is not getting mounted during booting.

===
[root@localhost ~]# systemctl status tmp.mount
● tmp.mount
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)
Warning: tmp.mount changed on disk. Run 'systemctl daemon-reload' to reload units.


[root@localhost ~]# mount|grep -i tmp
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=450188k,nr_inodes=112547,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=94732k,mode=700)

[root@localhost ~]# grep tmp /etc/fstab 
/dev/mapper/ovirt-tmp   /tmp                    xfs     nodev,noexec,nosuid 0 0
===

I can manually mount it using "mount -a" command. 

If I unmask and reboot the server, it mounts without any issues.

===
systemctl status tmp.mount
● tmp.mount - /tmp
   Loaded: loaded (/etc/fstab; disabled; vendor preset: disabled)
   Active: active (mounted) since Fri 2018-12-14 06:42:07 EST; 34min ago
    Where: /tmp
     What: /dev/mapper/ovirt-tmp
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)
  Process: 594 ExecMount=/bin/mount /dev/mapper/ovirt-tmp /tmp -t xfs -o nodev,noexec,nosuid (code=exited, status=0/SUCCESS)

Dec 14 06:42:06 localhost systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
Dec 14 06:42:06 localhost systemd[1]: Mounting /tmp...
Dec 14 06:42:07 localhost systemd[1]: Mounted /tmp.

mount|grep -i ovirt-tmp
/dev/mapper/ovirt-tmp on /tmp type xfs (rw,nosuid,nodev,noexec,relatime,seclabel,attr2,inode64,noquota)

I can see similar discussion about AMI images here https://bugzilla.redhat.com/show_bug.cgi?id=1408572#c10 where the solution was to unmask the tmp.mount.

Version-Release number of selected component (if applicable):

Tested with rhvm-appliance-4.2-20180828.0.el7.ova

How reproducible:

100%

Steps to Reproduce:

Boot the OVA rhvm appliance and check if /tmp is getting mounted.

Actual results:

/tmp is not getting mounted during boot.

Expected results:

/tmp should get mounted.

Additional info:

I am not sure if this is a bug with systemd or "tmp.umount" should be always unamsked for the /tmp/ to get mounted even if it's defined in fstab.

(Originally by Nijin Ashok)

Comment 6 Eli Marcus 2019-01-10 14:03:01 UTC
    If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field.

     

    The documentation team will review, edit, and approve the text.

     

    If this bug does not require doc text, please set the 'requires_doc_text' flag to -.


By the way - I see a comment in https://bugzilla.redhat.com/show_bug.cgi?id=1408572#c10 
that says this is a configuration issue and not a bug:
"This is a configuration issue and not a bug in systemd. We should talk to people building those AMIs and advice them to stop masking tmp.mount. In the meantime please unmask the unit manually in your provisioning scripts."

Maybe this comment can be added to the advisory summary?

Comment 7 Pavel Novotny 2019-01-15 13:13:02 UTC
Verified in rhvm-appliance-4.2-20190108.0.el7

/tmp is now mounted during the Appliance boot.


# mount | grep '/tmp'
/dev/mapper/ovirt-tmp on /tmp type xfs (rw,nosuid,nodev,noexec,relatime,seclabel,attr2,inode64,noquota)
# systemctl status tmp.mount
● tmp.mount - /tmp
   Loaded: loaded (/etc/fstab; disabled; vendor preset: disabled)
   Active: active (mounted) since Út 2019-01-15 08:04:27 EST; 3min 25s ago
    Where: /tmp
     What: /dev/mapper/ovirt-tmp
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)

Comment 9 errata-xmlrpc 2019-01-22 12:45:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0129


Note You need to log in before you can comment on or make changes to this bug.