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 - crud in /mnt/sysimage after install, presumably from user creation
Summary: crud in /mnt/sysimage after install, presumably from user creation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-04 16:58 UTC by Bill Nottingham
Modified: 2014-06-18 01:45 UTC (History)
2 users (show)

Fixed In Version: anaconda-19.31.39-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 10:16:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


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