Alexander Lazarevich wrote:
This problem was previously discussed in post: "duplicate packages after up2date failure" by Damian Menscher on Sun, 9 Oct 2005 16:53:17 -0500 (CDT). We have the same problem on a FC4x86_64 machine. I've notice that up2date of openssh causes a similar (unkillable) useradd process to hang the machine. After a hard reboot, the up2date openssh seems to have succeeded, but the old openssh is still around: openssh.x86_64 4.2p1-fc4.1 installed openssh.x86_64 4.0p1-3 installed Messy, but ssh seems works. What I'd like to know is, for any future up2date's, is redhat going to fix this FC4U2/up2date/useradd/64bit kernel problem. Or should we just roll back to FC3x86_64, which doesn't have this problem (not that I've heard of, we have a 64bitFC3 system that up2dates just fine). I agree with Damian in that up2date should install and clean each package individually before moving onto the next. Alex
I believe that rpm operates in the same method when updating groups of rpms. Yum and up2date seem to clear the database entries when the updating tasks complete. Any sudden interruption in any of the programs seems to result in multiple entries for programs replaced during a group rpm upgrade.
Probably filing an RFE regarding updating the db per successfully completed operation might get some answers. I think the db being updated upon completion is due to resolved dep entries not being complete until all packages are installed. Also writing to the db so many times when the end result is the same probably saves on disk cycles and lowers the possibility the database will become corrupted.
Of course power loss without a battery backup, programs that peg the processor which need a hard kill and shutting down the computer before the update process is completed make individually cleaning per package install desirable.
Jim -- QOTD: If it's too loud, you're too old.
