This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 986547 - Very long installation time, because fixing the owner takes three and a half hours time.
Very long installation time, because fixing the owner takes three and a half ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-20 09:01 EDT by Mikhail
Modified: 2014-12-08 16:25 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-08 16:25:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda log (42.06 KB, text/x-log)
2013-07-20 09:01 EDT, Mikhail
no flags Details
screenshot (218.22 KB, image/png)
2013-07-20 09:02 EDT, Mikhail
no flags Details

  None (edit)
Description Mikhail 2013-07-20 09:01:41 EDT
Created attachment 776154 [details]
anaconda log

Description of problem:
Very long installation time, because fixing the owner takes three and a half hours time.

09:04:47,687 INFO anaconda: Creating users
09:04:47,688 INFO anaconda: created new libuser.conf at /tmp/libuser.my9L2J with instPath="/mnt/sysimage"
09:04:47,725 INFO anaconda: Home directory for the user mikhail already existed, fixing the owner.
12:23:34,101 INFO anaconda: Configuring addons
Comment 1 Mikhail 2013-07-20 09:02:23 EDT
Created attachment 776160 [details]
screenshot
Comment 2 Mikhail 2013-07-20 09:04:41 EDT
I think you must add option for skip it, and graphically display the process because that is the impression that a setup is hangs.
Comment 3 Mikhail 2013-07-20 09:05:31 EDT
Of course be better if this process be more quick.
Comment 4 Steve Tyler 2013-07-20 14:56:20 EDT
Thanks for your report.

From the anaconda source, "fixing the owner" means running chown() on the user's home directory. Do you know what your user id was before you installed?
(The old and new user ids don't seem to get logged.)

Since you have already installed, this is moot, but you can set the user id and group id of the new user using the Advanced User Configuration dialog. (Click "Advanced..." in the Create User dialog.)

$ less -N anaconda-19.30.13-1/pyanaconda/users.py
...
    296                 if not mk_homedir:
    297                     stats = os.stat(userEnt.get(libuser.HOMEDIRECTORY)[0])
    298                     orig_uid = stats.st_uid
    299                     orig_gid = stats.st_gid
    300 
    301                     log.info("Home directory for the user %s already existed, "
    302                              "fixing the owner." % user_name)
    303                     # home directory already existed, change owner of it properly
    304                     iutil.chown_dir_tree(userEnt.get(libuser.HOMEDIRECTORY)[0],
    305                                          userEnt.get(libuser.UIDNUMBER)[0],
    306                                          groupEnt.get(libuser.GIDNUMBER)[0],
    307                                          orig_uid, orig_gid)
...
Comment 5 Steve Tyler 2013-07-20 17:22:19 EDT
It looks like the installer is "fixing the owner", even if the user id does not change. In a pair of back-to-back test installs, I created "/home" with F18 and confirmed the user id was 1000 after firstboot. Next, I installed F19, reused "/home", and created a user with the same user name. The resulting user had user id 1000, yet the fix was initiated anyway.

Snippet from anaconda.log:
...
21:03:42,208 INFO anaconda: Creating users
21:03:42,209 INFO anaconda: created new libuser.conf at /tmp/libuser.BT4B5m with instPath="/mnt/sysimage"
14:03:42,532 INFO anaconda: Home directory for the user joeblow already existed, fixing the owner.
...

Tested in a VM with:
$ qemu-img create f19-test-3.img 32G
$ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga std -boot menu=on
$ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
Comment 6 Steve Tyler 2013-07-20 19:01:15 EDT
A possible problem here is that the anaconda function iutil.chown_dir_tree() is reimplementing the Linux "chown -R" command by repeatedly calling the Python os.chown() function:
https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/iutil.py?h=f19-branch&id=anaconda-19.30.13-1#n676

The Python os.chown() function does not appear to support recursion or conditional changes:
http://docs.python.org/3/library/os.html?highlight=chown#os.chown

In contrast, the Linux chown command supports both recursion (-R option) and conditional owner and group changes (--from option):
http://man7.org/linux/man-pages/man1/chown.1.html

Using the Linux chown command might significantly increase the speed of this step in the installation process for users with a large number of files and directories in their home directory.
Comment 7 David Shea 2013-09-19 14:57:11 EDT
Providing an option to skip the process likely create a lot of permissions surprises for users who click it not knowing what it does, so I'd rather just not provide the option. There's nothing we can do to chown the directory any more quickly, but we could do a better job of reporting what's going on.

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