Bug 186216 - install of fc5 hangs if nscd not running.
install of fc5 hangs if nscd not running.
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
:
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-03-22 06:04 EST by James Hunt
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-14 17:47:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description James Hunt 2006-03-22 06:04:41 EST
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 10:53:45 EST
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 12:39:31 EST
/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 04:05:42 EST
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 17:47:24 EDT
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.