Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 186216 - install of fc5 hangs if nscd not running.
Summary: install of fc5 hangs if nscd not running.
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
Depends On:
Blocks: FC6Target
TreeView+ depends on / blocked
Reported: 2006-03-22 11:04 UTC by James Hunt
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-14 21:47:24 UTC

Attachments (Terms of Use)

Description James Hunt 2006-03-22 11:04:41 UTC
Description of problem:

I have just tried to upgrade an FC4 system to FC5, but part-way through the RPM
updates, the install screen hung (on updating privoxy).

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1. upgrade from fc4 to fc5
Actual results:

Anaconda hung.

Expected results:

Installation does not hang.

Additional info:

The messages console (Control-Alt-F4) showed a load of errors about useradd,
groupdel, "cannot contact LDAP server", and "sleeping for 32 seconds" (this
sequence looped round and round).

The workaround I found was to do the following:

1. Press "Control-Alt-F2" to get to the shell window
2. Run, "chroot /mnt/sysimage"
3. Run, "/sbin/service nscd start"
4. Run, "/sbin/ifup lo"
5. Press "Control-Alt-F7" to return to GUI install

Install should then proceed as expected until the last package
(eclipse-changelog), where again it hung. At this point I did this:

1. Ran, "exit"
2. Ran, "cd /"

The install then completed successfully.

This isn't the first time I've had problems with nscd, that's why I generally
switch it off. The problem here seemed to be the "classic" where you run useradd
as root, and it doesn't complain, but the user *doesn't* get added due to some
ldap issue.

It looks like the installer was unhappy with my /etc/ldap.conf since the "host"
line specified a non-local host, and when the installer was running, the network
was down.

Comment 1 Jeremy Katz 2006-03-22 15:53:45 UTC
Hrm.  What did your /etc/nsswitch.conf look like?

I'm not really sure how we can sanely handle this...

Comment 2 James Hunt 2006-03-22 17:39:31 UTC
/etc/nsswitch.conf is totally standard apart from this bit:

passwd:  files ldap
shadow:  files ldap
group:   files ldap

ie, the "ldap" bit was added. Additionally, my /etc/ldap.conf shows a non-local
host, ie something like this:

# Your LDAP server. Must be resolvable without using LDAP.

the comment is interesting - the ldap server would have been resolvable, had the
network been up with the upgrade was in progress ;-)

Comment 3 James Hunt 2006-03-27 09:05:42 UTC
I guess we'd need to either enable the network at upgrade time, or temporarily
disable ldap. I'd probably go for the latter.

Comment 4 Chris Lumens 2007-03-14 21:47:24 UTC
I don't think there's anything reasonable we can do here.  About the best we can
do is mention this in the release notes.

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