Bug 17419 - Pinstripe package installation hangs during ldconfig
Summary: Pinstripe package installation hangs during ldconfig
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brock Organ
QA Contact:
Whiteboard: Guinness has the same or similar prob...
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-12 02:16 UTC by Need Real Name
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-21 21:34:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Anaconda traceback (1.89 KB, patch)
2000-10-03 02:44 UTC, Need Real Name
no flags Details | Diff

Description Need Real Name 2000-09-12 02:16:11 UTC
Primary symptom: ldconfig hangs during package installation

background information:
 - this machine previously had redhat 6.1 installed with no problem
 - initial installation (not an upgrade) onto /dev/hdc
 - BH6 motherboard with 64MB & Celeron 300A (pretty darn common)
 - Matrox Millenium 4MB w/ NEC XV17 monitor
 - SB64 sound card
 - 4x4 cdrom changer
   (all-in-all a pretty mundane system that has been successfully run
   redhat since it was built)

 - Launch default redhat installer using boot.img
 - Select default workstation installation
 - packages start installing
 - ... hang ...
 - Ctrl-Alt-F2 and ps -eH => ldconfig is chewing up CPU
   indefinitely with no disk activity.
 - yes, but not with every package. For example, the first time 
   it hung was during the glibc package installation. Killing the
   ldconfig process allowed anaconda to continue but it would 
   invariably hang again later.
 - During the second installation attempt, it actually got through
   the glibc package but hung soon after on another package.

 - /mnt/sysimage/etc/ld.so.conf was empty
 - if I kept killing the hung ldconfig processes enough, it would get
   to the end of the installation and then anaconda itself would hang.
   All the packages are installed at this point but the installer just
   sits there. No CPU is being consumed and the "Next" button simply
   stays greyed out.

Comment 1 Michael Fulbright 2000-09-29 17:01:12 UTC
Please try the final 7.0 release and see if it fixes this problem.

Comment 2 Need Real Name 2000-10-03 02:44:53 UTC
Created attachment 3640 [details]
Anaconda traceback

Comment 3 Need Real Name 2000-10-03 02:46:40 UTC
It doesn't fix the problem. There is a change in behaviour though. Instead of
ldconfig hanging, it was anaconda itself that hung. The install.log indicated
that the glibc package failed to run ldconfig ldconfig complained that
/lib/lib???.so is not a symbolic link.

When I attempted the install a second time, it actually got through the package
installation but then rebooted during the post-install phase. During this second
install, the /mnt/sysimage/etc/ld.so.conf remained empty but the "not a symbolic
link" messages didn't appear in the install.log. After the spontaneous reboot, I
tried an "upgrade" instead of an initial install but it anaconda actually blew
up this time with the attached traceback (anacdump.txt).

I'd have a more information for you but when I tried to submit a new bug,
bugzilla asked me to go back and fix the "component" field. When I did,
everything that I had labouriously copied by hand from the other terminal was
lost. Yes I was pissed.

Comment 4 Michael Fulbright 2000-11-10 20:54:21 UTC
This sounds suspiciously like a hardware related issue.

Is it possible that you could try a different CDROM drive, or perhaps setup a
install tree on another Linux machine and try an NFS or FTP install?

Comment 5 Need Real Name 2000-11-10 23:12:40 UTC
Well, actually I've had similar problems with another extremely common hardware
configuration: ASUS P2T4 m/b w P166. This machine also successfully installed
RedHat 6.1. About the only commonality is that I am installing on a disk other
than /dev/hda.

I also tried a network NFS install (local 100T network) and had similar
problems. For the record, Mandrake 7.2 installed 100% painlessly on both
platforms although my preference is to go back to "stock" redhat.

Comment 6 Michael Fulbright 2000-11-17 16:39:02 UTC
Passing to QA to attempt to reproduce.

Comment 7 Need Real Name 2000-11-17 18:29:25 UTC
Thanks for investigating. Here's a more detailed description of my hardware:

System 1:
ASUS P2P4 m/b rev 1.1
P166 overclocked with 83MHz FSB to 208MHz (rock steady - never had a problem)
4x16MB EDO => 64MB
Matrox Millenium I with 4MB
4x4 cdrom changer
IBM 2.1GB HD (IBM-DAQA-32160) (this drive has a bug where it identifies itself
to the bios as PIO mode4 but it has to be overridden to PIO mode3 in order to
Quantum 1.6GB
17" NEC XV17 monitor
101 keyboard with us layout
logitech 3 button mouse
DLink 10/100 NIC (uses via-rhine driver)

System 2
Abit BH6 m/b
Celeron "450A" (300A with 100MHz FSB) - never a problem
IBM 2.1 GB Drive (Identical to above)
Quantum 30GB Fireball LP LM30
Creative Labs 36x CDROM
Matrox Matrox G200 AGP
3Com 3C905 100bTX (rev 0).
Creative Labs Awe128 (Ensoniq AudioPCI (rev 0).)
21" HP A4331D monitor

The two machines are connected through a 10/100 switch to the firewall.

If I can collect any more information for you, just ask.

Comment 8 Brock Organ 2001-01-12 20:56:23 UTC
thanks for your additional information, especially the detailed hardware
description ... 

unfortunately, we were not able to reproduce the problem here in test with
systems similar to what you describe above; 

specifically, we were not able to reproduce this on an Asus T2P4D (D for dual,
running two p133s, which slightly differs from yours above); our install worked
successfully, although we had troubles with the resulting installed system's
stability (old possibly flaky hardware) ...

has this error occurred on more than one system with the T2P4 motherboard ...?
If not, then it may be flaky hardware ... 

Comment 9 Brock Organ 2001-02-21 21:34:35 UTC
hi keith,

We have tried to tighten the anaconda installer to be more descriptive of
certain kinds of errors, and would be interested to know if our recent public
beta (fisher) helped fix the problem on your machine ...

If the error still occurs with fisher and/or any other info that may help us
reproduce the problem you're seeing occurs, please reopen this ...

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