Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1038241

Summary: crud in /mnt/sysimage after install, presumably from user creation
Product: Red Hat Enterprise Linux 7 Reporter: Bill Nottingham <notting>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: jstodola, rvokal
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: anaconda-19.31.39-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 10:16:22 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 Bill Nottingham 2013-12-04 16:58:39 UTC 
Description of problem:

On an installed system today, I have:

[root@localhost ~]# find /mnt/sysimage/
/mnt/sysimage/
/mnt/sysimage/home
/mnt/sysimage/etc
/mnt/sysimage/etc/pki
/mnt/sysimage/etc/pki/product
/mnt/sysimage/var
/mnt/sysimage/var/lib
/mnt/sysimage/var/lib/rhsm
/mnt/sysimage/var/lib/rhsm/productid.js

On a system installed in October, I have:

[root@wierzbowski ~]# find /mnt/sysimage/
/mnt/sysimage/
/mnt/sysimage/home
/mnt/sysimage/etc
/mnt/sysimage/etc/pki
/mnt/sysimage/etc/pki/product
/mnt/sysimage/etc/pki/product/231.pem
/mnt/sysimage/etc/pki/product/226.pem
/mnt/sysimage/var
/mnt/sysimage/var/lib
/mnt/sysimage/var/lib/rhsm
/mnt/sysimage/var/lib/rhsm/productid.js

Examining how these got created, I find this in the subscription-manager yum-plugin code:

def chroot():
    """
    Use /mnt/sysimage when it exists to support operating
    within an Anaconda installation.
    """
    sysimage = '/mnt/sysimage'
    if os.path.exists(sysimage):
        Path.ROOT = sysimage

Ergo, the subscription-manager yum plugin is using /mnt/sysimage if it exists in the installed system. It likely shouldn't (and I'll clone that bug), but it doesn't appear to be creating it.

Looking at the full timestamps:

[root@localhost ~]# ls --full-time /mnt/sysimage/ -at
total 0
drwxr-xr-x. 5 root root 37 2013-12-04 11:23:28.159000000 -0500 .
drwxr-xr-x. 3 root root 16 2013-12-04 11:23:28.159000000 -0500 etc
drwxr-xr-x. 3 root root 16 2013-12-04 11:23:28.159000000 -0500 var
drwxr-xr-x. 3 root root 21 2013-12-04 11:22:59.111000000 -0500 ..
drwxr-xr-x. 2 root root  6 2013-12-04 11:22:59.111000000 -0500 home

and then correlating with anaconda.log:

16:22:58,527 INFO anaconda: Configuring installed system
16:22:58,942 INFO anaconda: Writing network configuration
16:22:58,943 INFO anaconda: setting installation environment hostname to localhost.localdomain
16:22:59,062 INFO anaconda: Creating users
16:22:59,063 INFO anaconda: created new libuser.conf at /tmp/libuser.m2uj0l with instPath="/mnt/sysimage"
11:22:59,143 INFO anaconda: user account cloud-user setup with no password
16:22:59,155 INFO anaconda: Configuring addons
16:22:59,157 INFO anaconda: Generating initramfs

I am left with the impression that /mnt/sysimage/home is created as part of the user creation process. So, filing against anaconda.

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

latest-releng as of 1203

How reproducible:

Found two cases so far
Comment 2 Bill Nottingham 2013-12-06 14:50:14 UTC 
As a note, a image kickstart *without* a 'user' line did not show this issue.
Comment 3 Brian Lane 2013-12-09 17:56:13 UTC 
When anaconda runs the user setup /mnt/sysimage should have the target mounted on it, also /mnt/sysimage shouldn't exist at all on the installed system.
Comment 4 David Cantrell 2013-12-12 16:10:35 UTC 
I guess we need to make sure /mnt/sysimage/mnt/sysimage does not exist at the end of installation.  Or, really, /mnt/sysimage/mnt is an empty directory.
Comment 6 Jan Stodola 2014-01-30 09:04:40 UTC 
Retested with anaconda-19.31.51-1.el7, there is no /mnt/sysimage directory after the installation where one user was created.

Moving to VERIFIED.
Comment 8 Ludek Smid 2014-06-13 10:16:22 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.