UPGRADE to Xorg-X11, is it safe??
Douglas Furlong
douglas.furlong at firebox.com
Mon Mar 22 20:55:11 UTC 2004
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
More information about the fedora-test-list
mailing list