Bug 186216

Summary:	install of fc5 hangs if nscd not running.
Product:	[Fedora] Fedora	Reporter:	James Hunt <jamesodhunt>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED CANTFIX	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-14 21:47:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	150223

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:

n/a.

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.
host: non.local.com
____________________

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.