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) scenario: - 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. repeatability: - 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. observation: - /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] Anaconda traceback
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 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.
Passing to QA to attempt to reproduce.
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 work.) Quantum 1.6GB 17" NEC XV17 monitor 101 keyboard with us layout logitech 3 button mouse SB AWE 32 DLink 10/100 NIC (uses via-rhine driver) System 2 Abit BH6 m/b Celeron "450A" (300A with 100MHz FSB) - never a problem 256MB 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 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 ...
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 ...