During a fresh install from Fedora 17-Alpha-x86_64-DVD, and after all
packages have been installed, then there is a pause of a few minutes
before installation completes and is ready for Reboot. On a 2GHz box
I waited about 3 minutes from the last package before seeing "Bootloader
installation", and another 2 minutes before "Congratulations! ... Ready
for Reboot."
That five minutes from the last package to Reboot is much too long,
particularly without better indications of progress.
I re-ran the complete fresh install but turned on measuring near
the end of package install. On VT2 I entered the shell commands:
cd /mnt/sysimage/root # somewhere to keep a file
strace -f -t -o strace.out -e trace=file -p PID_of_anaconda 2>/dev/null
This traces the anaconda process and any future children, writes output
to a file, traces all system calls that involve filenames, and includes
the wall-clock time at each syscall.
When installation finished, then I applied text processing tools to
strace.out. Subtracting wall-clock times revealed these major steps
(and in this order):
seconds activity
112 dracut (construct initramfs)
260 new-kernel-pkg --rpmposttrans (commit yum transaction)
230 grub2-mkconfig (bootloader configuration)
65 anaconda (reset SELinux attributes of files in yum database)
=====
667 strace expanded wall-clock time by a factor of 2.2 (667/300)
I suggest that the activities "Construct initramfs", "Commit yum transaction",
and "Set SELinux attributes for yum database" deserve to be mentioned
separately just as "Bootloader configuration". It is curious that the
SELinux attributes for the yum database are not reset as part of the
--rpmposttrans, and that the bootloader configuration occurs between
those two activities.
The sorted histogram of all calls from strace.out begins:
One immediate suggestion: If the directories /tmp/updates and /tmp/product
contain no regular files [at any depth], then remove those directories
from the PATH and LD_LIBRARY_PATH environment variables. This will save
much searching.
All usage of /usr/bin/logger is within grub2-mkconfig. Could the logger be
run in parallel with items redirected into its stdin, instead invoking
a separate process each time?
The sorted histogram of filesystem probing via grub2-probe begins:
slow install after packages and before reboot
