I'm having a difficult time with a remote CentOS 5.5 kickstart installation on an HP ProLiant DL360 G6. This is in an environment where I maintain an internal CentOS yum repository. The kickstart installation and post scripts have been tested and normally work. This hardware is also common in this environment, so I do not believe that it is a factor. Unfortunately, I'm having problems with a specific server install.

The system is remote to the yum repository at a distance of 500 miles. They are connected over a private 100-megabit layer 2 connection (26ms round-trip). I'm mounting the 10mb CentOS 5 netinstall ISO image via an HP ILO remote console. The initial boot parameters are:

linux ks=http://yum.abctrading.com/prop.cfg ksdevice=eth0 ip=x.x.x.x dns=x.x.x.x netmask= gateway=x.x.x.x

I'm using the url --url http://ks.abctrading.com/5.5/os/x86_64/ method of installation. This quickly boots into the anaconda installer, pulls the kickstart config and formats the drives. The process eventually halts at the screen below, reading "Starting install process.". Going to the other virtual consoles give the second image below. The process stalls at this point and cannot proceed with the rest of the installation. Running the same kickstart config locally works just fine. I've tried mounting the boot ISO from the console as well as from the ILO2 command line pointing to a locally-hosted boot ISO via http.

How can I debug this? Are there any options I've overlooked?

enter image description here

enter image description here

  • Is dns= valid? I thought it was nameserver=? You seem to indicate it's getting past that part, so I guess so. – Aaron Copley Mar 3 '11 at 21:28
  • 1
    From the boot screen it's dns=. In the actual kickstart file, it's nameserver=. – ewwhite Mar 3 '11 at 21:30
  • I don't see any thing helpful in that second screenshot. Try changing the log level to debug and see if you get any thing more useful? I believe that's loglevel=debug on the boot line. Or in the Kickstart script with the logging --level=debug statement. – Aaron Copley Mar 3 '11 at 21:33
  • 1
    I've done remote CentOS installs and have has the anaconda stall out at this point for a half-hour, and then suddenly resume. How long have you waited? – JeffG Mar 3 '11 at 21:38
  • 1
    Watch the logs on the http server? (access_log, error_log) Maybe it's just caching RPMs on the remote server before starting the install. – Aaron Copley Mar 3 '11 at 21:44

Maybe it's caching RPMs on the remote server. Watch (tail -f /var/log/httpd/access_log) the access_log on the http server to check for activity.

  • They key here is to debug the slow yum downloads. It seems to be a tcp scaling issue. I'm going to keep working with network parameters. – ewwhite Mar 3 '11 at 22:44

Running this installation via NFS solved the performance issue. Unfortunately, the urlgrabber portion of Yum in the post-install scripts was slow like the initial http installation attempts. The narrows the focus to the implementation of Yum's urlgrabber and something with the line distance and low-latency connection. Once the system was booted into the newly-installed OS, yum speeds were fine.


I have seen this problem caused by a DNS issue.

Determine the hostname of the URL being used by anaconda, and add it to /etc/hosts:

# echo my.server.example.com >> /etc/hosts

anaconda immediately speeds up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.