UPGRADE to Xorg-X11, is it safe??

[Douglas Furlong]

Quoting geneSmith <gene.smith at sea.siemens.com>:

> Bart Kalita wrote:
> 
> > Gene Smith wrote:
> >> Is it normal for yum to get very quite (80-90% cpu and very little 
> >> disk activity) for a long time after all the header and packages are 
> >> downloaded and after printing "Test transaction complete, Success!"? I 
> >> killed it and started over thinking maybe it was hung but is is still 
> >> being very slow at this point the 2nd time.
> >>
> >>
> >>
> > Depending on the amount of the updated files it might take a fair amount 
> > of time.
> 
> Yum did finally finish whatever it does after "Test transaction 
> complelete, Success!". But after (or while) installing the 1st of 312 
> package, libgcc (gcclib?), it really seemed hung, so I killed it again. 
> It had earlier complained about needing "pyparted" which it had 
> obtained. I tried to manually install pyparted with rpm but rpm hung and 
> after that I could not get any rpm function to work again without 
> reboot. After reboot was able to manually upgrade rpm, python, yum, 
> pyparted and possibly others using rpm -Uhv. The next time I ran yum it 
> installed all 312 packages ok and did not hang on/after libgcc. Not sure 
> what my problem was or if manually installing these packages before 
> re-running yum had an effect. Or possibly it was not really hung during 
> gcclib but I just needed to give it more time. (The last time I ran yum, 
> I gave it a option to print status messages at max level 10. However, 
> during periods of intense cpu activity and zero disk, it provided no 
> additional info on what it was doing.)

There is a bug in redhat, that was quite sevear in Redhat 8 and 9, but seems to
have become fair less common in FC, but still present.

The symptoms.

RPM process would freez, CTRL + C would have no effect. kill -9 <pid> would tend
to kill the process.

On future runs, RPM would stall/fail untill a reboot.

As YUM relies on the RPM infrastructure, I have noticed once or twice it seems
to suffer from a similar problem, however I may be wrong.

To get around this without rebooting (handy on servers). kill -9 <pid>, then rm
/var/lib/rpm/__*.db (some thing along these lines), rpm --rebuilddb

Then RPM seems to run again.

I think this would have probably solved your problems.

Doug