Bug 170098

Description of problem:
On x86_64 systems, "yum update" hangs in useradd.

How reproducible:
100%

Steps to Reproduce:
1.  Do a fresh install of FC4 x86_64 on an Opteron or Athlon 64
2.  Do a "yum update"
  
Actual results:
System downloads hundreds of packages, installs some of them, then hangs.
ps shows hang in useradd.

Expected results:
Packages should be installed successfully

Additional info:

I did a fresh install of FC4 on an x86_64 system (Tyan S2892 motherboard,
2G RAM, 3ware RAID controller).  The install went fine.  After a reboot,
I logged in, did an su, then "yum update".  It downloaded all the packages,
installed a bunch of them, then hung.  Killing the yum yielded a system
that was broken in mysterious ways.

Did another fresh install, then yum update.  Same thing happened.  Poked
at it some more, found that it was hanging in an invocation of useradd.

Tried doing an install of FC4 x86_64 inside a VMware 5.5 beta virtual
machine on an FC4 system at home.  Install went fine, yum update failed
in the same way.

Sometimes when it fails there is an /etc/passwd.LOCK or some such, but
sometimes not.  On the most recent attempt, there is an /etc/.pwd.lock

At first I thought maybe one of these lock files was getting left over,
and it was waiting to acquire the lock.  But deleting the lock file
doesn't get it going again, so I don't think that's the problem.
Furthermore, I can't kill or even "kill -9" the useradd process; even
after "kill -9" it's still hanging around in "D+" state (whatever that
is):

[root@localhost etc]# ps -C useradd -f
UID        PID  PPID  C STIME TTY          TIME CMD
root     25933 25931  0 00:46 pts/1    00:00:00 /usr/sbin/useradd -c Network
Crash Dump user -r -u 34 -g netdump -s /bin/bash -r -d /var/crash netdump
[root@localhost etc]# 

I assume that useradd is being invoked as part of an RPM postinstall
script (or maybe preinstall).  The netdump user already exists before
the yum update.  The last time I did this it hung in useradd for a
different user, presumably as part of the installation of a different
package.

This seems *very* reporoducible, and not specific to the configuration
of the first machine I encountered the problem on.