Bug 1659450 - /tmp/ is not getting mounted in RHV-M appliance image during boot
Summary: /tmp/ is not getting mounted in RHV-M appliance image during boot
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.3.0
: ---
Assignee: Yuval Turgeman
QA Contact: Jan Zmeskal
URL:
Whiteboard:
Depends On:
Blocks: 1541529 1663810
TreeView+ depends on / blocked
 
Reported: 2018-12-14 12:21 UTC by nijin ashok
Modified: 2022-03-13 16:44 UTC (History)
4 users (show)

Fixed In Version: 4.3.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1663810 (view as bug list)
Environment:
Last Closed: 2019-05-08 12:39:27 UTC
oVirt Team: Integration
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-45234 0 None None None 2022-03-13 16:44:50 UTC
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:19:02 UTC
Red Hat Product Errata RHBA-2019:1088 0 None None None 2019-05-08 12:39:40 UTC

Description nijin ashok 2018-12-14 12:21:50 UTC
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.

Comment 6 errata-xmlrpc 2019-05-08 12:39:27 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:1088


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