Bug 1038241
| Summary: | crud in /mnt/sysimage after install, presumably from user creation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Bill Nottingham <notting> |
| Component: | anaconda | Assignee: | Brian Lane <bcl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | 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: | |||
As a note, a image kickstart *without* a 'user' line did not show this issue. 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. 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. 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. 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. |
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