Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 598957 - /etc/skel not copied if mountpoint inside home folder configured during partitioning
Summary: /etc/skel not copied if mountpoint inside home folder configured during parti...
Alias: None
Product: Fedora
Classification: Fedora
Component: firstboot
Version: 15
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Martin Gracik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-02 12:19 UTC by Sandro Mani
Modified: 2013-07-04 12:51 UTC (History)
1 user (show)

Fixed In Version: firstboot-16.1-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-29 07:56:13 UTC

Attachments (Terms of Use)

Description Sandro Mani 2010-06-02 12:19:44 UTC
Description of problem:
If, when installing fedora, in the partitioner you setup a partition mountpoint inside your future home directory, the items in /etc/skel will not get copied to the home directory when setting up the user with /usr/sbin/firstboot 

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

How reproducible:

Steps to Reproduce:
1. Boot from live cd, launch installer, proceed to partitioning
2. Setup the mountpoint of some partition inside your home directory, i.e. /home/<username>/Data
3. Complete installation, reboot, first-boot wizard appears
4. When setting up the user account in firstboot, you will get warned that /home/<username> already exists and you are asked if you want to take ownership of the items contained / relabel the items. Press yes, complete the wizard, login
5. Notice that .bashrc, .bash_profile etc are missing in your home directory
Actual results:
None of the /etc/skel items are copied to the newly setup home folder, which results in bash only showing bash-4.1$ instead of [user@host dir]$ for example.

Expected results:
The casual user would expect the home directory to be set up normally.

Additional info:
I guess the problem ist that, the directory being created by anaconda for the mount point, firstboot detects it as non-empty, hence assumes that it is an already-existing home directory of some previous installation, and for that reason it does not modify anything to prevent any possibly existing .bash* from getting overwritten, possibly erasing user defined settings. The most straight forward solution to this problem I see is to check whether the items in /etc/skel already exist in the home folder, and if not, copy them, otherwise leave them untouched.

Comment 1 Fedora Admin XMLRPC Client 2011-02-16 16:09:18 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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