Kickstart taking long time on RHEL 4 to start

[Greg Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rik Herrin wrote:
> Hi,
>   I'm experiencing a strange RHEL v4 specific issue. 
> For some reason, Kickstart is taking a very long time
> to start installing packages.  I'm installing from an
> nfs server and the ks file is located on the nfs
> server.  Anaconda quickly gets a DHCP request and goes
> through everything at a reasonable rate until it
> reaches the screen where it is about to install
> software (after it has completed the formatting).  It
> then "hangs" for about 5-10 minutes before continuing.

Being a Fedora Core weenie I cannot vouch for the main RH products.
Sniff RH 9 was the last one I could afford.  But alas Microsoft ME and
MS Office 97 were the last MS product I could afford.  The WAF, Wife
Acceptance Factor, is going reasonably well these days with FC 4.  She
really likes FireFox, etc but I digress...
My guess is that you are going from the precomputed dependency comps.xml
file to a dynamically computed file.  This is precisely the area that I
believe the computation would take place.  When I look at your full.cfg
ks file I see two things.  One, you have an @everything install.  To get
all the toys, then you will have some computation time involved.  Also
in your example file you have additional packages that I believe would
be included in an @everything install.  I don't know if this is true or
not but could that cause the comps.xml computation to take more time as
it has to account for these packages too?

I believe I see this same "hang" on FC 4.  However, I like you install
from ISOs or an install true on an NFS server.  I believe the location
of the ks.cfg is immaterial in this circumstance.  In my situation, I
get the install going and go to bed.  Life is good.


>  Even when installing software, I feel that it is
> quite slow.  I had the exact same setup on RHEL v3 and
> it was about twice as fast.  Furthermore, on RHEL v3,
> there was no delay in any part of the installation.  I

Yep!  I only have a couple of clients for the NFS server and a gigabit
switch.   There was a post from Jermy Katz talking about the future
plans back in June 2005--I think.  Try your install on FC 4 to see if
you have the same problem exists.  I thought part of the issue is that
when you do an @everything install it takes awhile to go through four
CDs.  I am even disappointed that there's not a DVD full of binary stuff
from extras.  I could careless about the source being on the DVD but
then again that's a whole subject itself.  More is better in this case
because I am paying for the distribution to include all these things
right?  Well those are my thoughts--one CD is less. ;-)

Anaconda is going through a bunch of changes right now.  Perhaps this
issue will be resolved if the dynamic comps.xml calculation is at the
heart of the matter.  The plan is to use yum to perform these
calculations as far as I understand it.  There were some posts to this
list or the anaconda development list.  Please review some of these
ideas here http://fedoraproject.org/wiki/AnacondaWorkItems .  Moreover,
you may want to enter some buzilla reports so that the developers keep
this in mind.  However, I gather that the dynamic computation of the
comps.xml solved other problems.

> checked that traffic on the network and there was
> basically no traffic except for the installation (I
> had only a single machine installing).  After taking
> some time to install the packages, the installation is
> successful.  However, I was wondering why it takes so
> long to start installing the packages.  Any ideas? 

Please remember that I am guessing here.

> Thanks for your time.  
> 
> PS.  I attached the kickstart file if anyone's interested.
> 

Here's the second problem with your kickstart file.  Please be aware of
security issues.  If you post a ks file in the future, then please blank
this line
rootpw --iscrypted $1$jgCXJg5n$Nkh7qximuxKPCkbE.Eulm1
You've just let people know an encrypted string that they can start
running a crack library against.  You may want to change all your
passwords that might use parts of this password.

I hope this helps,
Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDLepixyxe5L6mr7IRAv7uAJ0RYAS9YqvIjkEXvkqEyvNouedUSACgiWX6
RRhK+0mMwD+0V2hhzOkkj54=
=aVSd
-----END PGP SIGNATURE-----