Primary symptom: ldconfig hangs during package installation
- 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.
Please try the final 7.0 release and see if it fixes this problem.
Created attachment 3640 [details]
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.
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?
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
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.
Passing to QA to attempt to reproduce.
Thanks for investigating. Here's a more detailed description of my hardware:
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
17" NEC XV17 monitor
101 keyboard with us layout
logitech 3 button mouse
SB AWE 32
DLink 10/100 NIC (uses via-rhine driver)
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
QUANTUM FIREBALL EX6.4A
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.
thanks for your additional information, especially the detailed hardware
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 ...
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 ...