Fedora Account System
Red Hat Associate
Red Hat Customer
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.
Hrm. What did your /etc/nsswitch.conf look like? I'm not really sure how we can sanely handle this...
/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 ;-)
I guess we'd need to either enable the network at upgrade time, or temporarily disable ldap. I'd probably go for the latter.
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.