Okay, I have over 9 gigs of spare room on my main hard drive, so I don't think var is filling up. I've set prelinking to be off (I think), and yet still, YUM continues to freeze my computer.
If I try to do a search or install, about half the time it will go nuts on the hard drive, I lose control of the mouse, and eventually I have no choice but to hard reset.
What's wrong with YUM?
Dave
On Sun, 2005-08-21 at 22:25 +0900, Dave Gutteridge wrote:
Okay, I have over 9 gigs of spare room on my main hard drive, so I don't think var is filling up. I've set prelinking to be off (I think), and yet still, YUM continues to freeze my computer.
If I try to do a search or install, about half the time it will go nuts on the hard drive, I lose control of the mouse, and eventually I have no choice but to hard reset.
What's wrong with YUM?
Probably nothing wrong with yum ... instead probably something wrong with rpm or maybe just the rpm database.
Since you have installed packages outside the centos repos, it will be hard to track.
try doing this:
cd /var/lib/rpm rm __db.00* rpm --rebuilddb
after that completes, try running yum.
On Mon, 2005-08-22 at 00:32 +0900, Dave Gutteridge wrote:
try doing this:
cd /var/lib/rpm rm __db.00* rpm --rebuilddb
I got this message:
[root@localhost rpm]# rm __db.00* rm: cannot lstat `__db.00*': No such file or directory
Is this a significant error?
Dave
Maybe ... it means you don't have an RPM database ... hopefully all the other files are intact
try running:
rpm --rebuilddb
On Mon, 22 Aug 2005, Dave Gutteridge wrote:
cd /var/lib/rpm rm __db.00* rpm --rebuilddb
I got this message:
[root@localhost rpm]# rm __db.00* rm: cannot lstat `__db.00*': No such file or directory
Is this a significant error?
Just means that John was right, your rpm database was very messed up.
------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine
... or at least I hope it's solved. I rebuilt my database as suggested, and tried running some searches, since I didn't have anything I wanted to install. So far so good.
Thanks for the clear and helpful advice!
Dave
On Sun, 21 Aug 2005, Johnny Hughes wrote:
On Sun, 2005-08-21 at 22:25 +0900, Dave Gutteridge wrote:
Okay, I have over 9 gigs of spare room on my main hard drive, so I don't think var is filling up. I've set prelinking to be off (I think), and yet still, YUM continues to freeze my computer.
If I try to do a search or install, about half the time it will go nuts on the hard drive, I lose control of the mouse, and eventually I have no choice but to hard reset.
What's wrong with YUM?
Probably nothing wrong with yum ... instead probably something wrong with rpm or maybe just the rpm database.
Since you have installed packages outside the centos repos, it will be hard to track.
try doing this:
cd /var/lib/rpm rm __db.00* rpm --rebuilddb
after that completes, try running yum.
Beware though, removing the __db.* files (a cache) should be sufficient. You do not have to run rpm --rebuilddb if the cause of the poblem was the corrupt cache.
Also, do NOT attempt to run rpm --rebuilddb with a corrupt cache in place, because this may cause your rpmdb to get corrupted. Often people complain that rpm --rebuilddb did not solve their rpmdb problems, while in fact rpm --rebuilddb corrupted the rpmdb. And a mere removal of the cache (__db.*) was sufficient to solve the problem.
You have been warned :)
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 2005-08-22 at 20:31 +0200, Dag Wieers wrote:
Beware though, removing the __db.* files (a cache) should be sufficient. You do not have to run rpm --rebuilddb if the cause of the poblem was the corrupt cache. Also, do NOT attempt to run rpm --rebuilddb with a corrupt cache in place, because this may cause your rpmdb to get corrupted. Often people complain that rpm --rebuilddb did not solve their rpmdb problems,
Yep, AFAIK, --rebuilddb hasn't been required since the original RPM 4.1 (was it?) of Red Hat Linux (RHL) 8. Can you confirm that DAG?
while in fact rpm --rebuilddb corrupted the rpmdb. And a mere removal of the cache (__db.*) was sufficient to solve the problem. You have been warned :)
I often do an "--initdb" instead. Is that wrong? I haven't done it since RHL 9.
On Mon, 22 Aug 2005, Bryan J. Smith wrote:
On Mon, 2005-08-22 at 20:31 +0200, Dag Wieers wrote:
Beware though, removing the __db.* files (a cache) should be sufficient. You do not have to run rpm --rebuilddb if the cause of the poblem was the corrupt cache. Also, do NOT attempt to run rpm --rebuilddb with a corrupt cache in place, because this may cause your rpmdb to get corrupted. Often people complain that rpm --rebuilddb did not solve their rpmdb problems,
Yep, AFAIK, --rebuilddb hasn't been required since the original RPM 4.1 (was it?) of Red Hat Linux (RHL) 8. Can you confirm that DAG?
I can't. I just know JBJ often repeated the warning. Also, cache corruption should not happen on a stable system anymore. Those bugs have been fixed. But if you do encounter this, try to reproduce, check you hardware and then contact JBJ.
while in fact rpm --rebuilddb corrupted the rpmdb. And a mere removal of the cache (__db.*) was sufficient to solve the problem. You have been warned :)
I often do an "--initdb" instead. Is that wrong? I haven't done it since RHL 9.
I am not sure if it has any effect on a system with an existing rpmdb. Never used it for that.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 2005-08-22 at 21:47 +0200, Dag Wieers wrote:
I can't. I just know JBJ often repeated the warning.
Yep, I saw it too. I had a RHL8.0 installation get seriously fubar'd as a result.
Also, cache corruption should not happen on a stable system anymore. Those bugs have been fixed. But if you do encounter this, try to reproduce, check you hardware and then contact JBJ.
I ran into it all-the-time under RHL8.0, but RHL9 seem to fixed almost everything.
I think I had maybe 2 issues with RHL9 and 1 with FC1, and I never did again. And in all cases of the RHL9/FC1 issues, those were systems that were originally RHL8 (possibly RHL7.3) and had been upgraded to RHL9/FC1 from it.
I am not sure if it has any effect on a system with an existing rpmdb. Never used it for that.
What I ran into with RHL9/FC1 was that the system expected some sort of "initial db cache." Deleting the files didn't do enough, "--rebuilddb" had the aforementioned consequences. I found RHL9 always worked fine once I did a "--initdb". It basically started building the cache anew on any new operation.
On Mon, 2005-08-22 at 21:47 +0200, Dag Wieers wrote:
On Mon, 22 Aug 2005, Bryan J. Smith wrote:
On Mon, 2005-08-22 at 20:31 +0200, Dag Wieers wrote:
Beware though, removing the __db.* files (a cache) should be sufficient. You do not have to run rpm --rebuilddb if the cause of the poblem was the corrupt cache. Also, do NOT attempt to run rpm --rebuilddb with a corrupt cache in place, because this may cause your rpmdb to get corrupted. Often people complain that rpm --rebuilddb did not solve their rpmdb problems,
Yep, AFAIK, --rebuilddb hasn't been required since the original RPM 4.1 (was it?) of Red Hat Linux (RHL) 8. Can you confirm that DAG?
I can't. I just know JBJ often repeated the warning. Also, cache corruption should not happen on a stable system anymore. Those bugs have been fixed. But if you do encounter this, try to reproduce, check you hardware and then contact JBJ.
while in fact rpm --rebuilddb corrupted the rpmdb. And a mere removal of the cache (__db.*) was sufficient to solve the problem. You have been warned :)
You definitely do not want to rebuild the database if the cache is present.
I have not had any issues rebuilding the database if the cache is deleted.
It is a good thing to check and see if your problem is fixed before running --rebuilddb though, because sometimes just removing the cache can fix the issue.
A reboot will also normally clear the cache
-
Bryan J. Smith -
Dag Wieers -
Dave Gutteridge -
Jim Wildman -
Johnny Hughes